- Critical CSS, sayfanın "ilk görünen bölümünü (above the fold)" render etmek için gereken en az CSS'yi çıkarır; bunu HTML'e inline eklemek FCP (First Contentful Paint) gibi Core Web Vitals metriklerini iyileştirir
- HTML'in
<head> bölümüne inline eklenerek tarayıcının tüm stil dosyasını beklemeden içeriği hızlıca render etmesini sağlar
- Algılanan yükleme hızında artış, Lighthouse puanında yükselme, SEO ve UX iyileşmesi gibi avantajlar sunar
- Kritik olmayan CSS,
<body> sonuna <link> ile yüklenebilir veya JavaScript ile gecikmeli yüklenerek performans daha da optimize edilebilir
- Kullanıcının CSS bağlantı yolu ve varlık referanslarını doğrudan ayarlaması gerektiğine dikkat edilmelidir
Critical CSS Generator
- Critical CSS Generator, bir web sayfasında mutlaka gerekli olan minimum CSS kodunu çıkaran bir araçtır ve kullanım amacına göre optimize edilmiş CSS çıkarımı sağlar
- Critical CSS, sayfada ilk görünen alanı stillendirmek için gereken minimum CSS kurallarıdır
- Bu yaklaşım, tarayıcının tüm stil dosyalarının yüklenmesini beklemeden ana içeriği hemen göstermesine yardımcı olur; böylece performans ve Core Web Vitals (FCP vb.) iyileşir
Neden kullanılmalı?
- Daha hızlı ilk yükleme hissi
- Lighthouse puanında iyileşme
- SEO ve kullanıcı deneyiminde iyileşme
🔧 Uygulama yöntemi
Step 1: Critical CSS'yi inline işleme
Step 2: Kritik olmayan CSS'yi gecikmeli yükleme (temel yöntem)
Step 3 (isteğe bağlı): JavaScript ile asenkron stil yükleme
- Sayfa yüklemesi tamamlandıktan sonra JavaScript ile kritik olmayan CSS dinamik olarak yüklenir
- Ağ hızı yavaş olduğunda performans artışı sağlayabilir
- Mevcut
<head> içindeki tüm kritik olmayan CSS <link> etiketleri kaldırılmalıdır
window.addEventListener("DOMContentLoaded", function () {
console.log("✅ Page loaded, now loading non-critical stylesheets...");
let stylesheets = [
// "/css/vendors.min.css",
// "/css/style.min.css",
];
let loadedCount = 0;
function checkAllStylesLoaded() {
loadedCount++;
if (loadedCount === stylesheets.length) {
console.log("✅ All non-critical stylesheets loaded...");
}
}
stylesheets.forEach(function (href) {
var link = document.createElement("link");
link.rel = "stylesheet";
link.href = href;
link.onload = checkAllStylesLoaded;
link.onerror = () => console.warn(`Failed to load stylesheet: ${href}`);
document.head.appendChild(link);
});
});
1 yorum
Hacker News görüşleri
Duyarlı tasarıma da destek veriyorsa harika olur gibi görünüyor; responsive kritik stil deduplication zor olduğu için en sonunda hep stylesheet'i elle düzenlemeye devam ettim. Critical CSS'nin boyutu önemli olduğundan CSS değişkenleri gibi şeyleri de down-compile eden bir seçenek olsa iyi olurdu. Ayrıca kritik olmayan CSS için
<link>etiketini</body>önüne koyma tavsiyesini önermiyorum; CSS'nin hızlı alınması gerekir, bu yöntem CSS'nin keşfini geciktirip indirmeyi de geciktirir. Onun yerine preload ve noscript birleşimini öneriyorum:<link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'"><noscript><link rel="stylesheet" href="styles.css"></noscript>Bu preload yönteminde JS kodu kullanmak, CSP'de unsafe-inline'a izin verilmezse engellenmez mi diye merak ediyorum
CSS'yi JS hilesiyle yükleme yaklaşımını kullanmak istemiyorum; stylesheet uygulanırken tüm sayfada layout/style yeniden hesaplaması olabilir. Tarayıcılar stylesheet'i sayfanın altında olsa bile hızlıca alıyor
Sadece prefetch özniteliği, HTTP header hint'leri ve CDN kombinasyonuyla da benzer etki elde edilebilir; critical CSS'yi durmadan rebuild etmeye gerek yok. CF gibi bir CDN'i düzgün kullanırsan inanılmaz hızlı oluyor
Sanırım doğru, böyle bir seçeneği eklemeyi planlıyorum. 'before body' yerine 'DOMContentLoaded' seçeneğini denedim; eski telefonlarda, yavaş ağlarda vb. bile UX ve Lighthouse açısından yeterince iyi çalışıyor
Responsive destek fikrine kesinlikle katılıyorum
Bana göre bu fazla erken optimizasyon gibi geliyor. CSS aşırı karmaşıksa veya yüklenen kaynak çoksa değeri olabilir ama çoğu durumda CSS, HTML ve JS'yi temiz yazmak daha verimli; bu yaklaşım gereksiz hatta zararlı olabilir
Çok faydalı. Serbest çalışan olarak sık sık WordPress siteleri alıyorum ve birçok geliştirici/ajans elinden geçtiği için CSS/JS'nin tam bir karmaşa olduğu durumlar çok oluyor. Böyle bir aracı gerçekten denemek isterim
CSS karmaşıklaştıkça ya da kaynak arttıkça optimizasyonun net etkisi aslında küçülür. Buradaki hedef RTT latency optimizasyonu; critical CSS büyüdükçe optimizasyon maliyeti artar ve net kazanç azalır
12 yıl önce olsaydı böyle bir araca para verirdim. Yıllar içinde birikmiş muazzam miktarda CSS vardı ve hangi kuralların kritik olduğunu anlamak zordu
Birçok site için kesinlikle erken optimizasyon olabilir. Ama haber/medya gibi tıklamaya duyarlı sitelerde “anında” sayfa yüklenmesi çok önemli. 1 saniyeyi geçince terk oranı ve reklam geliri düşüyor. HuffPost da 10 yıl önce bu optimizasyonu denemişti
Frontend geliştirmenin bugünkü durumuna bakınca bunun gerçekten aşırıya kaçtığını düşünüyorum. Lighthouse gibi araçlar anlamsız sayılar için optimizasyona takıntı yaratıyor; sonuç olarak build karmaşıklığı artıyor, gerçek kullanıcı ise bunu hissetmiyor ama geliştirme daha zor hale geliyor. Bu arada gerçekten temel UI/durum yönetimi hatalarıyla dolu siteleri de sık görüyorum. Sinir bozucu
Temiz CSS, HTML ve JS doğru cevap ama bazen dağınık bir projeyi devralabiliyor ya da bir şablon kullanabiliyorsun; hatta kendim geliştirirken bile tasarım dolaşabiliyor
Benim için CSS yükleme biçimi geliştirme sürecinin en başında mutlaka ele alınması gereken bir konu. Web sitemizin page speed test puanı düşük olduğu için müşteri kaybı çok yaşadık. Performans SEO'ya yansıdığı için çok önemli. Google Lighthouse'da 100 puan almak için sayfa optimizasyonunu baştan yeniden tasarladım; CSS/JS yükleme sırası ve yöntemine kadar her şeyi en baştan planlamak gerekiyor ki sonradan düzeltme ihtiyacı azalsın. Biz fold üstü/altı CSS'yi ayırıp uygun yerlere inline olarak da koyduk ve fold altı JS'yi kullanıcı kaydırana kadar hiç evaluate etmiyoruz. Lighthouse'un önerdiği her şeyi uyguladık. Önceki sistem tüm sayfalara sitenin bütün CSS'sini gönderiyordu (3~4MB), JS ise daha da kötüydü. Sebep, başta optimizasyon mimarisinin düşünülmemesiydi. Hâlâ o sistemi kullandığımız için adını veremem ama içeride sürekli sorun oluyor. Hedef performanssa erken optimizasyon diye bir şey olmadığını düşünüyorum; en baştan her şey hesaba katılmalı. Sonuçta mobil dahil tüm istemcilerde 100 puan performans alıyoruz ve rakiplere karşı üstün durumdayız. Bu aracı kendi sitemde denedim ama zaten her şeyi uygulamış olduğum için daha optimize edecek bir şey kalmamıştı, etkisi olmadı
Astro framework'üyle yapılmış sayfamda HTML 27.52KB (sıkıştırılmış 6.1KB), JS 10KB'den az, critical CSS ise 57KB (sıkıştırılmış 7KB). Benzer siteler 100KB~1MB aralığında olabiliyor. Temiz yapılırsa inline CSS/JS olmadan da resource hint'lerle yeterince hızlı oluyor. nginx+HTTP/2+edge cache kombinasyonunda critical CSS/inline JS olmadan da 100/100 performans mümkün. Her sayfaya 7KB eklemek verimsiz gibi geliyor. Uygulama açısından SPA/edge caching çok daha çevreci ve hızlı. Elementor gibi aşırı ağır HTML göndermeye gerek yok. Mobil batarya sınırlıyken gereksiz veriyi göndermenin anlamı yok
Güzel bir numara ama CDN ve HTTP/2 zaten yaygınken bu tür optimizasyonlar sonuçta sadece bant genişliğini israf ediyor. Benchmark sayıları biraz iyileşiyor ama gerçek etkisi 10~20ms civarında
Her sayfaya critical CSS koymak tek doğru değil. Bunu yalnızca ilk ziyaret (cache yokken) ya da oturumun giriş sayfası gibi durumlarda seçici biçimde uygulamak, gereksiz data bloat'ı önleyebilir
Bir müşterinin isteği üzerine critical CSS çıkarma aracı aradım ama istediğim özellikler yoktu; bu yüzden Puppeteer ve kendi yaptığım çözümü paylaşıyorum. Sayfa yüklendikten sonra ne kadar bekleneceği ayarlanabiliyor. Ücretli servisler de kullandım ama beğenmeyip iade aldım. Geri bildirim memnuniyetle karşılanır; şimdilik ücretsiz açtım
Sorunun penthouse paketi gibi mevcut araçlarda ne olduğunu merak ediyorum
CSS olmayan bir site girince hata veriyor
Kod açık mı, Vite/Astro eklentisi olarak da kullanmak isterim
Bunun penthouse'un bir UI sürümü olup olmadığını sormak istiyorum; ayarların çoğu çok benzer görünüyor
Bu yöntem ters etki yaratabiliyor; çok tutarlı bir FOUC (stil uygulanmamış görünüm parlaması) oluşuyor. Düzen ortada değişirse zaten bir şeye tıklamakta olan kullanıcı ciddi rahatsızlık yaşayabilir. Bu sadece estetik değil, doğrudan kullanılabilirlik sorunu
Ben de bu yaklaşımı uyguladıktan sonra bazı stilleri düzelttim ama sonuçta CLS'yi (kümülatif yerleşim kayması) 0'a kadar optimize etmek mümkün oldu. Bütçe düşükse ve çok sayıda kütüphane içeren şablonlar kullanılıyorsa oldukça işe yarayabiliyor
Amaç zaten CSS network request'ini block etmeden FOUC'yi önlemek değil mi?
Bu yaklaşım, ilk sayfa görüntülemesinde CSS cache'inin hiç olmadığı varsayımı altında daha anlamlı. Gerçekte ise yeni/geri dönen ziyaretçi oranı, CSS cache ayarları, CDN, 103 early hints, critical CSS/initial congestion window gibi birçok unsur arasında trade-off var
Performans ölçerken localhost'ta CSS'nin etkisi neredeyse yoktu. CSS'yi tamamen kaldırsam bile iyileşme 7ms'in altındaydı ve o da ölçüm hatası payı içindeydi
Bu aracı kendi sitemde kullandığımda aslında hiç gerekli olmayan debugging öğeleri bile CSS'ye çıkarıldı. Örneğin site grid overlay'i için olan
body::afterda aynen CSS'ye dahil edildiğini gördüm (unutmuştum, bu sayede fark ettim)Ben CSS olmadan da anlamını iyi ileten HTML yazımını tercih ediyorum. Böylece doküman yapısının gereksiz yere karmaşıklaşmasını baştan önlemek mümkün oluyor
Fikir taze geldiği için kişisel sitemde denedim ama penthouse kütüphanesinden CSS eksik hatası aldım
{"error":true,"name":"Error","message":"css should not be empty" ...}