Diller

Kritik CSS

Critical CSS — ekranın üst bölümündeki stilleri ayıklayıp satır içine alarak ve geri kalanını erteleyerek ilk boyamayı hızlandırma tekniği. Google'ın bunu neden gelişmiş ve isteğe bağlı gördüğü, gerçek ödünleşimler (önbellek kaybı, bakım riski, zamanlama yarışları) ve CSS'nin gerçekten darboğazınız olup olmadığını nasıl belirleyeceğiniz.

İlk yayın tarihi: 3 Tem 2026 · Son güncelleme: 22 Ağu 2026 · Advanced
Diller
AIYazanAI v2

Critical CSS bir performans tekniğidir: seçilen ekran üstü görünümü oluşturmak için gereken CSS'yi ayıklar, <head> içine alır ve stil dosyasının geri kalanını asenkron olarak erteler. CSS varsayılan olarak oluşturmayı engellediği için çalışır; CSSOM kurulana kadar tarayıcı boyama yapmaz. Evrensel bir ekran üstü yüksekliği yoktur (cihaz, yön, yakınlaştırma ve sayfa durumu bunu değiştirir); bu nedenle ayrımı sabit bir piksel sınırı değil, bir karar olarak ele alın. En önemli nokta şudur: Google, Critical CSS'yi varsayılan bir tavsiye olarak değil, gelişmiş ve isteğe bağlı bir teknik olarak çerçeveler; kendi belgeleri çoğu sitenin bu tekniği uygulamadan hedeflerine ulaşabilmesi gerektiğini söyler. Ödünleşimler gerçektir: satır içi CSS tekrarlanan ziyaretlerde yeniden kullanılmak üzere önbelleğe alınmaz (ikinci görüntülemeler daha yavaş olabilir), kritik/kritik olmayan ayrım şablonlar veya durumlar değiştikçe fark ettirmeden bozulabilir, CSP style-src politikası satır içi bloğu tamamen engelleyebilir ve preload/onload ertelemesi zamanlama yarışına girebilir veya düzen kaymasına yol açabilir. Önce teşhis edin: Tekniği uygulamadan önce asıl oluşturma darboğazının JavaScript veya sunucu yanıt süresi değil, CSS olduğunu doğrulayın. SEO etkisi doğrudan bir sıralama sinyali değil, Core Web Vitals/LCP üzerinden dolaylıdır. Bing'e özgü bir rehber yoktur. Bu sayfa critical rendering path merkezinin altında yer alır.

TL;DR — Critical CSS = ekranın üst bölümündeki stilleri ayıklamak, bunları <head> içine almak ve stil dosyasının geri kalanını asenkron olarak ertelemek (rel="preload" + onload değişimi, <noscript> yedeği veya loadCSS). CSS varsayılan olarak oluşturmayı engellediği için işe yarar. Doğruluğun temel dayanağı şudur: Google bunu varsayılan bir tavsiye olarak değil, gelişmiş ve isteğe bağlı bir teknik olarak sunar — “Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (çeviri) “Çoğu site, bu tekniği uygulamadan önerilen tüm performans hedeflerine ulaşabilmelidir.” Satır içi yükü küçük tutun. Ödünleşimler gerçektir: satır içi CSS sayfa yüklemeleri arasında önbelleğe alınmaz (tekrarlanan ziyaretler daha yavaş olabilir), şablonlar değiştikçe kritik/kritik olmayan ayrımı bozulur ve erteleme zamanlama yarışına veya FOUC/CLS’ye yol açabilir. Önce teşhis edin — asıl darboğazın JavaScript veya sunucu yanıt süresi değil, CSS olduğunu doğrulayın. Hızlı bir demoda görünmeyen tuzaklara dikkat edin: CSP style-src politikası satır içi <style> bloğunuzu tamamen engelleyebilir; temalar, kişiselleştirme ve durumlar söz konusu olduğunda “yakalama sırasında kullanılmadı” ifadesi “ertelenmesi güvenli” anlamına gelmez; ayrıca satır içine almak font yükleme zamanlamasını çözmez. SEO etkisi Core Web Vitals/LCP üzerinden dolaylıdır. Bing’e özgü bir rehber yoktur.

