Critical CSS Nedir? İlk Boyama Süresini Kısaltma

Critical CSS nedir ve neden önemlidir?

Critical CSS, sayfanın ilk ekranında (above-the-fold) görünen içeriğin doğru biçimde görüntülenebilmesi için mutlaka ihtiyaç duyulan minimum CSS kurallarıdır. Bu kurallar, sayfanın en başında — harici CSS dosyası yüklenmeden önce — kullanıcıya sunularak tarayıcının ilk boyamayı (First Contentful Paint) daha erken gerçekleştirmesini sağlar.

Standart bir sayfada CSS, head bölümündeki <link rel="stylesheet"> etiketiyle yüklenir. Tarayıcı bu dosyayı indirip ayrıştırana kadar sayfanın herhangi bir bölümünü ekrana çizmez. Bağlantı hızına, dosya boyutuna ve sunucu yanıt süresine bağlı olarak bu bekleme süresi 300 ms ile birkaç saniye arasında değişebilir. Critical CSS yaklaşımı bu engeli kaldırır: ilk ekran için zorunlu stiller doğrudan HTML içine (inline) alınır, geri kalanlar sayfa yüklendikten sonra asenkron yüklenir.

Bu yaklaşımın FCP ve LCP üzerinde doğrudan etkisi vardır. Tarayıcı inline CSS'i ayrıştırırken harici kaynak bekleme süresi ortadan kalkar; ilk ekran içeriği çok daha erken görünür hâle gelir. LCP görseli de bu bölgede yer alıyorsa onun render süresi de dolaylı olarak iyileşir. Google'ın Core Web Vitals metrikleri bu iki boyamayı doğrudan değerlendirdiğinden critical CSS çalışması teknik bir iyileştirme olmaktan çıkıp organik görünürlüğü etkileyen bir karar hâline gelir.

Critical CSS nasıl çıkarılır? Araçlar ve yöntemler

Critical CSS'i elle çıkarmak küçük projeler için mümkündür; ancak orta ölçekli bir projede yüzlerce bileşen varken hangi stillerin ilk ekranda gerekli olduğunu manuel belirlemek hem hata payı yüksek hem de sürdürülemez bir süreçtir. Bu nedenle otomasyon araçları tercih edilir.

Critters (Google), Next.js ve webpack ile entegre çalışır; sayfayı bir headless tarayıcıda render ederek hangi CSS kurallarının ilk ekranda uygulandığını saptar ve otomatik inline yapar. Critical (npm paketi) benzer mantıkla çalışır; CLI veya Gulp/Grunt pipeline'larına entegre edilebilir. Penthouse ise PhantomJS/Puppeteer tabanlı, daha özelleştirilebilir bir seçenektir.

Bu araçların ortak sınırlaması: headless render sırasında görünür olmayan ancak gerçekte ilk ekranda yer alan içeriği kaçırabilirler. Dinamik bileşenler, sunucu tarafı render farklılıkları veya A/B test varyantları bu sorunun kaynağı olabilir. Bu nedenle araç çıktısı doğrudan kullanılmaz; ekip tarafından gözden geçirilip onaylanmalıdır.

• Critters: Next.js veya webpack projelerinde otomatik critical CSS inline için en kolay entegrasyon seçeneği; CI pipeline'ına kolayca eklenir.
• Critical (npm): Bağımsız CLI veya Gulp entegrasyonu; birden fazla viewport boyutunu destekler, farklı cihaz profilleri için ayrı çıkarım yapılabilir.
• Chrome DevTools Coverage: Hangi CSS kurallarının kullanılmadığını görsel olarak gösterir; manuel inceleme ve başlangıç noktası belirleme için idealdir.
• Manuel yaklaşım: Küçük projeler veya tek sayfa sitelerde geçerlidir; bileşen sayısı artıkça sürdürülemez hâle gelir.

Hangi stillerin ilk render için gerekli olduğunu veriyle netleştirin

Tek sayıya bakıp karar vermek riskli; dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri 3-4 katına çıkarabilir. Ortalama 2.1 saniye görüyorsanız %25'lik dilim 4.8 saniye bekliyor olabilir.

• Gerçek kullanıcı verisi: CrUX raporundan 28 günlük dağılımı çekin, %75'lik dilime odaklanın.
• Laboratuvar testi: Lighthouse'u 3G throttling ile 5 kez çalıştırın, medyan değeri alın.
• Cihaz kırılımı: Düşük-orta-yüksek segment ayrı ölçülmeli, mobil %80 ise oraya optimize edin.
• Zaman karşılaştırması: Haftalık snapshot alın, trend grafiği çizin, ani düşüşleri deploy loglarıyla eşleştirin.

