murattunalı.

Kritik CSS.

Kritik CSS, sayfanın ilk görünen alanını boyamak için gereken minimum stil kümesidir ve ayrı bir dosya beklemeden hemen uygulanabilir.

Tarayıcı, stil dosyalarını indirip ayrıştırmadan hiçbir şey boyamaz. Bu kural, stil dosyalarını render engelleyici yapıyor: her biri bir istek ve bir bekleme demek. Sayfada üç ayrı stil dosyası varsa, ilk boyama üçünün de gelmesini bekliyor.

Kritik CSS yaklaşımı bu beklemeyi kısaltmayı hedefliyor: ilk görünen alanı boyamak için gereken kurallar ayrılıyor ve doğrudan sayfanın içine gömülüyor, geri kalanı ise engellemeyen bir biçimde sonradan yükleniyor. Böylece ilk boyama hiçbir ağ isteği beklemiyor.

Ne zaman değer, ne zaman değmez

Teknik güçlü ama bedava değil ve her sitede karşılığı yok. Getirisi, stil dosyasının boyutuna ve sunucunun hızına bağlı; ikisi de iyiyse kazanç ölçülemeyecek kadar küçük kalabilir.

Bu sitede yaklaşım denendi ve TERCİH EDİLMEDİ. Gerekçe ölçüldü: iki ayrı stil dosyası tek dosyada birleştirildi ve yorumlar sıyrıldı; sonuç gzip sonrası 12,4 kilobayt oldu. Bu boyuttaki tek bir dosya, iyi bir sunucudan tek gidiş dönüşte geliyor ve kritik CSS ayırmanın getireceği kazanç, sistemin karmaşıklığını haklı çıkarmıyor.

Karar sayılarla verildi. Birleştirme öncesi Lighthouse mobil koşumunda iki dosya render'ı bloke ediyordu: biri 821 milisaniye, diğeri 221. Birleştirme ikisini de kapattı. Kritik CSS, o noktadan sonra kalan süreyi bölmeye çalışmak olurdu — ve bölünecek süre kalmamıştı.

Bir teknik iyi olabilir ve sizin sitenizde gereksiz olabilir; ikisi çelişmez.

Uygulanacaksa nasıl

Kritik CSS'in gerçekten gerektiği durumlar var: büyük tasarım sistemleri, çok sayfalı uygulamalar ve stil dosyası yüz kilobaytları bulan siteler. Orada yaklaşım şu şekilde kurulur.

  1. Görünür alanı belirle — hangi ekran boyutu için? Genelde en dar ve en yaygın kırılım seçilir.
  2. Kuralları çıkar — o alanda kullanılan seçicileri toplayan bir araç kullanılır; elle yapılmaz.
  3. Gövdeye göm — çıkarılan kurallar sayfanın içine, ilk boyamadan önce uygulanacak şekilde konur.
  4. Kalanı engellemeden yükle — geri kalan stil, boyamayı bloke etmeyen bir yöntemle sonradan gelir.
  5. Sayfa türüne göre üret — ana sayfanın kritik kümesi ile yazı sayfasınınki aynı değildir.
  6. Otomatikleştir — elle bakılan bir kritik küme, ilk tasarım değişikliğinde bayatlar.

Son madde bu tekniğin asıl maliyetidir. Kritik CSS, tasarım değiştikçe yeniden üretilmelidir; bir kez çıkarılıp unutulduğunda ilk boyama yanlış stillerle yapılır ve sayfa gözle görülür biçimde «zıplar». Bu, hiç kritik CSS kullanmamaktan kötü bir sonuçtur.

İçerik güvenlik politikası ile gerilim

Kritik CSS'i gövdeye gömmek, satır içi stil kullanmak demektir — ve sıkı bir içerik güvenlik politikası satır içi stili engeller. İki hedef doğrudan çelişiyor ve seçim yapmak gerekiyor.

Politikayı gevşetmek bir seçenek ama güvenlik tarafında bedeli var; her satır içi bloğa ayrı bir imza vermek mümkün ama üretim zincirini karmaşıklaştırıyor. Bu sitede politika sıkı tutuldu ve satır içi stile hiç izin verilmedi — kritik CSS'in tercih edilmemesinin ikinci gerekçesi bu.

