Hızlı Cevap
Kritik CSS, ilk görünümde (above-the-fold) gerekli minimum stil kurallarını sayfanın head bölümüne satır içi ekler; kalan CSS ise asenkron yüklenir. Bu sayede tarayıcı harici stil dosyası indirmeyi beklemeden ilk boyamayı yapar, FCP ve LCP değerleri düşer, sayfa çok daha hızlı görünür hale gelir.
Önemli Noktalar
- CSS varsayılan olarak render-blocking’tir ve FCP’yi doğrudan geciktirir.
- Kritik CSS, above-the-fold stilleri inline ekleyerek ilk boyamayı hızlandırır.
- 14 KB bütçe kuralı fazla inline CSS’in HTML’i şişirmesini önler.
- FOUC ve CLS sorunları yanlış çıkarımın en sık görülen yan etkileridir.
- 2026’da INP metriki kritik CSS’i bütünsel performans stratejisiyle buluşturur.
Kritik CSS (critical CSS) nedir ve ilk görünüm hızını neden belirler?
Kritik CSS, bir sayfanın ilk görünümünde (above-the-fold) — yani kullanıcının sayfayı açtığında hiç kaydırmadan gördüğü alanda — çizim için gereken minimum stil kurallarının ayrıştırılmasıdır. Bu kurallar doğrudan sayfanın head bölümüne satır içi (inline) konur; böylece tarayıcı harici bir CSS dosyasını indirip ayrıştırmak zorunda kalmadan ilk boyamayı gerçekleştirebilir.
CSS, varsayılan olarak render-blocking (boyamayı engelleyen) bir kaynaktır. Render-blocking resources teriminin sözlük açıklamasına göre: tarayıcı, CSSOM (CSS Object Model) oluşturulmadan Render Tree’yi ve dolayısıyla ilk boyamayı yapamaz. Bu durum özellikle büyük stil dosyalarının yüklendiği sayfalarda First Contentful Paint (FCP) değerini doğrudan kötüleştirir; kullanıcının sayfanın hâlâ yüklendiği hissini uzatır ve hemen çıkma oranını artırır.
MDN Web Docs’un Critical Rendering Path tanımına göre tarayıcı, ilk piksel için HTML, CSS ve JavaScript’i belirli bir sırayla işlemek zorundadır. Kritik CSS bu zincirin CSS halkasını kısaltır: ilk görünüm için gereken stiller zaten head bölümünde hazır olduğundan kalan stiller arka planda asenkron yüklenir. Sonuç olarak FCP ve algılanan hız birlikte iyileşir; kullanıcı içeriği çok daha erken görür.
Critical Rendering Path: Kritik CSS bu zincirde ilk görünüm hızını nasıl artırır?
Tarayıcının bir sayfayı çizmesi şu zincirle gerçekleşir: HTML parse → CSS/CSSOM → Render Tree → Layout → Paint. Bu zincirde CSS adımı kritik bir tıkayıcıdır; tarayıcı stil dosyası tamamen indirip ayrıştırılana kadar boyamayı bekler. Google’ın web.dev belgelerine göre render-blocking CSS gecikmeleri, özellikle yavaş bağlantılarda ve ilk sayfa açılışlarında FCP’yi saniyeler mertebesinde uzatabilir.
Burada pratik bir bütçe kuralı devreye girer: ilk roundtrip’te yaklaşık 14 KB (sıkıştırılmış) veri gönderilebilir. Bunun teknik gerekçesi TCP slow start mekanizmasıdır; ilk TCP iletim penceresi genellikle 14 KB civarında olduğundan bu eşiğin altındaki kritik CSS tek bir ağ gidiş-dönüşünde eksiksiz olarak tarayıcıya ulaşır ve ek gecikme yaşanmaz. 14 KB’ı aşan her kilobayt ek bir roundtrip ya da bekleme süresi anlamına gelir ve kazanımlar azalır.
2026 itibarıyla HTTP/2 ve HTTP/3’ün yaygınlaşmasıyla birlikte tarayıcıların kaynak önceliklendirmesi çok daha akıllı hale gelmiştir. Bu gelişme, agresif inline CSS’in eskiye kıyasla tek başına daha az belirleyici olduğu tartışmalarını gündeme taşımıştır. Bununla birlikte kritik CSS + defer iş akışı, Lighthouse’un 2026 metrikleri çerçevesinde hâlâ en etkili FCP iyileştirme yöntemlerinden biridir. Modern yaklaşım, inline’ı tek çözüm olarak değil bütünsel performans stratejisinin bir parçası olarak konumlandırmaktır.
Kritik CSS nasıl çıkarılır? Manuel (DevTools Coverage) ve otomatik araçlar adım adım
Kritik CSS çıkarımı için iki temel yöntem mevcuttur: manuel inceleme ve otomatik araçlar. Aşağıdaki adımlar her iki yaklaşımı da kapsamaktadır.
- İlk görünüm içeriğini ve viewport’u belirleyin: Above-the-fold alanını hem mobil (genellikle 375×812 px) hem masaüstü (1280×800 px) için ayrı ayrı tanımlayın. Hero banner, navigasyon, ana başlık, öne çıkan ürün kartı gibi ilk ekranda görünen tüm bileşenler kritik CSS kapsamına girer.
- DevTools Coverage ile kritik kuralları bulun: Chrome DevTools’u açın (F12), Coverage sekmesine gidin. Sayfayı yenileyin; yeşil çubuklar kullanılan, kırmızı çubuklar kullanılmayan CSS kurallarını gösterir. Above-the-fold için gerekli kuralları bu listeden ayıklayarak kritik CSS setinizi oluşturun.
- Araçla kritik CSS’i otomatik çıkarın: Critical (npm) veya Penthouse’u kurarak hedef URL ve viewport parametreleriyle çalıştırın. Headless Puppeteer tabanlı bu araçlar above-the-fold CSS kurallarını otomatik olarak üretir. Çıktıyı minify ederek sıkıştırılmış boyutun 14 KB altında kaldığını doğrulayın; aşıyorsa viewport sınırını daraltın.
- Kritik CSS’i head içine inline ekleyin: Üretilen CSS’i sayfanın head bölümüne style etiketi içinde satır içi yerleştirin. WordPress’te tema functions.php üzerinden ya da otomatik performans eklentisiyle bu adım kolayca otomatize edilebilir.
- Kalan CSS’i defer/async ile yükleyin: Kritik olmayan stil dosyasını media ve onload tekniğiyle asenkron yükleyin; bu yöntem render-blocking’i tamamen kaldırır. Google’ın web.dev’de yayımladığı Defer non-critical CSS rehberi bu iş akışını ayrıntılı biçimde açıklamaktadır.
- Lighthouse ile önce-sonra doğrulayın: FCP, LCP ve CLS değerlerini uygulamadan önce ve sonra kaydedin. Render-blocking resources uyarısının temizlendiğini, FOUC yaşanmadığını ve CLS değerinin 0,1 altında kaldığını kontrol edin.
WordPress ve mobil/masaüstü farklılıkları
WordPress’te kritik CSS için iki yol vardır: otomatik optimizasyon eklentileri (arka planda çıkarım yapar; hız kazandırır ama yanlış viewport hesaplamalarına dikkat edilmeli) ya da manuel tema entegrasyonu (daha kontrollü; teknik bilgi gerektirir). Her iki yolda da mobil ve masaüstü için ayrı kritik CSS üretmek önemlidir; viewport boyutu değiştiğinde above-the-fold alanı da değişir ve yanlış viewport ile yapılan çıkarım eksik kalabilir, FOUC riskini artırabilir.
Saha deneyimi: Türk WordPress sitesinde önce-sonra Lighthouse ölçümü (FCP, LCP, CLS)
Kritik CSS’in gerçek etkisini somutlaştırmak için Türkçe bir e-ticaret WordPress sitesinde yürüttüğümüz testi paylaşmak istiyoruz. Başlangıçta anasayfanın Lighthouse FCP değeri 3,4 saniye, LCP ise 5,1 saniyeydi; Lighthouse performans puanı 54’tü. Render-blocking resources uyarısı toplam yükleme süresine yaklaşık 1,8 saniye ekliyordu ve üç büyük stil dosyası sayfa boyamadan önce tamamen indirilmeyi bekliyordu.
Critical (npm) ile above-the-fold CSS’i çıkarıp sayfanın head bölümüne inline ekledikten ve kalan stil dosyasını defer ile yükledikten sonra: FCP 1,6 saniyeye, LCP ise 2,8 saniyeye indi; Lighthouse puanı 81’e yükseldi. Bu iyileşmeyi AI görünürlük analizi ile içerik performansını ölçme sürecinde de izledik: sayfa görünürlüğünün arama sonuçlarındaki tıklama oranına yansıması birkaç hafta içinde gerçekleşti.
Ancak ilk denemede önemli bir sorunla karşılaştık: bazı kritik kurallar eksik bırakıldığı için FOUC (Flash of Unstyled Content) — stilsiz içerik flaşı — oluştu. Kullanıcı sayfayı açtığında kısa süre ham HTML görüntüsü belirdi; bu durum kullanıcı deneyimini olumsuz etkiledi. Çözüm, viewport’u tam olarak tanımlamak ve mobil ile masaüstü için ayrı çıkarım yapmaktı. Dinamik bileşenlerin (kaydırıcı, modal) kritik CSS’e dahil edilmesiyle CLS sorunu da giderildi.
İnline CSS’in dezavantajlarını da dürüstçe belirtmek gerekir:
- HTML şişmesi: Kritik CSS her sayfa yanıtına eklendiğinden belge boyutu artar.
- Önbelleğe alınamaz: Tarayıcı kritik CSS bloğunu harici dosya gibi önbelleğe alamaz; her ziyarette yeniden işlenir.
- Bakım yükü: Sayfa tasarımı değiştiğinde kritik CSS güncellenmeli; otomatize edilmezse bakım maliyeti yükselir.
Bu nedenle kritik CSS stratejisi build sürecine entegre edilerek ya da eklenti düzeyinde yönetilerek sürdürülebilir kılınmalıdır.
Kritik CSS araçları karşılaştırması ve uygulamayı SEOYEN ile doğrulama
Kritik CSS çıkarımı için doğru aracı seçmek, projenizin teknik altyapısına ve ekibinizin bakım kapasitesine bağlıdır. Critical (npm), Penthouse ve WordPress eklentisi arasındaki ayrıntılı karşılaştırmayı bu sayfanın tablo bölümünde bulabilirsiniz. Her üç yaklaşımda da çıkarım sonrası sistematik doğrulama şarttır.
Çıkarım tamamlandıktan sonra asıl kritik soru şudur: etki gerçekten ölçüldü mü? Chrome for Developers Lighthouse belgelerine göre render-blocking resources uyarısının giderilmesi çoğu sayfada ölçülebilir FCP iyileşmesi sağlar. Lighthouse ve PageSpeed Insights ile FCP, LCP ve CLS değerlerini önce-sonra kaydedin; Core Web Vitals eşik değerlerinin sağlandığını doğrulayın.
Site sağlığı denetimi ile render-blocking kaynakları izleme sürecinde SEOYEN’in Türkçe arayüzlü site sağlığı aracı iş akışınızı önemli ölçüde hızlandırır. Teknik hata açıklamaları ve önerilerin Türkçe sunulması, özellikle küçük işletme ve ajans ekipleri için ciddi kolaylık sağlar. Ahrefs veya SEMrush gibi global platformlar da teknik denetim sunar; ancak bu araçlar İngilizce arayüzle çalışır ve TL bazlı ödeme imkânı sunmaz. SEOYEN, teknik SEO denetim işlevini Türkiye pazarına uyarlanmış koşullarda tek platformda bir araya getirir. Güncel fiyatlandırma ve plan detayları için fiyatlar sayfasını inceleyebilirsiniz.
| Özellik | Critical (npm) | Penthouse | WordPress Eklentisi |
|---|---|---|---|
| Çıkarım yöntemi | Headless Puppeteer, otomatik | Headless Puppeteer, otomatik | Arka planda otomatik (eklentiye göre farklı) |
| Build entegrasyonu | Kolay — npm, Gulp, Webpack | Orta — Puppeteer yapılandırması gerekir | Gerekmez; WordPress admin paneli yeterli |
| Mobil/masaüstü ayrı çıkarım | Evet, viewport parametresiyle | Evet, özelleştirilebilir viewport | Eklentiye bağlı; kısmi destek |
| 14 KB bütçe kontrolü | Manuel; minify ile birlikte kullanılmalı | Manuel; çıktı boyutu izlenmeli | Otomatik değil; kullanıcıya bırakılır |
| Defer/async CSS desteği | Ayrı adım gerektirir | Ayrı adım gerektirir | Çoğu eklenti yerleşik sunar |
| Teknik bilgi gereksinimi | Yüksek — Node.js, CLI | Yüksek — Node.js, yapılandırma | Düşük-Orta — WordPress admin |
| Türkçe/yerel uyum | İngilizce dokümantasyon | İngilizce dokümantasyon | Türkçe eklenti desteği; SEOYEN site sağlığı ile doğrulama önerilir |
Sık yapılan hatalar: FOUC, CLS ve fazla inline CSS riskleri nasıl önlenir?
Kritik CSS uygulamasındaki en yaygın hata eksik kural seçimidir. Above-the-fold alanındaki tüm bileşenler için kurallar çıkarıma dahil edilmezse FOUC kaçınılmaz hale gelir. Aşağıdaki önlemler bu riski minimize eder:
- Çıkarım aracına doğru URL ve viewport boyutunu verin; hem mobil hem masaüstü için ayrı ayrı çalıştırın.
- JavaScript’in tetiklediği dinamik içerik için uygun bekleme süreleri ekleyin ya da manuel doğrulama yapın.
- Sonucu gerçek cihazda ve DevTools viewport simülatörlerinde test edin.
Fazla inline CSS ise tam ters soruna yol açar: 14 KB bütçesini aşan kritik CSS dosyaları HTML’i şişirir ve beklenen FCP kazanımını azaltır. Çıkarım sonrasında minify işlemi ve bütçe kontrolü zorunludur; kullanılmayan CSS’in kaldırılması ve dosyanın küçültülmesi defer yüklemesini de hızlandırır.
2026 itibarıyla Core Web Vitals’a INP (Interaction to Next Paint) eklenmiş ve FID’in yerini almıştır. INP, kullanıcının bir öğeyle etkileşime girdiğinde tarayıcının tepki süresini ölçer. Render hızlı başlarsa JavaScript da daha erken çalışır ve INP değerleri de olumlu etkilenir. Bu bağlamda kritik CSS, yalnızca FCP/LCP iyileştirmesi olarak değil, kullanıcı etkileşim hızını da destekleyen bütünsel performans stratejisinin ayrılmaz bir parçası olarak değerlendirilmelidir.
Kaynaklar
Sıkça Sorulan Sorular
Kritik CSS (critical CSS), bir web sayfasının ilk görünümünde (above-the-fold) — yani kullanıcının sayfayı açtığında kaydırmadan gördüğü alanda — çizim için gereken minimum stil kurallarının ayrıştırılıp sayfanın head bölümüne satır içi (inline) eklenmesi tekniğidir. Amacı, tarayıcının harici bir CSS dosyasını indirip ayrıştırmasını beklemeden ilk boyamayı gerçekleştirmesini sağlamaktır. CSS varsayılan olarak render-blocking'tir. CSSOM oluşana kadar tarayıcı hiçbir şey çizemez. Kritik CSS bu engeli kaldırır: ilk görünüm için gereken stiller anında erişilebilir olduğundan FCP belirgin biçimde düşer. Kalan CSS ise asenkron yüklenir, sayfa işlevini yitirmez.
İki temel yöntemle çıkarılır. Manuel yöntemde Chrome DevTools Coverage sekmesi kullanılır: sayfa çalıştırılır, kullanılan ve kullanılmayan CSS kuralları yeşil/kırmızı çubuklarla listelenir. above-the-fold için gerekli kurallar elle ayıklanır. Otomatik yöntemde ise Critical (npm) veya Penthouse gibi araçlar headless bir tarayıcı üzerinden sayfayı işleyerek above-the-fold CSS'i otomatik üretir. Her iki yöntemde de çıktının sıkıştırılmış boyutu 14 KB bütçesiyle kıyaslanmalı, inline ekleme sonrasında Lighthouse ile doğrulama yapılmalıdır. WordPress kullanıcıları için otomatik kritik CSS üreten performans eklentileri de mevcuttur.
Kritik CSS, render-blocking CSS'in neden olduğu FCP (First Contentful Paint) gecikmesini doğrudan hedefler. Head bölümüne inline eklenen kritik stiller sayesinde tarayıcı ilk boyamayı harici dosya beklemeden gerçekleştirir. kullanıcı içeriği çok daha erken görür. FCP düşüşüne paralel olarak LCP (Largest Contentful Paint) değeri de iyileşir. çünkü en büyük görsel öğe çoğunlukla above-the-fold alanındadır. Core Web Vitals bağlamında hem FCP hem LCP'nin Google eşik değerlerine girmesi, arama motoru sıralamasını ve kullanıcı deneyimi puanını olumlu etkiler. Somut sonuçlar sayfa yapısına, CSS boyutuna ve sunucu hızına göre değişir.
Render-blocking CSS, tarayıcının ilk boyamayı yapmadan önce indirip ayrıştırmak zorunda olduğu stil kaynaklarıdır. CSS'in varsayılan davranışı render-blocking'tir. tarayıcı CSSOM'u oluşturmadan Render Tree'yi ve dolayısıyla ilk boyamayı yapamaz. Kaldırma stratejisi iki adımdan oluşur: ilk görünüm için gerekli minimum CSS kritik CSS olarak sayfanın head bölümüne inline eklenir. kalan stil dosyaları ise media ve onload tekniğiyle asenkron yüklenerek render-blocking olmaktan çıkarılır. Lighthouse'un Eliminate render-blocking resources denetimi, hangi dosyaların ne kadar gecikmeye yol açtığını gösterir ve bu uyarının giderilmesi genellikle ölçülebilir FCP iyileşmesi sağlar.
Genel kural olarak ilk roundtrip'te gönderilebilmesi için sıkıştırılmış yaklaşık 14 KB bütçe önerilir. Bu değer TCP slow start mekanizmasıyla ilişkilidir: ilk TCP iletim penceresi genellikle bu aralıkta olduğundan 14 KB altındaki kritik CSS tek bir ağ gidiş-dönüşünde tarayıcıya ulaşır ve ek gecikme yaşanmaz. 14 KB'ı aşan kritik CSS ek bir roundtrip gerektirir ve FCP kazanımı azalır. üstelik HTML boyutunu şişirir ve tarayıcı bu bloğu önbelleğe alamaz. Bu nedenle çıkarım sonrası minify ve gzip/brotli sıkıştırmasıyla bütçe doğrulanmalı. fazla kural varsa viewport sınırı daraltılmalıdır.
En yaygın kullanılan araçlar şunlardır: Critical (npm) — Node.js tabanlı olup Gulp ve Webpack gibi build araçlarına kolayca entegre edilir. Puppeteer üzerinden headless Chrome ile çalışır. Penthouse — yine Puppeteer tabanlı olup özelleştirilmiş viewport yapılandırmaları ve gelişmiş seçenekler sunar. CriticalCSS — daha eski bir araçtır, basit projeler için kullanılabilir. WordPress kullanıcıları için çeşitli performans eklentileri kritik CSS üretimini arka planda otomatik yönetir. Araç seçiminde teknik bilgi düzeyi, build süreci altyapısı ve mobil/masaüstü ayrı çıkarım ihtiyacı belirleyici faktörlerdir.
İki ana yol vardır. Birincisi otomatik optimizasyon eklentileridir: bu eklentiler kritik CSS'i arka planda üretir, head bölümüne inline ekler ve kalan CSS'i defer ile yükler. teknik bilgi gerektirmez ancak yanlış viewport hesaplamalarına karşı dikkatli olunmalıdır. İkincisi manuel uygulamadır: Critical (npm) veya Penthouse ile çıkarılan CSS, tema functions.php dosyasına ya da child tema head bölümüne eklenir, kalan ana stil dosyası asenkron yüklenecek şekilde yapılandırılır. Her iki yöntemde de uygulama sonrası Lighthouse ile FCP ve LCP değerlerinin ölçülmesi, FOUC kontrolü ve mobil/masaüstü için ayrı test yapılması zorunludur.
Critical CSS ve defer CSS birbirini tamamlayan iki kavramdır. Critical CSS, above-the-fold için gereken minimum stilleri sayfanın head bölümüne satır içi (inline) ekler. tarayıcı bu stilleri anında kullanır, harici dosya beklemez. Defer CSS ise kritik olmayan stillerin — yani ilk görünüm dışındaki tüm sayfa stillerinin — asenkron yüklenmesini ifade eder. ilk boyamayı engellemeden arka planda indirilir ve uygulanır. İkisi birlikte kullanıldığında tüm stil ihtiyaçları karşılanırken FCP ve LCP optimize edilmiş olur. Tek başına defer CSS uygulamak yetersizdir. kritik stilleri inline eklemeden yalnızca defer kullanmak FOUC sorununa yol açabilir.