Critical CSS Nedir, Nasıl Çıkarılır

PageSpeed Insights raporunda "Render engelleyen kaynakları ortadan kaldırın" satırının altında kendi style.css dosyanızı gördüyseniz, karşılaştığınız sorunun adı belli: tarayıcı, sayfanın tek bir pikselini bile çizmeden önce o CSS dosyasının tamamen inmesini bekliyor. Critical CSS tam olarak bu beklemeyi ortadan kaldırmak için var. Fikir basit: kullanıcının ilk açılışta gördüğü ekranı çizmeye yetecek kadar stili doğrudan HTML'in içine gömersin, geri kalan devasa CSS dosyasını ise sayfa çizildikten sonra arka planda yüklersin.

Bu rehberde tarayıcının CSS'i neden bir "engel" olarak gördüğünü, kritik stilin sınırlarını nasıl belirleyeceğini, bu stili elle veya otomatik araçlarla nasıl çıkaracağını, çıkardığın kodu sayfaya nasıl doğru yerleştireceğini ve WordPress gibi hazır sistemlerde işin nasıl yürüdüğünü anlatacağım. Sonunda da bu tekniği uygularken en çok tökezlenen noktaları — bayatlayan kritik stil, şişmiş inline blok, sayfa tipine göre değişen ilk ekran — tek tek göreceksin.

Tarayıcı Sayfayı Neden CSS'i Bekleyerek Çizer#

Tarayıcı bir HTML belgesini indirdiğinde iki ayrı ağaç kurar: DOM (belge yapısı) ve CSSOM (stil kuralları). Ekrana çizim yapabilmesi için ikisine de ihtiyacı vardır, çünkü bir div'in ekranda nerede duracağını bilmeden onu boyayamaz. HTML'i parça parça alıp işleyebilir ama CSS için aynı şey geçerli değildir: bir stil dosyasının son satırı, ilk satırdaki bir kuralı tamamen geçersiz kılabilir. Bu yüzden head içindeki her link rel="stylesheet" etiketi varsayılan olarak render engelleyicidir; dosya tamamen inip ayrıştırılana kadar ekran boş kalır.

Sorun sadece dosyanın boyutu da değildir. Aradaki ağ turu, bağlantı kurulumu ve sunucunun yanıt süresi de bu beklemeye eklenir. 200 KB'lık bir CSS dosyası hızlı bir bağlantıda 100 ms'de inebilir ama üçüncü parti bir alan adından geliyorsa DNS + TCP + TLS maliyeti eklenir ve toplam kolayca 400-500 ms'ye çıkar. Bu sürenin tamamı, kullanıcının bomboş beyaz ekrana baktığı süredir ve doğrudan First Contentful Paint ile LCP değerine yansır. Aşağıdaki tablo, head içindeki farklı kaynakların çizimi engelleyip engellemediğini özetliyor:

Critical CSS tekniği bu tablonun ikinci ve üçüncü satırından beslenir: kritik stili inline style bloğuna koyar, tam dosyayı ise engellemeyen bir yöntemle sonradan yükletirsin.

Critical CSS Tam Olarak Neyi Kapsar#

"Kritik" kelimesi burada "ilk görünen ekranı doğru çizmek için gereken" anlamına gelir. Yani kullanıcı sayfayı açtığında kaydırma yapmadan gördüğü alandaki her öğenin stili kritiktir: gövde tipografisi, renk değişkenleri, header ve navigasyon, hero bölümü, ilk başlık, varsa üstteki buton veya arama kutusu, düzeni oluşturan grid/flex kuralları. Kaydırınca gelen bölümler, footer, modal pencereler, hover animasyonları, ikinci sekmedeki içerik — bunların hiçbiri kritik değildir.

Burada dikkat etmen gereken şey, "ilk ekran"ın sabit bir şey olmamasıdır. 390 piksel genişliğindeki bir telefonda ilk ekran header + başlık kadarken, 1440 pikselde hero görselinin altındaki üç kart da görünür. Bu yüzden ciddi kurulumlarda kritik stil en az iki çözünürlük için çıkarılır ve birleştirilir. Ayrıca sayfa tipine göre de değişir: ana sayfanın ilk ekranı ile bir blog yazısının ilk ekranı aynı bileşenleri kullanmaz.