Genel ders şu: performans teknikleri boşlukta değerlendirilemez. Bir teknik, güvenlik politikanızla, bakım kapasitenizle ve mevcut ölçümlerinizle birlikte değerlendirilir. Herkes için doğru olan bir liste yoktur; ölçülüp karar verilen bir liste vardır.

Alternatif: dosyayı küçültmek

Kritik CSS'in çözmeye çalıştığı sorun — stil dosyasının beklenmesi — başka bir yoldan da azaltılabilir: dosyayı gerçekten küçültmek. Ve çoğu sitede bu yol daha ucuz, daha kalıcı ve daha az riskli.

  1. Kullanılmayan kuralları çıkar — çoğu sitede stil dosyasının büyük bölümü hiçbir sayfada kullanılmıyor.
  2. Çerçeve varsayılanlarını tart — hazır bir CSS çerçevesi getirdiği kuralların yüzde onunu kullandırabilir.
  3. Yorumları sıyır — kaynak dosyada kalsın, yayına inmesin.
  4. Sıkıştırmayı doğrula — sunucu gerçekten sıkıştırılmış gönderiyor mu? Kontrol edilmeden varsayılmamalı.
  5. Tek dosyada topla — modern protokollerde bile ilk boyama için gereken stil tek istekte gelmeli.

Bu sitede beş maddenin dördü uygulandı ve ölçülen sonuç 12,4 kilobayt gzip. Bu boyuttaki bir dosya iyi bir sunucudan tek gidiş dönüşte geliyor; kritik CSS ayırmanın getireceği kazanç ölçülemeyecek kadar küçük kalıyor ve sistemin karmaşıklığını haklı çıkarmıyor.

Genel ders şu: bir tekniğin gerekli olup olmadığı, o teknik uygulanmadan önceki ölçümden anlaşılır. Kritik CSS büyük stil dosyaları için gerçek bir çözümdür — ama önce dosyanın gerçekten büyük olup olmadığına bakılmalıdır.

Kapanışta bir ölçüm önerisi: kritik CSS uygulanmadan önce ve sonra ilk boyama süresi ölçülmeli ve fark yazılmalıdır. Teknik sezgisel olarak doğru görünüyor ve tam bu yüzden ölçülmeden uygulanıyor — oysa küçük stil dosyalarında kazanç ölçüm gürültüsünün içinde kalabiliyor. Ölçülmemiş bir optimizasyon, bir varsayımdır; ve bakım maliyeti taşıyan bir varsayım, zamanla zarara dönüşür.

Bu sitede karar tam olarak böyle verildi: teknik değerlendirildi, mevcut ölçüm bakıldı, kazanç tahmin edildi ve karmaşıklıkla karşılaştırıldı. Sonuç uygulamamaktı — ve gerekçe kayda geçti ki gelecekte biri aynı soruyu sorduğunda cevabı hazır olsun.

Bir de ekip boyutu meselesi var: kritik CSS üretimi, tasarım değiştikçe yeniden koşması gereken bir adım ekliyor ve o adım unutulduğunda sonuç, hiç kritik CSS olmamasından kötü. Küçük ekiplerde bakım yükü, kazançtan büyük çıkabiliyor. Teknik seçimi yalnız performans getirisiyle değil, o getiriyi sürdürebilme kapasitesiyle birlikte değerlendirmek gerekiyor.

Pratik kontrol listesi

Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, stil dosyalarının render maliyeti için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.

  1. Kaç stil dosyası iniyor — birden fazlaysa birleştirme adayı.
  2. Gzip sonrası boyut ne — on kilobayt civarı bir dosya tek gidiş dönüşte geliyor.
  3. Kullanılmayan kural oranı ne — çerçeve varsayılanları en büyük şişkinlik kaynağı.
  4. Yorumlar yayına iniyor mu — kaynakta kalsın, çıktıda kalmasın.
  5. Sunucu sıkıştırma yapıyor mu — varsayılmamalı, ölçülmeli.
  6. Kritik CSS gerçekten gerekli mi — dosya küçüldükten SONRA sorulmalı.

Altıncı madde bu sayfanın tezi: teknik seçimi ölçümden sonra yapılır. Bu sitede sıra tam olarak böyle işledi — önce birleştirme ve sıyırma yapıldı, sonuç 12,4 kilobayt gzip oldu, ve o noktada kritik CSS'in getireceği kazanç karmaşıklığı haklı çıkarmıyordu.

KAYNAKLAR