Defter · Not 001 · Web performansı

Statik bir sitede son 18 puan nerede saklanıyordu

Resimler sıkıştırılmış, JavaScript üç dosya, çerçeve yok. Lighthouse yine de 82 veriyordu. Kalan puanlar üç yerdeydi ve üçü de aracın adını koyduğu ama açıklamadığı yerlerdi.

Bu sitede çerçeve yok. Sayfalar Python betikleriyle üretilen düz HTML, stil tek bir CSS dosyası, JavaScript üç küçük dosya. Görseller WebP ve üç boyutta üretiliyor. Yani performans için yapılması gereken bariz şeylerin hepsi zaten yapılmıştı.

Mobil puan 82'de duruyordu.

Bariz olanlar bittiğinde geriye kalan puanlar tek bir büyük hatada değil, üç ayrı yerde birer parça hâlinde duruyordu. Üçünü de bulmak, aracın verdiği uyarıyı okumaktan çok, uyarının ne demek istediğini anlamayı gerektirdi.

Birinci yer: işi atlamak için yazılan kontrolün kendisi

Lighthouse'un "zorunlu yeniden akış" (forced reflow) uyarısı, JavaScript'in tarayıcıyı sayfa yerleşimini vaktinden önce hesaplamaya zorladığını söyler. Tarayıcı stil değişikliklerini biriktirip tek seferde uygular; ama araya bir ölçüm okuması girerse birikeni hemen boşaltmak zorunda kalır.

Uyarı kaynak satırını gösteriyordu ama satırda gözle görülür bir ölçüm yoktu. Üç turda bulundu.

• İlk turda getComputedStyle çağrıları kaldırıldı. Puan değişmedi.
• İkinci turda asıl suçlu göründü: gereksiz işi atlamak için yazılmış if (window.scrollY > 0) kontrolü. Kontrolün kendisi bir yerleşim okumasıdır. İşi atlamak için yazılan satır, atlamak istediğin işi yaptırıyordu.
• Üçüncü turda fonksiyon tamamen silindi. Açılış durumu zaten CSS'te tanımlıydı; JavaScript'in onu yeniden kurmasına hiç gerek yoktu.

Kalan bir kalıp da void element.offsetWidth idi. Bir geçişi yeniden başlatmak için yerleşimi bilerek zorlayan, yaygın ve kabul görmüş bir hile. Yerine art arda iki requestAnimationFrame kondu. Aynı işi yapıyor, yerleşimi zorlamıyor.

function yenidenBaslat(fn) {
  /* Sekme arka plandaysa rAF hic calismaz ve demo bos kalir. */
  if (document.hidden) { fn(); return; }
  requestAnimationFrame(function () { requestAnimationFrame(fn); });
}

Buradaki ders şuydu: performans uyarısı çoğu zaman "fazla iş yapıyorsun" demez, "işi yanlış anda yapıyorsun" der.

İkinci yer: ilk boyamadan önceki 600 ms

İkinci uyarı, ilk boyamayı engelleyen kaynaklardı. Sayfa açılırken tarayıcı önce stil dosyasını, sonra yazı tiplerini indirip işlemeden hiçbir şey çizmiyordu. Ölçülen gecikme 600 milisaniyeydi.

Stil dosyası sayfanın içine alındı

Ayrı bir CSS dosyası ikinci ziyarette önbellekten gelir, bu bir avantajdır. Ama ilk ziyarette fazladan bir gidiş-geliş demektir ve ilk ziyaret, arama sonucundan gelen ziyaretçinin yaşadığı şeydir. CSS yayın anında küçültülüp sayfanın içine gömülüyor. Ölçtük: Brotli sıkıştırmasından sonra gömülü hâli, ayrı dosya + ikinci istek toplamından küçük çıktı.

Yazı tipleri kendi sunucumuza alındı

Google Fonts'tan gelen kurulum iki ayrı kökene bağlanıyordu: stil için fonts.googleapis.com, dosyalar için fonts.gstatic.com. Her yeni köken için DNS çözümlemesi, TLS el sıkışması ve yeni bir bağlantı gerekir. Bunu kaldırmanın ölçülen karşılığı şu:

Yazı tiplerinin nasıl küçüldüğü ve on dile açılırken nerede bedel ödendiği ayrı bir not oldu: on dil, üç yazı tipi dosyası.

