Core Web Vitals’ı bir tasarım kararı olarak okumak

Bir sitenin ilk izlenimi hero görseli değildir; hero görselinden önceki beklemedir. Kullanıcı bu beklemeyi kronometreyle ölçmez, hisseder: sayfa “ağır”, buton “tepkisiz”, metin “zıplıyor”.

Google’ın Core Web Vitals metrikleri bu hisleri üç ölçüme çevirir. Bu metrikleri projenin sonunda geliştiricinin önüne konan bir kontrol listesi olarak değil, ilk eskizde verilen tasarım kararlarının sonucu olarak görüyoruz. Bu yazıda her birinin arayüzde neye karşılık geldiğini anlatıyor, ortasında da gecikmeyi elinizle deneyebileceğiniz küçük bir demo kuruyoruz.

Üç metrik, üç soru

• LCP (Largest Contentful Paint) — “Geldi mi?” Sayfadaki en büyük içerik öğesinin, genellikle hero görselinin ya da ana başlığın, ekrana çizildiği an.
• INP (Interaction to Next Paint) — “Beni duydu mu?” Kullanıcı tıkladığında, dokunduğunda ya da yazdığında ekranın ilk görsel tepkiyi verdiği süre. Mart 2024’te FID’in yerini aldı.
• CLS (Cumulative Layout Shift) — “Yerinde duruyor mu?” Sayfa yüklenirken öğelerin beklenmedik kaymalarının toplamı. Tam tıklayacakken aşağı kayan buton, CLS’nin en tanıdık hâlidir.

Google bu metrikleri gerçek kullanıcı verisinin 75. yüzdelik diliminde değerlendirir. Yani ziyaretlerin dörtte üçü eşiğin altında kalıyorsa sayfa “iyi” sayılır.

Beklemenin bir bedeli var

Hızın iş sonuçlarına etkisi yıllardır ölçülüyor. Google ve SOASTA’nın 2017’de mobil siteler üzerinde yaptığı araştırma, yükleme süresi uzadıkça ziyaretçinin sayfayı hiçbir şey yapmadan terk etme olasılığının nasıl arttığını gösteriyor.

Üç saniye kulağa kısa geliyor; yine de hemen çıkma olasılığını üçte bir artırıyor. Tersi de geçerli: Deloitte’un Google için hazırladığı Milliseconds Make Millions raporunda, mobil site hızındaki yalnızca 0,1 saniyelik iyileşme perakende sitelerinde dönüşümü %8,4, seyahat sitelerinde %10,1 artırdı.

INP: tıklama ile tepki arasındaki boşluk

Tarayıcı, sayfadaki JavaScript’in büyük kısmını tek bir ana iş parçacığında (main thread) çalıştırır. Aynı iş parçacığı ekranı da boyar. Bir tıklamanın ardından ağır bir iş başlarsa, tarayıcı o iş bitene kadar ekranı güncelleyemez; buton basılmamış gibi durur, animasyonlar donar.

INP tam olarak bu boşluğu ölçer: etkileşimden bir sonraki boyamaya kadar geçen süreyi. Aşağıdaki demoda ana iş parçacığını sahiden meşgul ediyoruz. Bir gecikme seçin ve butona basın.

Ne değişti?

İki denemede de yapılan iş aynı ve aynı süreyi aldı. Değişen tek şey sıralamaydı. Geri bildirim açıkken buton önce basılı hâle geçti, tarayıcıya bir kare çizme fırsatı verildi, ağır iş ondan sonra başladı. INP bir sonraki boyamaya kadar olan süreyi ölçtüğü için, işin kendisi kısalmadan ölçüm iyi bölgeye geçti.

Pratikteki karşılığı basit: önce haber ver, sonra çalış.

• Tıklamada ekranı hemen güncelleyin: basılı durum, yükleniyor göstergesi, iyimser (optimistic) arayüz.
• Uzun işleri parçalayın ve aralarda tarayıcıya nefes aldırın: scheduler.yield(), desteklemeyen tarayıcılarda setTimeout.
• Gerçekten ağır hesaplamaları Web Worker’a taşıyın; ana iş parçacığı ekrana ait kalsın.
• Her etkileşime paket paket JavaScript bağlamayın. Bu siteyi Astro ile kurduk: sayfalar varsayılan olarak JavaScript’siz gelir, yukarıdaki demo gibi etkileşimli parçalar kendi küçük bileşenleri olarak yüklenir.

LCP ve CLS tasarım masasında kazanılır

LCP ve CLS sorunlarının çoğu kod yazılmadan önce, tasarımda başlar.

Hero görseli

En büyük öğe çoğu zaman hero görselidir. Onu AVIF ya da WebP olarak, ekran genişliğine uygun boyutlarda sunmak ve tembel yüklemeye (lazy loading) dahil etmemek gerekir. Görsel tasarlanırken dosya ağırlığı da tasarım kararıdır: tam ekran bir fotoğraf yerine güçlü bir tipografi ve hafif bir doku çoğu zaman hem daha hızlı hem daha karakterlidir.

Yazı tipleri

Her ağırlık ayrı bir dosyadır. Tasarımda dört ağırlık yerine iki ağırlıkla çalışmak doğrudan hız kazandırır. Türkçe karakterler için doğru alt kümeyi (latin-ext) yüklemek, “ş” ya da “ğ” harfinin yedek fonttan gelip satırı zıplatmasını önler.

Yer ayırmak

Görsellere, videolara ve gömülü içeriklere genişlik ve yükseklik ya da aspect-ratio verin. Duyuru bantları ve çerez bildirimleri içeriği aşağı itmemeli, sayfanın üstüne binmeli.

Hareket

Yalnızca transform ve opacity üzerinden animasyon yapın; bu ikisi sayfa düzenini yeniden hesaplatmaz. Kendi 404 sayfamızdaki kedi oyununda mobilde yaşanan takılmayı, hareketleri left/top yerine transform ile yaparak çözdük.

Ölçmeden iyileştirme olmaz

Lighthouse gibi laboratuvar araçları kontrollü bir ortamda tek bir ölçüm yapar ve sorunu bulmak için idealdir. Google’ın değerlendirmesi ise gerçek kullanıcılardan toplanan saha verisine dayanır. Search Console’daki Core Web Vitals raporu ve Chrome UX Report bu yüzden asıl karnedir.

Bir de şu var: siteyi fiber bağlantılı bir dizüstünde değil, orta segment bir Android telefonda ve mobil veriyle test edin. Kullanıcılarınızın büyük kısmı oradadır.

Hız, lansmandan sonra eklenen bir özellik değil. Hangi görselin, hangi fontun, hangi etkileşimin sayfaya gireceği daha ilk eskizde belirleniyor. Karar oradayken hızı da orada kazanmak en ucuzu.