Web performansı.
Web performansı, bir sayfanın ne kadar hızlı yüklendiğini, ne kadar hızlı tepki verdiğini ve yüklenirken ne kadar kararlı durduğunu ölçen üç boyutlu bir kalite ölçütüdür.
Performans tartışmalarının çoğu tek bir sayıya indirgeniyor ve o sayı genelde yanlış olanı: bir denetim aracının verdiği skor. Oysa performans tek boyutlu değil. Bir sayfa çok hızlı açılıp tıklamalara geç yanıt verebilir; hızlı ve tepkisel olup yüklenirken altınızdan kayabilir. Google'ın Core Web Vitals ölçütleri tam olarak bu üç ayrı boyutu ayırmak için tanımlandı.
Bu rehber üç şey yapıyor. Üç metriğin ne ölçtüğünü ve eşiklerini net biçimde ayırıyor. Laboratuvar ölçümü ile saha verisi arasındaki farkı — ki en pahalı yanlış anlamaların kaynağı orası — açıklıyor. Ve performansın sonradan eklenen bir optimizasyon değil bir tasarım kısıtı olduğunu, ölçülmüş örneklerle savunuyor.
Üç metrik, üç ayrı soru
Core Web Vitals üç metrikten oluşuyor ve üçü birbirinin yerine geçmiyor. Bir sayfanın «iyi» sayılması için üçünün de eşiği geçmesi gerekiyor — biri kırıldığında diğer ikisinin mükemmel olması durumu kurtarmıyor.
- LCP — sayfanın en büyük görünür içeriği ne zaman boyandı? İyi eşik 2,5 saniye. Soruyu şöyle sorar: kullanıcı ne zaman «sayfa geldi» diyor?
- INP — kullanıcının tıklama, dokunma ve tuş girişlerine sayfa ne kadar hızlı görsel yanıt veriyor? İyi eşik 200 milisaniye. 2024 Mart'ında FID'in yerini aldı.
- CLS — sayfa yüklenirken ya da kullanılırken içerik ne kadar beklenmedik biçimde kaydı? İyi eşik 0,1. Birimsizdir; kayan alanın büyüklüğü ile kayma mesafesinin çarpımından hesaplanır.
Üçünün ayrı olması bir tasarım kararı. LCP yükleme hızını, INP etkileşim tepkiselliğini, CLS görsel kararlılığı ölçüyor. Bir sayfa üç boyutta da bağımsız olarak iyi ya da kötü olabilir ve her birinin kendi tedavisi var — LCP'yi düzelten iş genelde INP'ye dokunmaz.
INP'nin FID'in yerini alması özellikle önemliydi çünkü FID yalnız İLK etkileşimin GECİKMESİNİ ölçüyordu. Bir sayfa ilk tıklamaya hızlı yanıt verip sonraki her tıklamada donabilir ve FID yine iyi çıkardı. INP tüm oturumdaki etkileşimlere bakıyor ve gecikmeyi değil TAM DÖNGÜYÜ — girişten bir sonraki boyamaya kadar — ölçüyor. Yani çok daha zor bir sınav.
Saha verisi ile laboratuvar ölçümü
Performans tartışmalarındaki en pahalı yanlış anlama burada yaşanıyor. Bir denetim aracı sayfayı kendi kontrollü ortamında açar ve bir skor verir; bu laboratuvar ölçümüdür. Google'ın sıralamada kullandığı veri ise gerçek kullanıcıların gerçek cihazlarda ve gerçek ağlarda yaşadığı deneyimden toplanır; bu saha verisidir.
İkisi rutin olarak ayrışır ve ayrışma yönü genelde aynıdır: laboratuvar iyi, saha kötü. Sebebi basit — laboratuvar ölçümü sabit bir cihaz ve sabit bir ağ varsayar, oysa gerçek kullanıcıların önemli bir bölümü düşük güçlü telefonlarda ve değişken bağlantılarda geziniyor.
Pratik sonuç: laboratuvar skoru bir teşhis aracıdır, bir hedef değil. Neyin yavaş olduğunu gösterir ve tekrar edilebilir olduğu için değişikliğin etkisini ölçmeye yarar. Ama «biz iyiyiz» hükmü yalnız saha verisinden verilebilir.
Laboratuvar skoru neyin yavaş olduğunu söyler; iyi olup olmadığınızı yalnız saha verisi söyler.
Bu sitede saha verisi bir cache dosyasına çekiliyor ve şeritte gösteriliyor — ama veri yoksa alan HİÇ RENDER EDİLMİYOR. Doğrulama süiti bunu ayrıca ölçüyor: veri gelmediğinde «ölçülen LCP» yazısı hiç çıkmamalı. Sahte kanıt yerine boş alan tercih ediliyor.
Performans bir tasarım kısıtıdır
Yaygın çalışma biçimi şu: site tasarlanır, kurulur, sonra bir denetim koşulur ve çıkan liste düzeltilir. Bu sırayla yapıldığında düzeltmelerin çoğu kozmetik kalır çünkü asıl maliyetler tasarım aşamasında kilitlenmiştir.
Somut örnekler: kaç yazı tipi ailesi kullanılacağı bir tasarım kararıdır ve doğrudan LCP'yi etkiler. Hero alanında video mu görsel mi olacağı bir tasarım kararıdır. Kaç animasyon katmanı kurulacağı bir tasarım kararıdır ve INP'yi belirler. Bunlar sonradan «optimize edilemez», yalnız geri alınabilir.
Sağlıklı yöntem, performansı bir bütçe kalemi saymaktır. Bütçe baştan konur, tasarım o bütçenin içinde yapılır ve her dağıtımda ölçülür. Bu sitede bütçe pazarlık dışı olarak tanımlı: LCP 1,8 saniyenin altında, CLS 0,05'in altında, INP 200 milisaniyenin altında ve toplam JavaScript 150 kilobayt gzip'in altında.
Bütçenin gerçekten tutup tutmadığı ölçüldü: vendor kütüphaneleri gzip sonrası 55,7 kilobayt, sitenin kendi kodu 28 kilobayt — toplam 83,7 kilobayt, tavanın epey altında. Ana stil dosyası 67,4 kilobayt kaynak, gzip sonrası 12,4 kilobayt. Canlı sunucudan ölçülen ilk bayt süresi 0,302 saniye.
Ölçmeden «oldu» denmez
Performans çalışmasının en sinsi tuzağı, iyileştirmenin gerçekten iyileştirme olduğunu varsaymaktır. Bir değişiklik mantıklı görünebilir, bilinen bir iyi uygulama olabilir ve yine de o sitede hiçbir şey değiştirmemiş — hatta kötüleştirmiş — olabilir.
Bu sitede tam olarak öyle bir vaka yaşandı ve kayda geçti. Yazı tipi yükleme davranışı bir düzen kayması kaynağı sanıldı ve düzeltilmek istendi. Ölçüm bir hatayı düzeltmedi — YANLIŞ BİR DÜZELTMEYİ engelledi: kayma başka bir yerden geliyordu ve planlanan değişiklik durumu bozacaktı.
İkinci vaka daha öğretici. Sayfa yüklenirken ölçülen düzen kayması sıfıra yakındı; ama kaydırma sırasında, sabitlenmiş bir bölüm bırakılırken bir kayma oluşuyordu. Klasik CLS ölçümü sayfa yükleme penceresine bakar ve bu kaymayı hiç görmez — kullanıcı ise tam olarak onu yaşar.
İkisinin ortak dersi şu: bir metriğin iyi çıkması, o metriğin ölçtüğü şeyin iyi olduğu anlamına geliyor; ölçmediği şey hakkında hiçbir şey söylemiyor. Bu yüzden bu sitede kaydırma sırasındaki kayma ayrı bir testle, oturum penceresi mantığıyla ölçülüyor ve 0,08 eşiğine bağlı.
Nereden başlamalı
Mevcut bir siteyi hızlandırmak isteyen biri için, etkiye göre sıralanmış bir başlangıç. Sıra önemli: üsttekiler hem daha çok kullanıcıyı etkiler hem de daha ucuzdur.
- Saha verisine bak — laboratuvar skoruna değil. Gerçek kullanıcılarda hangi metrik kırık?
- Render engelleyen kaynakları say — kaç stil dosyası, kaç senkron script? Her biri boyamayı geciktiriyor.
- En büyük görünür öğeyi bul — LCP öğesi hangisi? Genelde hero görseli ya da başlık. O öğe için her şey yapılabilir.
- Görsellere boyut ver — genişlik ve yükseklik bildirimi, CLS'in en yaygın kaynağını tek satırda kapatır.
- Yazı tipi sayısını azalt — her aile ek bir istek ve ek bir takas riski.
- JavaScript'i tart — gerçekten gereken ne kadarı? Ölçmeden kesme, ölçtükten sonra acımasız ol.
- Bütçe koy ve teste bağla — bir kereye mahsus iyileştirme, üç dağıtım sonra geri alınır.
Son madde en çok atlananıdır ve en pahalıya mal olandır. Performans düzeltmeleri sessizce bozulur: yeni bir kütüphane eklenir, yeni bir görsel boyutsuz gelir, yeni bir yazı tipi ailesi girer. Bütçe bir teste bağlıysa bozulma dağıtım anında görünür; bağlı değilse bir sonraki denetimde yeniden keşfedilir.
Kümenin geri kalanı bu adımların her birini ayrı ayrı ele alıyor — üç metriğin kendi sayfaları, ölçüm katmanlarının farkı, ve bu sitede ölçülerek öğrenilen iki kör nokta.