Kullanıcı sayfa ile akıcı etkileşime girmeli, içerik stabilitesini korumalı, bekleme hissi azalmalı. Bir metriği iyileştirirken başka alanda sorun üretmek çok kolaydır.

Critical CSS için belirlediğiniz eşikleri sürüm notlarına işleyin. Yeni geliştirmeler performans çizgisini bozduğunda daha erken yakalarsınız.

Render zincirinde bloklayan katmanı ve kullanılmayan stili birlikte ayırt edin

İlk ekran zincirini kısaltırken render blocking çözüm adımları ve JavaScript yükleme stratejileri birlikte değerlendirildiğinde etki daha net ölçülür.

Lighthouse "Reduce unused CSS" diyor — ama hangi dosya, hangi selector, kaç KB? DevTools Coverage sekmesini açın, sayfayı yükleyin, kullanılmayan CSS oranını görün. %60 unused görüyorsanız 180 KB stil dosyasının 108 KB'ı gereksiz yükleniyor demektir; bu 3G bağlantıda 2.4 saniye bloklama anlamına gelir.

Bloklama tiplerine göre değerlendirin:

• Ağır medya: Hero görseli 850 KB, WebP'ye çevirince 140 KB. LCP 3.2 saniyeden 1.8 saniyeye düştü.
• Bloklayan kaynak: Google Fonts 340ms bekletiyor. font-display: swap ekleyin, FOUT kabul edin.
• Ana iş parçacığı yükü: 1.2 saniye JavaScript parse süresi. Code splitting yapın, route bazlı chunk'lara bölün.
• Sunucu gecikmesi: TTFB 890ms. CDN ekleyin, edge cache aktif edin, origin sunucu yanıt süresini 200ms altına çekin.

Her darboğazın maliyeti farklı. Bloklayan CSS 400ms geciktiriyorsa ve düzeltmesi 2 saat sürüyorsa, ROI açık. Ama %5 kullanılmayan CSS temizliği için 3 gün harcamak mantıklı değil.

Önce etkiyi ölçün, sonra düzeltin, tekrar ölçün. Değişiklik öncesi ve sonrası ekran kaydı alın, kullanıcıya gösterin. "Şimdi 1.4 saniye daha hızlı" demek, "CSS optimize ettik" demekten daha etkili.

Inline stilin kapsamını dört kritere göre belirleyin

Unused CSS temizliği 600ms kazandırıyor, 4 saat sürüyor, risk düşük, geri alma 5 dakika — yüksek öncelik. Font subsetting 80ms kazandırıyor, 2 gün sürüyor, karakter seti hatası riski var, geri alma 1 saat — düşük öncelik. Etki büyüklüğü, uygulama maliyeti, risk seviyesi ve geri dönüş süresi dört faktörü birlikte değerlendirin.

• Etki büyüklüğü: Değişiklik LCP'yi kaç milisaniye düşürüyor? 500ms+ ise yüksek, 100-500ms orta, 100ms altı düşük.
• Uygulama maliyeti: Kaç saat geliştirme, kaç saat test, kaç deployment? 1 gün altı düşük, 1-3 gün orta, 3+ gün yüksek.
• Risk seviyesi: Değişiklik layout bozabilir mi? Fonksiyonellik etkilenir mi? A/B test gerekir mi?
• Geri dönüş süresi: Sorun çıkarsa ne kadar sürede eski haline dönersiniz? Feature flag var mı?

Yüksek etki + düşük maliyet öğeleri önce uygulanır. Orta etki + orta maliyet sprint planına girer. Düşük etki + yüksek maliyet backlog'da kalabilir.

Ekip içinde bu matrisi görünür tutun. Yeni iyileştirme önerisi geldiğinde 4 kritere göre puanlayın, öncelik sırasına koyun. "Hadi şunu da yapalım" yerine "Bu değişiklik matrise göre nerede?" diye sorun.

Her sayfa tipi için ayrı kapsam belirleyip izole test edin

Tüm CSS'i bir seferde yeniden yazmayın. Önce bir sayfa tipi seçin, critical CSS'i çıkarın, test edin, canlıya alın, ölçün. Sorun yoksa diğer sayfa tiplerine geçin. Her adımda geri alma planı hazır olsun.