Critical CSS aslında nedir

Çözdüğü sorun, oluşturmayı engelleyen CSS’dir. Google’ın web.dev sitesi bunu açıkça belirtir: CSS varsayılan olarak oluşturmayı engelleyen bir kaynak sayılır; bu da CSSOM oluşturulana kadar tarayıcının işlenmiş içeriği göstermeyeceği anlamına gelir. Tekniğin var olma nedeni tam olarak budur: Tarayıcı stillerinizi edinene kadar boyama yapmaz; dolayısıyla CSS’yi geciktiren her şey ilk boyamayı da geciktirir. Bunun altında yatan işlem hattının tamamı için bu sayfanın bağlı olduğu critical rendering path merkezine ve onun tamamlayıcısı olan render-blocking resources sayfasına bakın.

Critical CSS, CSS’yi ikiye bölerek bu sorunu ele alır. web.dev’in tanımı: “Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (çeviri) “Critical CSS, ekranın üst bölümündeki içeriği kullanıcıya olabildiğince hızlı göstermek için gereken CSS’yi ayıklayan bir tekniktir.” İşleyişi ise şöyledir: Ayıklanan stilleri HTML belgesinin <head> bölümünde satır içine almak, bu stilleri getirmek için ek istek gereksinimini ortadan kaldırır; CSS’nin geri kalanı asenkron yüklenebilir.

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

web.dev’in açıkça belirttiği, ancak birçok ikincil rehberin geçiştirdiği bir nokta var: there’s no single, universal above-the-fold height. Cihaz boyutu, yön, tarayıcı arayüzü, yakınlaştırma düzeyi ve sayfa durumu (açık bir menü, yüklenmiş kişiselleştirme veya hata durumu), “kritik” kümeye gerçekte nelerin girmesi gerektiğini değiştirir. Critical CSS’yi sabit bir piksel sınırı olarak değil, seçilmiş bir başlangıç görünüm alanı/durumu hakkında verilmiş bir karar olarak ele alın; tek bir masaüstü ekran görüntüsüne göre değil, gerçek kırılma noktalarınız ve durumlarınız üzerinden doğrulayın.

Yani sırasıyla iki iş vardır:

  1. Satır içine alın: İlk boyamadan önce ek bir gidiş-dönüş olmaması için ekran üstü CSS’nin en küçük gerekli kümesini <head> içine alın.
  2. Erteleyin: Stil dosyasının geri kalanını asenkron yükleyin; böylece ilk boyamayı hiçbir zaman engellemez.

Sayfa deneyimi konuşmalarımda bunu tam olarak böyle ikiye ayırdım. Sayfa Deneyiminde Sırada Ne Var? sunumumda (SMX Next 2021) CSS işini iki kovaya koydum: erken/kritik yol (kullanılmayan CSS’yi kaldır → CSS’yi küçült → Critical CSS’yi satır içine al) ve geç/ertelenmiş yol (kritik olmayan CSS’yi ertele). web.dev ile aynı şekil; yalnızca benim düşündüğüm sırada.

Nasıl uygulanır

1. adım — Critical CSS’yi satır içine alın. Lighthouse’ın kendi rehberi, ilk boyama için gereken kritik stilleri HTML sayfasının başındaki bir <style> bloğunda satır içine alın der. Aynı sayfada Google’ın satır içi yük için verdiği boyut hedefi şudur: ekranın üst bölümündeki içeriği 14 KB’nin (sıkıştırılmış) altında tutmayı hedefleyin; böylece içerik ilk ağ gidiş-dönüşüne sığar. Bu sayıyı zamandan bağımsız bir standart olarak değil, tarihsel bir aktarım rehberi olarak değerlendirin: Kaynak sayfa 2019 tarihlidir ve günümüzde yaygınlaşan HTTP/2 ile HTTP/3’ten önce yayımlanmıştır; bu iki protokol ilk gidiş-dönüş hesabını değiştirir. Google’ın kendi belgelerinde hâlâ belirtilen sayı budur; ancak hassas ayar yapıyorsanız 14 KB’yi değişmez bir kural saymak yerine mevcut protokolünüz ve sunucu davranışınız üzerinden doğrulayın.