Üçüncü yer: aracın yanıldığı yer

Erişilebilirlik denetimi 24 renk kontrastı uyarısı verdi. Doğru kabul edilip düzeltilseydi tasarımın yarısı bozulacaktı. Uyarıların 6 tanesi gerçek değildi.

Sebep content-visibility:auto idi. Bu özellik, ekran dışındaki bölümlerin işlenmesini erteleyerek ilk boyamayı hızlandırır. Tam istediğimiz şey. Ama ertelenen bölümün hesaplanmış rengi denetim aracına ulaşmıyor, araç da "beyaz üstüne beyaz" diye rapor ediyordu. Ekranda öyle bir şey yoktu.

Gerçek oranlar tarayıcıda tek tek ölçüldü. 18 uyarı gerçekti ve düzeltildi. 6 tanesi aracın kör noktasıydı; content-visibility yalnızca sorunlu iki bölümden kaldırıldı, kalan bölümlerde bırakıldı.

Bir denetim aracının uyarısı, düzeltilecek bir hata olduğunun kanıtı değildir. Uyarı bir iddiadır; doğrulanır, sonra düzeltilir. Bu ders bu sitede iki kez daha karşımıza çıktı. Biri dil denetimi notunda anlatılıyor.

Bir de kendi açtığımız yara

Düzen kaymasını önlemek için tüm görsellere width ve height özniteliği eklendi. Doğru bir hamle; tarayıcı görselin yerini indirmeden ayırabiliyor. Ama demo kutuları bozuldu: bazı görseller 58 piksel genişlikte, 1500 piksel yükseklikte çizildi.

Sebep şu: HTML'deki width ve height öznitelikleri sunum ipucudur ve CSS'teki height değerini doldururlar. Tasarımda o kutular için yalnızca aspect-ratio tanımlıydı, height boştu. öznitelik oraya yerleşti ve oranı ezdi. Tek satırlık düzeltme:

img{max-width:100%;height:auto;display:block}

Ve taramanın asıl işe yaradığı yer

Ana sayfa 100 olunca iş bitmiş görünüyordu. Bitmemişti. Ölçtüğümüz şey örneklemeydi. Sitenin 150 sayfasının tamamı tek tek Lighthouse'tan geçirildi ve sonuç şu çıktı: 137 sayfa dört başlıkta da 100, 13 sayfa değil. Erişilebilirlik, en iyi uygulamalar ve SEO her sayfada 100'dü; sapma yalnız performanstaydı.

On üç sayfanın on biri aynı dildeydi: Arapça. En düşüğü 83.

/ar/safecoast/     83
/ar/laya/          84
/ar/localmind/     84
/ar/adforge/       85
/ar/garanti/       85
/ar/gtin/          86
/ar/visionguard/   86
/ar/               89
/ar/growthos/      97
/ar/dream/         99
/ar/twin/          99

Sebebi Lighthouse doğrudan söyledi: Web font loaded → ar.woff2. Arapça yazı tipi geç gelip sayfayı yeniden dizdiriyordu. Arapça yedek yazı tipinin ölçüleri Noto Sans Arabic'ten çok farklı olduğu için kayma büyük çıkıyordu. Düzeltme, Martian Mono'da zaten verdiğimiz karardı: swap değil optional.

Buradaki asıl ders performansla ilgili değil. Örnekleme yapıp "site 100" demek, ölçmediğin sayfa hakkında iddiada bulunmaktır. On beş sayfa bu yüzden aylarca 83 puanla ayakta durdu, çünkü hiç bakmadık.

Sonucun sınırı

Puanın kendisi laboratuvar ölçümüdür. Sabit bir cihaz ve sabit bir ağ modeli varsayar; gerçek ziyaretçinin telefonu ve şebekesi bundan kötü olabilir. Aynı sayfa arka arkaya ölçüldüğünde 98 ile 100 arasında oynuyor. 100 puan "herkes için hızlı" demek değil, "ölçülebilen engellerin kaldırıldığı" demektir. Gerçek kullanıcı verisi biriktikçe bakılacak yer Chrome'un saha verisi olacak.

Bu üç düzeltmenin ortak noktası, hiçbirinin daha fazla iş yapmakla ilgili olmaması. Üçü de yanlış anda yapılan ya da hiç yapılmaması gereken işin kaldırılmasıydı.