• Aşamalı yayın: %5 trafiğe açın, 24 saat bekleyin, metrik stabil mi? %25'e çıkarın, tekrar bekleyin.
• Önce test sonra canlı: Staging'de Lighthouse skoru 85+ olmalı, yoksa canlıya almayın.
• Regresyon kontrolü: Her deploy sonrası otomatik Lighthouse testi çalıştırın, skor 10 puan düşerse alarm verin.
• Geri alma planı: Feature flag kullanın, sorun çıkarsa 30 saniyede eski haline dönün.

Gerçek vaka: Bir e-ticaret sitesi tüm CSS'i tek seferde critical/non-critical olarak ayırdı. Checkout sayfasında ödeme butonu 2 saniye geç render oldu, conversion %18 düştü. Geri aldılar, sayfa sayfa ilerlediler, sorun çıkmadı.

Her hafta küçük bir iyileştirme yapın; 6 ayda büyük fark görürsünüz. Tek seferde büyük değişiklik yapmak çoğunlukla başka bir şeyi bozar.

FCP hızlı ama LCP yavaşsa critical CSS kapsamını yeniden sorgulayın

Doğrulama aşamasında Lighthouse metriği okuma ve sayfa hızı hedefleri aynı çerçevede izlenirse gereksiz CSS geri dönüşü erken yakalanır.

Lab testi ideal koşullarda çalışır. Gerçek kullanıcı yavaş ağda, düşük RAM'li cihazda, 12 sekme açıkken sayfanızı ziyaret ediyor. CrUX verisine bakın: laboratuvarda LCP 1.2 saniye, gerçek kullanıcıda 3.8 saniye olabilir. Tek ölçüme güvenmeyin.

• Tek ölçüm yanılgısı: Lighthouse'u 5 kez çalıştırın, sonuçlar 78-92 arası değişiyorsa ölçüm güvenilir değil.
• Aşırı ortalama kullanımı: Ortalama LCP 2.1 saniye ama %25'lik dilim 5.4 saniye. Ortalamanın altındaki kullanıcılar kötü deneyim yaşıyor.
• Coğrafya farkı: ABD'de 1.8 saniye, Hindistan'da 4.2 saniye. Hedef pazarınıza göre optimize edin.
• Cihaz sınıfı etkisi: iPhone 14'te 1.1 saniye, Samsung Galaxy A12'de 3.9 saniye. Kullanıcılarınızın %60'ı hangi cihazı kullanıyor?

FCP hızlı ama LCP yavaşsa ilk boyama erken oluyor ama asıl içerik geç yükleniyor. CLS sıfır ama sayfa 8 saniyede yükleniyor olabilir — layout shift yok ama kimse beklemez. TTI 2 saniye ama TBT 1200ms'deyse sayfa interaktif görünüyor ama tıklamalar yanıt vermiyor.

Her metriği bağlamında değerlendirin. Tek sayıya odaklanmayın, kullanıcı deneyiminin tamamına bakın.

Inline boyutu zamanla şişer, düzenli gözden geçirme gerekir

Yeni özellik eklendiğinde performans çizgisi bozulur. Yeni JavaScript kütüphanesi, yeni font, yeni üçüncü taraf script. Her deploy sonrası metrikler kayıyor ama kimse fark etmiyor. 3 ay sonra LCP 1.8 saniyeden 3.4 saniyeye çıkmış.

• Haftalık denetim: Her Pazartesi CrUX raporunu çekin, önceki haftayla karşılaştırın. LCP 200ms+ artmışsa nedenini araştırın.
• Yayın öncesi kontrol: CI/CD pipeline'a Lighthouse testi ekleyin, skor 80 altına düşerse deploy başarısız olsun.
• Otomatik alarm: Gerçek kullanıcı LCP'si 2.5 saniyeyi geçerse Slack'e bildirim gitsin, 3 saniyeyi geçerse PagerDuty alarm versin.
• Dokümantasyon disiplini: Her iyileştirmeyi not edin: ne yaptınız, ne kadar kazandınız, hangi riski aldınız. 6 ay sonra aynı hatayı tekrar yapmayın.

Performans bütçesi belirleyin. JavaScript max 200 KB, CSS max 50 KB, font max 100 KB, toplam sayfa ağırlığı max 1.5 MB. Bütçe aşılırsa yeni özellik eklenemez, önce eski kod temizlenir.

Ekip içinde performans şampiyonu atayın. Her sprint'te performans review yapın, regresyonları erken yakalayın. Performans metriklerini dashboard'a koyun, herkes görsün.

Süreklilik olmadan iyileştirme kalıcı olmaz. Bugün 95 skor alırsınız, 6 ay sonra 68'e düşer. Düzenli kontrol, düzenli ölçüm, düzenli iyileştirme.