2. adım — Geri kalanı erteleyin. web.dev’in kritik olmayan CSS’yi ertelemek için önerdiği desen, onload değişimi ve <noscript> yedeği olan bir preload’dur:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

web.dev, üretimde değişimi elle yazmak yerine bu davranışı kapsülleyen ve tarayıcılar genelinde iyi çalışan loadCSS gibi CSS erteleme işlevlerini kullanmayı tavsiye eder. Bunun yerine JavaScript ile erteleme yaparsanız web.dev, kritik olmayan CSS’yi yüklemeden önce JavaScript’in çalışmasını beklemenin kullanıcı kaydırdığında oluşturmayı geciktirebileceği uyarısını yapar. preload bu nedenle indirmeyi daha erken başlatmak için kullanılır.

Araçlar. Critical CSS’yi nadiren elle ayıklarsınız. Google’ın referans uygulaması Addy Osmani’nin critical npm paketidir — “a tool that extracts, minifies and inlines above-the-fold CSS.” (çeviri) “Ekranın üst bölümündeki CSS’yi ayıklayan, küçülten ve satır içine alan bir araç.” Alternatifler arasında Penthouse ve CriticalCSS’nin yanı sıra WordPress ve Shopify için çok sayıda SaaS/eklenti oluşturucusu bulunur. Kritik kuralları kendiniz bulmak için Google, kritik olmayan CSS ve JavaScript’i belirlemek üzere Chrome DevTools’taki Coverage sekmesini önerir.

Bir eklenti veya oluşturucu (WP Rocket, Autoptimize ve benzerleri) kullanıyorsanız satıcının arayüz turunu veya önce/sonra puan ekran görüntüsünü platform garantisi saymayın. Bu sayfalar ürün sürümlerini ve belirli site sonuçlarını serbestçe birbirine karıştırır; puan farkları bağımsız olarak yeniden üretilmiş değildir. Üretimde güvenmeden önce davranışı eklentinin güncel belgeleri ve sürüm numarasıyla doğrulayın ve elle yazılmış bir uygulamada kullanacağınız test matrisiyle — soğuk ve tekrarlı yüklemeler, gerçek kırılma noktalarınız/temalarınız/durumlarınız ve kullanıyorsanız CSP politikanız — sınayın.

Critical CSS’nin oluşturmayı engelleyen CSS için yalnızca bir çözüm olduğunu unutmayın. Diğerleri stil dosyalarını media özniteliğiyle kapsamlandırmak (böylece indirilmeleri ama boyamayı engellememeleri) ve baştan daha az CSS göndermektir. web.dev’in oluşturmayı engelleyen CSS makalesi satır içine almak yerine aslında media yaklaşımını öne çıkarır; yani hangi belgeyi okuduğunuza göre Google’ın birden fazla resmî reçetesi vardır.

Google’ın gerçek tutumu (doğruluk omurgası)

Rakip makalelerin neredeyse tamamının arka plana attığı ve bu yazıyı kaleme almak istememin asıl nedeni olan bölüm budur. Google, Critical CSS’yi varsayılan bir tavsiye olarak sunmaz. Codelab risk konusunda son derece açıktır: Bu codelab, performansı artırabilen ancak doğru uygulanmazsa hatalara da yol açabilen gelişmiş bir performans tekniğini anlatır. Google ayrıca belgelerinde iki kez çoğu sitenin bununla uğraşmasına gerek olmadığını söyler: Çoğu site, bu tekniği uygulamadan önerilen tüm performans hedeflerine ulaşabilmelidir.

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

