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

Critical CSS için başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazlarda farklı hız gösterir. Normal.

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.

Hedef sadece raporda iyi görünen skor değil. Kullanıcı sayfa ile akıcı etkileşime girmeli, içerik stabilite korumalı, bekleme hissi azalmalı. Bir metriği iyileştirirken başka alanda sorun üretmek çok kolay.

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.

Critical CSS darboğazını katman katman ayırın

İ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.

Performans sorunu geneldir, ama nedeni spesifiktir.

Lighthouse "Reduce unused CSS" diyor. Tamam, 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. Bunu 3G bağlantıda 2.4 saniye bloklama anlamına gelir.

Darboğaz tipleri:

• 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.

Critical CSS tarafında öncelik sırası kurun

Önceliklendirme matrisi kurun. Etki büyüklüğü, uygulama maliyeti, risk seviyesi, geri dönüş süresi.

Örnek: 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üğü: 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ı?

Matris örneği:

Yüksek etki + düşük maliyet: Hemen yapın. Orta etki + orta maliyet: Sprint'e alın. Düşük etki + yüksek maliyet: Backlog'a atın veya hiç yapmayın.

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.

Critical CSS değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklik = büyük risk.

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ı.

Hız çalışması maraton, sprint değil. Her hafta küçük bir iyileştirme yapın, 6 ayda büyük fark görürsünüz. Tek seferde dev değişiklik yapmaya çalışırsanız, ya başaramazsınız ya da başka bir şeyi bozarsınız.

Critical CSS verisini yanlış okumayı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.

Lighthouse skoru 95. Harika mi? Belki değil.

Laboratuvar 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?

Metrik tuzakları:

FCP hızlı ama LCP yavaş: İlk boyama erken oluyor ama asıl içerik geç yükleniyor. Kullanıcı beyaz ekran görmüyor ama içerik de görmüyor. CLS sıfır ama sayfa 8 saniyede yükleniyor: Layout shift yok ama kimse o kadar beklemez. TTI 2 saniye ama TBT 1200ms: 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.

Critical CSS için sürdürülebilir kontrol rutini kurun

Bir kez optimize edip unutmayın.

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.

Gerçek vaka: Üst alan optimizasyonu

SaaS landing page. Tasarım güçlü, ama kullanıcı içeriği 3.2 saniye sonra görüyor.

Sorun: 240 KB CSS dosyası başlangıçta bloklayıcı. Tüm sayfanın stili yüklenmeden render başlamıyor. DevTools Coverage açtık: ilk ekranda sadece %18 CSS kullanılıyor, geri kalan %82 scroll sonrası veya modal açılınca gerekli.

Çözüm: Critical CSS'i 12 KB'a düşürdük, sadece hero section, navbar ve CTA butonu. Kalan 228 KB'ı async yükledik. Render zinciri 2.1 saniye kısaldı. LCP 3.2'den 1.1 saniyeye düştü.

Ama ilk denemede hata yaptık. Critical CSS'e footer stillerini de ekledik, "her sayfada görünüyor" diye. 12 KB yerine 19 KB oldu, kazanç %40 azaldı. Dar kapsam tutun: sadece ilk ekran, başka hiçbir şey.

3 ay sonra kontrol ettik. Yeni özellik eklenmiş, critical CSS 27 KB'a şişmiş. Tekrar temizledik, 13 KB'a düşürdük. Sürekli kontrol gerekiyor.