Pratik bir sınır da vardır: inline blok ne kadar büyürse HTML belgesi o kadar şişer ve inline CSS önbelleklenemez, çünkü belgenin bir parçasıdır. Kullanıcı ikinci sayfaya geçtiğinde o bloğu bir kez daha indirir. Deneyimime göre sıkıştırılmadan 10-15 KB civarında bir kritik blok tatlı noktadır; 40 KB'a çıktığında kazandığın süreyi belge boyutuyla geri vermeye başlarsın. Kritik stilin küçük kalması için önce kullanmadığın kuralları temizlemek işe yarar; bunun için kullanılmayan CSS'i temizleme yazısındaki yöntemleri bu işten önce uygulaman ciddi fark yaratır.

Kritik Stili Elle Çıkarmak#

Küçük ve tek şablonlu bir sitede kritik stili elle çıkarmak hem mümkün hem de en temiz sonucu verir, çünkü hangi kuralın gerçekten gerektiğine sen karar verirsin. Yöntem şudur:

1. Chrome DevTools'u aç, Ctrl+Shift+P ile komut çubuğunu çağır ve Show Coverage yaz.
2. Coverage sekmesinde yeniden yükle düğmesine bas; sayfa yüklendiğinde CSS dosyalarının kullanılan/kullanılmayan oranını görürsün.
3. Dosyaya tıkla; sol tarafta yeşil çubukla işaretli satırlar o yüklemede gerçekten uygulanan kurallardır.
4. Sayfayı hiç kaydırmadan ölçüm yaparsan, yeşil kısımlar kabaca kritik CSS'e denk gelir.
5. Bu kuralları ayrı bir critical.css dosyasına kopyala; değişkenler (:root), reset ve tipografi bloklarını mutlaka al.

Elle yaklaşımın en büyük avantajı, otomatik araçların sık sık kaçırdığı iki şeyi doğru yapabilmendir: CSS custom property tanımları ve @font-face blokları. Coverage bunları bazen "kullanılmadı" gösterir çünkü doğrudan bir seçiciye bağlı değildir, ama onlar olmadan sayfa yanlış çizilir.