Sağladığı yarar bile bir uyarıyla birlikte gelir. web.dev, satır içine almanın tarayıcının CSS’yi sonraki sayfa yüklemelerinde yeniden kullanmak üzere önbelleğe almasını engellediğini, bu nedenle ölçülü uygulanması gerektiğini belirtir; aşırı uygulama konusunda da her şey öncelikliyse hiçbir şey öncelikli değildir der. Gereğinden fazla CSS’yi satır içine alırsanız hızlı iletmeye çalıştığınız HTML’yi şişirirsiniz.

Dürüst çerçeve şudur: Critical CSS gerçek, belgelenmiş ve bazen güçlü bir tekniktir; ama Google’ın çoğu sitenin hedeflerine ulaşmak için ihtiyaç duymadığını söylediği gelişmiş, isteğe bağlı ve son çare bir tekniktir. Ona bu şekilde yaklaşın.

Gerçek ödünleşimler

Bağımsız performans mühendisleri burada en yüksek sesle konuşanlar oldu ve Google’ın kendi uyarılarıyla aynı çizgideler.

Tekrarlanan ziyaretlerde önbellek kaybı. DebugBear’dan Matt Zeunert bunu açıkça ifade eder: Critical CSS’nin sitenizde farklı sayfa yüklemeleri arasında yeniden kullanılamayacağını ve bu nedenle sonraki sayfa görüntülemelerinin Critical CSS olmadan olduğundan daha yavaş olabileceğini belirtir. Normal bir harici stil dosyası bir kez önbelleğe alınır ve her yerde yeniden kullanılır; satır içi CSS ise her HTML yanıtının içinde yeniden indirilir.

Bakım ve regresyon riski. Harry Roberts’ın karşıt görüşlü yazısı bu konuda en çok atıf alan değerlendirmedir. Uyarısı şudur: Critical CSS’yi sonradan uyarlamak zor ve hataya açıktır. CSS’nin darboğazınız olduğunu belirledikten sonra “you need to keep it that way… One wrong decision can undo everything.” (çeviri) “Böyle kalmasını sağlamalısınız… Tek bir yanlış karar her şeyi bozabilir.” Otomatik yeniden doğrulama yoktur; bir şablon veya tasarım değişikliği kritik/kritik olmayan ayrımınızı fark ettirmeden bozabilir.

Ertelemedeki zamanlama yarışları. Roberts, preload/onload değişiminin zamanlama açısından ters tepebileceğine de dikkat çeker: tarayıcının <head> bölümünü ayrıştırması 1 saniye, kritik olmayan CSS’yi asenkron getirmesi 0,5 saniye sürerse CSS’nin siz hazır olmadan 0,5 saniye önce yeniden senkron bir dosyaya dönüşeceğini belirtir. Kritik olmayan CSS geç ulaştığında stillenmemiş içerik parlaması ve düzen kayması riski de doğar.

Çoğu zaman darboğaz CSS değildir. Roberts’ın temel tezi şudur: Critical CSS’nin yalnızca en büyük oluşturma engelleyici darboğaz CSS ise yardımcı olduğunu ve çoğu zaman durumun böyle olmadığını söyler. DebugBear da aynı görüştedir: Satır içine almadan önce sorunun gerçekten CSS olup olmadığını kontrol edin; çünkü hâlâ oluşturmayı engelleyen JavaScript kodunuz varsa CSS’yi satır içine almanın yardımcı olma ihtimali düşüktür ve “often it’s not the most impactful optimization.” (çeviri) “Çoğu zaman en etkili optimizasyon bu değildir.”

Üretim tuzakları: CSP, durum ve fontlar

Hızlı bir demoda görünmeyen, ancak canlıya çıktıktan sonra can yakan üç hata modu daha var:

CSP politikası satır içi <style> bloğunuzu tamamen engelleyebilir. Content-Security-Policy style-src politikası, politika açıkça izin vermediği sürece satır içi kritik <style> bloğunu engelleyebilir; genellikle izin nonce veya eşleşen bir hash ile verilir. MDN ihlal durumlarını ve nonce/hash mekanizmalarını belgeler. Konsol hatasını susturmak için unsafe-inline kullanmak site genelinde politikayı zayıflatır ve varsayılan çözüm değildir. Nonce/hash üretimini Critical CSS’yi ayıklayan araca bağlayın ve yayına çıktıktan sonra tarayıcı konsolunda ihlal olup olmadığını kontrol edin.

“Yakalama sırasında kullanılmadı” ile “ertelenmesi güvenli” aynı şey değildir. Coverage sekmesi, tek bir kayıtlı çalıştırma sırasında hangi CSS’nin yürütüldüğünü söyler. Güvenli bir ayrım; basamaklandırma sırasını ve gerçek duyarlı kırılma noktalarınız, tema varyantlarınız, kişiselleştirilmiş içerik, odak durumları, açık menü/modal durumları ve hata durumları için gereken kuralları korumalıdır — o geçişte tesadüfen oluşturulanları değil. Roberts aynı soruyu başka açıdan sorar: ayıklamanız hangi görünüm alanını ve hangi ekran dışı ya da etkileşilmemiş öğeleri (açılır menüler, uçan paneller) gerçekten kapsamalı?

Font sorununu çözmez ve oluşturma işini artırabilir. Öğe stillerini satır içine almak bir web fontunun daha erken keşfedilmesini veya metnin zamanında oluşturulmasını tek başına sağlamaz; font keşfi, preload, font-display ve yedek metrikler Critical CSS’nin dokunmadığı ayrı bağımlılıklardır. Ayrıca küçük bir satır içi alt kümenin ardından daha büyük bir stil dosyası uygulamak ek stil yeniden hesaplama, düzen ve boyama işi anlamına gelebilir; getirme gecikmesini azaltmak toplam oluşturma işinin de azalacağı anlamına gelmez. Yalnızca ağ şelalesini değil ikisini de ölçün.

Gerçekten ihtiyacınız olup olmadığını nasıl teşhis edersiniz

Bütün bunlar ışığında “Critical CSS ekle” diye başlamayın; “CSS’nin oluşturma darboğazım olduğunu doğrula” diye başlayın ve orada durmayın. Buna değmesi için dört kapının da geçilmesi gerekir:

1. CSS tahmin değil, kanıtlanmış bir engelleyicidir.

  • PageSpeed Insights / Lighthouse raporunu açın. Lighthouse 13 itibarıyla eski “Eliminate render-blocking resources” denetimi Render-blocking requests içgörüsüne taşındı; bu nedenle eski denetim adını kullanan makaleler güncelliğini yitirmiştir.
  • İlk boyamada CSS’nizin (ve JS’nizin) ne kadarının gerçekten kullanılmadığını görmek için Chrome DevTools’taki Coverage sekmesini kullanın.
  • Nedenleri ayırın. Darboğazınız oluşturmayı engelleyen JavaScript veya yavaş bir sunucu yanıtı (TTFB) ise CSS’yi satır içine almak bunu düzeltmez; yanlış şeyi optimize etmiş olursunuz.

2. Gerçek kırılma noktalarınız, temalarınız, kişiselleştirmeniz ve etkileşimli durumlarınız boyunca gerçekten kararlı bir ayıklama kapsamı oluşturabilirsiniz — tek bir masaüstü ekran görüntüsüyle değil (yukarıdaki tuzaklara bakın).

3. Tekrarlanan görüntüleme ve CSP maliyeti kabul edilebilir. Satır içi CSS önbelleğe alınmaz; bunu tipik oturumunuzun ne kadar derin olduğuyla tartın. CSP style-src politikası çalıştırıyorsanız nonce/hash üretimi canlıya çıktıktan sonra keşfedilecek bir şey değil, yayından önce işlem hattına bağlanması gereken bir iştir.

4. Bunun bakımını gerçekten yapacaksınız. Her şablon veya tasarım değişikliğinde yeniden üretin ve tek bir gözle kontrol yerine tam test matrisini — soğuk ve tekrarlı yüklemeleri, desteklediğiniz her rota/görünüm alanı/durumu — yeniden çalıştırın.

