Web Sitesi Hızı: Neyi Ölçmeli, Neyi Düzeltmeli

Sayfa hızı konuşulurken sıra neredeyse hep görsellere ve minify'a gelir. Oysa çoğu sitede beklemenin büyük kısmı, tarayıcı tek bir CSS dosyası indirmeden önce, sunucunun ilk baytı göndermesi sırasında geçer. Neyin ölçüldüğü ayrılmadan yapılan optimizasyon puanı yükseltip deneyimi aynı bırakıyor.

Hangi hızdan konuşuyoruz?

"Site yavaş" cümlesi tek bir şeyi tarif etmiyor. Kullanıcı bazen beyaz ekranda bekliyor, bazen içerik geliyor ama düğmeler tıklamaya cevap vermiyor, bazen de yazı yerine oturmuşken üstüne bir banner düşüp satırı aşağı kaydırıyor. Üçü farklı metrik, farklı sebep, farklı çözüm.

• TTFB: isteğin gidip ilk baytın dönmesi. Sunucu ve veritabanı işi.
• LCP: ekrandaki en büyük öğenin görünmesi. Genellikle bir görsel ya da başlık bloğu.
• CLS: yükleme sırasında yerinden kayan içerik. Süreyle değil, kararlılıkla ilgili.

Peki kullanıcı bunlardan hangisini şikayet olarak dile getirir? Çoğunlukla CLS'i, ama adını koyamadan: "bir şeye basacaktım, kaydı."

Ölçerken lab ile sahayı karıştırma

PageSpeed Insights aynı ekranda iki ayrı şey gösteriyor. Üstteki bölüm gerçek kullanıcılardan toplanan saha verisi, alttaki Lighthouse skoru ise sabit bir cihaz ve sabit bir bağlantı profiliyle o an yapılan sentetik bir koşu. 98 puan, sitenizi mobil veriyle açan kullanıcının ne kadar beklediğini söylemez.

Skoru kovalamanın tuzağı burada. Lighthouse'un ölçtüğü şeyi iyileştirmek kolaydır, çünkü senaryo bilinir; saha verisi kıpırdamıyorsa optimizasyon test ortamına yapılmış demektir. GTmetrix ve Pingdom farklı lokasyonlardan waterfall çıkarır, hangi isteğin diğerlerini beklettiğini görmek için o grafik tek bir puandan çok daha kullanışlıdır.

Gecikmenin çoğu ön yüzde değil

Görselleri sıkıştırıp CSS'i küçülttükten sonra hâlâ yavaş olan sitelerin ortak noktası yüksek TTFB'dir. Sebep genelde şablonda değil, sorgu sayısında: liste sayfasında her kayıt için ayrı sorgu atan bir döngü tek başına yarım saniyeyi yer. Sorgu logunu aç, bir sayfa isteğinde kaç sorgu döndüğüne bak. Sayı üç haneliyse ön yüzde yapacağın hiçbir şey fark ettirmez; onu ilişkili veriyi tek seferde çeken bir sorguyla çözersin, ek bir araç gerekmez.

Önbellek de aynı yerden devreye giriyor. Tam sayfa önbelleği TTFB'yi milisaniyelere indirir, ama sayfada sık değişen bölümler varsa asıl karar önbelleği hangi granülerlikte kurduğundur.

Ön yüzde gerçekten ne işe yarıyor

Hız listelerinde sıralanan bazı maddeler aslında hız önerisi değil. Görsellere alt metni yazmak erişilebilirlik ve arama için gerekli, indirme süresine etkisi yok. Görsel ve tablo boyutlarını HTML'de belirtmek de sayfayı hızlandırmıyor, tarayıcının yeri baştan ayırmasını sağlayıp kaymayı engelliyor, yani düzelttiği metrik CLS. İkisi de yapılmalı, doğru gerekçeyle.

Dosya birleştirme tavsiyesi ise HTTP/1.1 döneminden kalma. Tarayıcı başına altı paralel bağlantı sınırı varken istek sayısını azaltmak doğrudan kazançtı. HTTP/2 üzerinden istekler aynı bağlantıda çoğullanıyor, tek dev bundle'ın getirisi azalıyor, maliyeti ise net: bir satır CSS değiştiğinde tüm dosyanın önbelleği düşer ve kullanıcı her şeyi yeniden indirir. Sık değişen kodu ayrı tutmak bugün daha mantıklı.

Dizin bağlantılarının sonundaki eğik çizgi küçük ama ölçülebilir bir kalem: eksikse sunucu 301 döndürüyor, tarayıcı ikinci bir tur atıyor. Site içi bağlantılarda bu eksiği toplu bulup düzeltmek yarım saatlik iş.

Neye önce bakmalı

Sınırlı zaman varsa sıra şöyle işliyor. Önce TTFB, çünkü o düşmeden yapılan her ön yüz iyileştirmesi sabit bir gecikmenin üstüne biniyor. Sonra LCP öğesini bul ve yalnızca onu hızlandır, sayfadaki diğer görsellerin gecikmeli yüklenmesi yeterli. CLS en sona kalabilir, ama düzeltmesi en ucuz olandır.