/* critical.css — sadece ilk ekran */
:root{--renk-metin:#1a1a1a;--renk-vurgu:#0f62fe;--baslik-font:'Inter',system-ui,sans-serif}
*,*::before,*::after{box-sizing:border-box}
body{margin:0;font-family:var(--baslik-font);color:var(--renk-metin);line-height:1.6}
.site-header{display:flex;align-items:center;justify-content:space-between;padding:16px 24px}
.hero{min-height:420px;display:flex;flex-direction:column;justify-content:center;padding:0 24px}
.hero h1{font-size:clamp(1.8rem,4vw,3rem);margin:0 0 12px}
.hero .btn{display:inline-block;background:var(--renk-vurgu);color:#fff;padding:12px 24px;border-radius:6px;text-decoration:none}

Otomatik Araçlarla Critical CSS Üretme#

Birden fazla şablonu olan bir sitede elle çıkarmak sürdürülebilir değildir; her tasarım değişikliğinde işlemi tekrarlaman gerekir. Bu yüzden otomatik araçlar build sürecine bağlanır. En yaygın ikisi critical ve penthouse paketleridir; ikisi de arka planda başsız bir tarayıcı çalıştırıp sayfayı belirlediğin çözünürlükte açar, uygulanan kuralları toplar ve sana bir CSS metni döner.

# Node.js kurulu bir makinede
npm install --save-dev critical

# Tek bir URL için kritik CSS üret ve dosyaya yaz
npx critical https://firmaniz.com/ \
  --base dist/ \
  --width 1300 --height 900 \
  --extract false > dist/critical-home.css

# Mobil ilk ekran için ayrı bir üretim
npx critical https://firmaniz.com/ \
  --base dist/ \
  --width 390 --height 844 \
  --extract false > dist/critical-home-mobil.css

Bu iki çıktıyı birleştirip tekilleştirmek, tek bir geniş ekran ölçümünden çok daha güvenilir sonuç verir. Kritik olan nokta şu: bu adımı her yayına alma sürecinde çalıştır. Kritik CSS'in en büyük düşmanı bayatlamasıdır; temayı değiştirirsin, hero bölümüne yeni bir öğe eklersin ama inline blok eski kalır ve kullanıcı yarım saniye boyunca bozuk bir düzen görür. Bir package.json script'ine bağlamak bunu çözer:

{
  "scripts": {
    "build": "vite build && npm run critical",
    "critical": "node scripts/critical.mjs"
  }
}

Çıkarılan Stili Sayfaya Doğru Yerleştirme#

Kritik CSS'i ürettikten sonra iki şey yapman gerekir: onu head içine inline gömmek ve tam CSS dosyasını render'ı engellemeyecek şekilde yüklemek. İkinci kısım için en yaygın ve en sağlam yöntem, media niteliğiyle oynamaktır. Tarayıcı media="print" olan bir stil dosyasını ekran çizimi için beklemez; dosya indiğinde onload ile media değerini all yaparsın ve stil devreye girer.

<head>
  <meta charset="utf-8">
  <title>Firmanız</title>

  <!-- 1) Kritik stil: doğrudan belgede, ağ turu yok -->
  <style>
    :root{--renk-vurgu:#0f62fe}body{margin:0;font-family:system-ui,sans-serif}
    .site-header{display:flex;justify-content:space-between;padding:16px 24px}
    .hero{min-height:420px;display:flex;flex-direction:column;justify-content:center}
  </style>

  <!-- 2) Tam CSS: indirilir ama çizimi engellemez -->
  <link rel="stylesheet" href="/assets/style.css" media="print" onload="this.media='all';this.onload=null">
  <noscript><link rel="stylesheet" href="/assets/style.css"></noscript>
</head>

noscript yedeği önemlidir: JavaScript kapalı bir tarayıcıda onload çalışmaz ve site stilsiz kalırdı. Alternatif yöntem rel="preload" as="style" kullanmaktır; ikisi de aynı sonucu verir, ancak media numarası daha eski tarayıcılarda da sorunsuz çalıştığı için ben onu tercih ediyorum. preload ile prefetch arasındaki farkı ve as niteliğinin neden zorunlu olduğunu merak ediyorsan preload, prefetch ve preconnect farkı yazısında ayrıntılı anlattım.

Bir de sıralama kuralı var: inline kritik blok, ertelenen link etiketinden önce gelmeli. Aksi halde tam dosya erken inerse kritik blokla çakışır ve özgüllük sırası beklediğin gibi çalışmaz.

WordPress ve Hazır Sistemlerde Uygulama#

Kendi build sürecin yoksa, WordPress tarafında bu işi önbellek eklentileri üstlenir. LiteSpeed Cache, WP Rocket ve benzeri eklentilerin hepsinde "Critical CSS" ya da "Kritik CSS Üretimi" başlıklı bir seçenek bulunur; eklenti sayfa tiplerini tarar, her tip için ayrı bir kritik blok üretir ve geri kalan CSS'i erteler. LiteSpeed kullanıyorsan sunucu tarafındaki ayarlarla birlikte nasıl yapılandırılacağını LiteSpeed Cache rehberinde bulabilirsin.

Buradaki en kritik ayar, üretimin sayfa tipi başına yapılmasıdır. Ana sayfa, kategori sayfası, tekil yazı ve ürün sayfası farklı şablonlar kullanır; tek bir kritik blok hepsine uygulanırsa bazı sayfalarda ilk ekran yanlış çizilir. Eklentiler genelde bunu otomatik yapar ama üretim kuyruğu bir cron işine bağlıdır ve o cron çalışmıyorsa kritik CSS hiç üretilmez. Yayına aldıktan sonra sayfanın kaynağına bakıp style bloğunun gerçekten dolu olduğunu doğrula.

# Kritik blok gerçekten belgeye gömülmüş mü, kaç bayt?
curl -s https://firmaniz.com/ | grep -o '<style[^>]*>' | head
curl -s https://firmaniz.com/ | wc -c

Belge boyutunun 100 KB'ı geçtiğini görüyorsan kritik blok şişmiş demektir; eklentinin "yalnızca ilk ekran" ayarını sıkılaştır. Sunucu tarafında gzip/brotli açıksa bu bloğun ağdaki maliyeti epey düşer; .htaccess ile sıkıştırmayı nasıl açacağını htaccess önbellek ve sıkıştırma yazısında bulabilirsin.

Sık Yapılan Hatalar ve Tuzaklar#

Kritik bloğu güncellememek. Bu, listenin bir numarasıdır. Tema veya bileşen değişir, inline blok eski kalır ve kullanıcı yarım saniye boyunca yanlış hizalanmış bir header görür, sonra düzelir. Bu titremeye "flash of unstyled content" denir ve düzen kayması olarak Core Web Vitals'a da yansır. Kritik CSS üretimini build'e bağlamazsan bu er ya da geç başına gelir.

Her şeyi kritik saymak. "Ne olur ne olmaz" diye tüm CSS'i inline eden kurulumlar gördüm; sonuç, ilk baytın gecikmesi ve önbelleklenemeyen dev bir belgedir. Kritik CSS bir kısaltmadır, bir kopyalama işlemi değil.

@font-face ve font yüklemesini unutmak. Kritik blokta metnin fontu tanımlı değilse tarayıcı sistem fontuyla çizer, sonra gerçek fontla yeniden çizer. Bunu tamamen ortadan kaldıramazsın ama font-display: swap kullanımı ve font preload'u ile öngörülebilir hale getirebilirsin.

Görselleri hesaba katmamak. İlk ekrandaki hero görselinin width/height veya aspect-ratio değeri kritik blokta yoksa, görsel indiğinde altındaki her şey aşağı kayar. Kritik CSS'in görevi sadece renk vermek değil, yer ayırmaktır.

Test etmeden yayına almak. Kritik CSS uyguladıktan sonra JavaScript'i kapatıp sayfayı aç; tam CSS yüklenmeden ekranın nasıl göründüğünü gör. Bu, kullanıcının ilk 300 ms'de gördüğü şeydir.

Sonucu Ölçmek#

Değişikliğin gerçekten işe yarayıp yaramadığını gözle değil sayıyla doğrula. Lighthouse'u değişiklikten önce ve sonra aynı koşullarda çalıştır, özellikle First Contentful Paint ve LCP değerlerine bak. Beklenen kazanç, engellenen CSS'in indirme süresine yakın bir düşüştür — hızlı bir sunucuda 100-200 ms, yavaş bir üçüncü parti CSS'te 500 ms'yi bulabilir.

DevTools'un Performance sekmesinde ağ throttling'i "Slow 4G" yapıp kaydettiğinde farkı çıplak gözle de görürsün: kritik CSS öncesinde ilk boya, stylesheet'in bitiş çizgisiyle aynı hizadadır; sonrasında ise HTML belgesinin bitişine yapışır. Dış araçlarla ölçmek istersen GTmetrix ile hız testi yazısındaki adımlar aynı karşılaştırmayı yapmanı sağlar.

Sıkça Sorulan Sorular#

Critical CSS kaç KB olmalı#

Kesin bir üst sınır yok ama pratikte sıkıştırılmamış halde 10-15 KB arasında kalmayı hedefle. Bu boyut, HTML belgesine eklendiğinde ilk yanıtın tek bir ağ paketi turunda gitmesine yakın kalır ve sıkıştırıldığında birkaç KB'a iner. 40 KB'ı aşan bir kritik blokta genellikle kaydırma altındaki bölümler de kritik sayılmıştır; üretim ayarlarını gözden geçirmen gerekir.

Critical CSS ile kullanılmayan CSS temizliği aynı şey mi#

Hayır, ikisi farklı işler yapar ama birbirini tamamlar. Kullanılmayan CSS temizliği, hiçbir sayfada uygulanmayan kuralları dosyadan tamamen atar ve toplam boyutu düşürür. Critical CSS ise kalan geçerli kuralların içinden yalnızca ilk ekrana ait olanları ayırır ve onları belgeye gömer. Önce temizlik yapıp sonra kritik stil çıkarmak en verimli sıradır.

Her sayfa için ayrı critical CSS gerekir mi#

Şablon başına ayrı üretmek doğru yaklaşımdır, her URL için değil. Ana sayfa, kategori/arşiv sayfası, tekil içerik sayfası ve varsa ürün sayfası genellikle farklı ilk ekranlara sahiptir; bu dört tip için dört ayrı blok üretmek çoğu siteyi kapsar. Aynı şablonu kullanan yüzlerce yazı sayfası için tek bir kritik blok yeterlidir.

Critical CSS SEO'ya zarar verir mi#

Hayır. Arama motorları sayfayı tarayıcı gibi işler ve ertelenen stylesheet'i de yükler, dolayısıyla nihai görünüm aynıdır. Aksine, ilk boya süresini kısalttığı için sayfa deneyimi sinyallerine olumlu katkı yapar. Tek risk, kritik bloğun bayatlaması sonucu sayfanın bir süre bozuk görünmesidir; bu da kullanıcı deneyimi sorunudur, dizine ekleme sorunu değil.

JavaScript kapalıysa sayfa stilsiz mi kalır#

media="print" numarasını kullanıyorsan ve noscript içine normal bir stylesheet bağlantısı koyduysan hayır, sayfa tam stille açılır. Bu yedek satırı atlarsan JavaScript'i kapalı kullanıcılar yalnızca kritik bloğu görür ve sayfanın alt kısımları biçimsiz kalır. Bu yüzden noscript bloğunu isteğe bağlı değil, kurulumun bir parçası olarak düşün.

Kritik CSS'i her deploy'da yeniden üretmek şart mı#

Şart olmasa da güçlü bir öneri. CSS dosyanız veya şablonlarınız değiştiğinde kritik blok teknik olarak geçersizleşir; ne kadar beklerseniz kullanıcının gördüğü ilk kare ile gerçek tasarım o kadar ayrışır. Üretimi build script'ine bağlarsan bu tamamen otomatikleşir ve unutma ihtimali kalmaz. Değişiklik yapmadığın dönemlerde yeniden üretimin bir maliyeti de yoktur.

Kapanış#

Critical CSS'i tek cümleye indirgersek: kullanıcının ilk gördüğü ekranın stilini belgeye gömer, geri kalanını ertelersin. Akılda tutulması gereken dört alışkanlık şudur — kritik bloğu küçük tut (10-15 KB), şablon tipi başına ayrı üret, üretimi build sürecine bağlayarak bayatlamasını engelle ve ertelenen dosya için mutlaka bir noscript yedeği bırak. Öncesinde kullanılmayan kuralları temizlemek, hem kritik bloğu hem toplam CSS'i belirgin biçimde küçültür.

Bu tür optimizasyonların kazancı, sunucunun ilk baytı ne kadar hızlı gönderdiğiyle doğrudan ilişkilidir; yavaş bir barındırmada kritik CSS'in kazandırdığı 200 ms, TTFB'de kaybedilen 800 ms'yi kapatmaz. Hızlı NVMe diskli ve LiteSpeed çalışan web hosting veya WordPress hosting paketlerimiz bu tabanı sağlamlaştırır; daha fazla kontrol istiyorsan kendi build sürecini çalıştırabileceğin VDS sunucularımıza geçebilir, optimizasyonun tamamını bize bırakmak istersen sunucu yönetimi hizmetimizden yararlanabilirsin.