Dört kapının tümü geçiliyorsa Critical CSS bakım maliyetine değer. Biri bile geçilmiyorsa kullanılmayan CSS’yi kaldırmak, küçültmek ve kritik olmayan stil dosyalarını media ile kapsamlandırmak gibi daha ucuz düzeltmeler daha iyi hamledir.

2026 için güncel bir sürpriz

Dikkat çekmeye değer güncel bir ayrıntı var: Google belgelerinin CSS’yi ertelemek için önerdiği tam <link rel="preload" as="style"> deseninin, bir Lighthouse/PSI nokta güncellemesinden sonra yeniden oluşturmayı engelleyen kaynak olarak işaretlenmeye başladığına ilişkin açık ve henüz çözümlenmemiş bir bildirim bulunuyor. GitHub issue #17031, önceden yüklenen CSS’nin Lighthouse 13.0.1’de yeşil gösterilirken 13.3.0’da oluşturmayı engelleyen kaynak olarak işaretlendiğini belgeliyor. Bu yazı hazırlanırken Google tarafından kamuya açıklanmış bir çözüm yoktu; dolayısıyla durumu gelişmekte olan bir konu olarak değerlendirin. Pratik ders yine de geçerlidir: PSI doğru biçimde ertelenmiş CSS’nizi işaretlerse denetimin kendisi hatalı olabilir; uygulamanızın bozuk olduğunu varsaymak yerine raporu eleştirel biçimde inceleyin.

Critical CSS SEO’ya yardımcı olur mu?

Dolaylı ve mütevazı biçimde. Birbirinden ayırmanız gereken iki nokta var:

  • CSS doğrudan bir sıralama sinyali değildir. Google’dan Martin Splitt, CSS sınıf adları hakkında şöyle demiştir: “I don’t think we care because the CSS class names are just that.” (çeviri) “Bunu önemsediğimizi sanmıyorum; CSS sınıf adları yalnızca adlardan ibaret.” Bu açıklama özellikle sınıf adlarıyla ilgilidir; ancak CSS tercihlerinizin sıralama girdisi olarak okunduğu yönündeki daha geniş efsaneyi de çürütür.
  • Hız, Core Web Vitals üzerinden küçük bir sinyaldir. Critical CSS ilk boyamayı iyileştirebilir; bu da Google’ın sayfa deneyimi sinyallerine katkıda bulunan bir Core Web Vitals metriği olan LCP’yi iyileştirebilir. SEO bağlantısının tamamı budur: Tekniğin kendisi için verilen bir avantaj değil, daha hızlı boyamadır.

Bu nedenle Critical CSS’nin SEO gerekçesi, sitenizdeki LCP etkisi kadar güçlüdür; Google’a ve performans topluluğuna göre bu etki çoğu zaman onu satan araçların ima ettiğinden küçüktür.

Bing ne olacak?

Bing’e özgü bir şey yok. Tekniği ele alan birden fazla web.dev sayfası ve bir codelab yayımlayan Google’ın aksine, Critical CSS’yi ele alan özel bir Bing/Microsoft belgesi bulamadım. Bing’in genel sayfa deneyimi rehberi geçerlidir (hızlı tutun, kritik içeriğe erişilebilir tutun); ancak web.dev’in Critical CSS codelab’inin Bing karşılığı yoktur. Bing’in özel bir Critical CSS tavsiyesi olduğunu söyleyen kişi bunu uyduruyordur.

Bu sayfanın yeri

Bu sayfa critical rendering path merkezinin altında yer alır; Critical CSS bu yolu kısaltmak için kullanılan taktiklerden biridir. render-blocking resources sayfasının pratik kardeşidir. Kazanç varsa Largest Contentful Paint (LCP), First Contentful Paint (FCP) ve daha geniş Core Web Vitals kümesinde görünür. Daha geniş performans resmi için web performance kümesine bakın.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.