Core Web Vitals ve Sayfa Hızı

Core Web Vitals, Google'ın sayfa deneyimini ölçmek için tanımladığı üç metrikten oluşur. Bu metrikler laboratuvar testi değil, siteyi gerçekten ziyaret eden kullanıcıların tarayıcılarından toplanan veriye dayanır. Sıralamada tek başına belirleyici olmasalar da, benzer güçteki sayfalar arasında fark yaratan ve her hâlükârda dönüşüm oranını etkileyen ölçülerdir.

Üç metrik neyi ölçüyor ve eşikleri ne?

Metriklerin her biri kullanıcı deneyiminin farklı bir yönünü ölçer. Google'ın yayımladığı eşik değerler şöyledir:

Bu üç metriğin arasındaki değerler "iyileştirme gerekiyor" aralığıdır. Değerlendirme, sayfa yüklemelerinin yüzde 75'lik diliminden yapılır; yani kullanıcıların dörtte üçünün gördüğü deneyim esas alınır. Ölçüm mobil ve masaüstü için ayrı raporlanır ve son 28 günü kapsayan kayan bir pencereden hesaplanır.

INP, 2024 yılının Mart ayında FID metriğinin yerini almıştır. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise sayfa üzerindeki tüm etkileşimleri değerlendirir ve bu nedenle gerçek yanıt verme davranışını daha doğru yansıtır.

Saha verisi ile laboratuvar verisi neden farklı çıkar?

PageSpeed Insights aynı ekranda iki tür veri gösterir. Üstteki bölüm saha verisidir ve Chrome Kullanıcı Deneyimi Raporu'ndan gelir. Alttaki bölüm ise Lighthouse'un o anda simüle ettiği laboratuvar testidir. İkisi çoğu zaman uyuşmaz.

Fark doğaldır: laboratuvar testi belirli bir cihaz ve ağ profiliyle, tek bir yüklemede yapılır. Saha verisi ise farklı cihazlar, farklı bağlantılar ve farklı kullanıcı davranışlarının bileşimidir. Karar verirken saha verisi esas alınır; laboratuvar verisi ise sorunun nerede olduğunu bulmak için kullanılır.

Yeni yayına alınan ya da az trafik alan sayfalarda saha verisi bulunmayabilir. Bu durumda site genelindeki veri kullanılır; sayfa düzeyinde veri oluşması için yeterli sayıda ziyaret gerekir.

LCP nasıl iyileştirilir?

LCP ögesi genellikle ekranın üst kısmındaki büyük görsel ya da başlık metnidir. İyileştirme dört aşamada ele alınır:

1. Sunucu yanıt süresi. İlk bayta kadar geçen sürenin 800 ms altında kalması hedeflenir. Önbellekleme, veritabanı sorgu optimizasyonu ve içerik dağıtım ağı kullanımı bu aşamanın araçlarıdır.
2. Kaynak keşfi. LCP görselinin HTML içinde doğrudan yer alması, CSS arka planı olarak gizlenmemesi gerekir. Görsele fetchpriority="high" verilir ve tembel yükleme uygulanmaz.
3. Engelleyici kaynaklar. Baş bölümündeki senkron JavaScript ve büyük CSS dosyaları oluşturmayı geciktirir. Kritik CSS ayrılır, geri kalanı ertelenir.
4. Görsel boyutu. Görseller WebP ya da AVIF biçiminde, gösterildikleri boyuta uygun ölçüde sunulur. Ekran genişliğine göre farklı boyut sunmak için srcset kullanılır.

Yazı tipleri de LCP'yi etkiler. Harici bir kaynaktan yüklenen yazı tipi geldiğinde metin görünmüyorsa, LCP süresi yazı tipinin inmesini bekler. font-display özelliğinin swap olarak ayarlanması ve yazı tipi dosyalarının kendi sunucunuzdan sunulması bu gecikmeyi azaltır.

INP değerini ne bozar?

INP, kullanıcı bir düğmeye bastığında ekranda bir değişiklik görünene kadar geçen süredir. Bu süreyi uzatan asıl etken, ana iş parçacığını uzun süre meşgul eden JavaScript görevleridir. Tarayıcı tek bir iş parçacığında hem sizin kodunuzu çalıştırır hem de ekranı boyar; kod uzun sürerse boyama gecikir.

Uygulamada en sık karşılaşılan nedenler şunlardır: üçüncü taraf etiket yöneticilerine yığılmış çok sayıda betik, sayfa yüklenirken çalışan ağır analiz kodları, her tuş vuruşunda tetiklenen arama önerileri ve gereğinden büyük çerçeve paketleri.

İyileştirme yolu, uzun görevleri parçalamak ve gereksiz işi ertelemektir. Kullanıcı etkileşiminin hemen ardından görsel geri bildirim verilir, ağır hesaplama sonraki kareye bırakılır. Ayrıca kullanılmayan üçüncü taraf betikleri kaldırılır; çoğu sitede en hızlı kazanç buradan gelir.

CLS neden oluşur ve nasıl önlenir?

Düzen kayması, sayfa yüklenirken içeriğin yer değiştirmesidir. Kullanıcı okumaya başladığı satırın kayması ya da tıklamak üzereyken düğmenin yer değiştirmesi bu metriğe yansır. Başlıca nedenler ve çözümleri şunlardır:

• Boyutu belirtilmemiş görseller. Her img ögesine width ve height verilir; tarayıcı yer ayırır.
• Sonradan eklenen reklam ve gömülü içerik. Konteynerlere sabit yükseklik tanımlanır.
• Yazı tipi değişimi. Yedek yazı tipi ile asıl yazı tipinin ölçüleri size-adjust ve ascent-override ile yakınlaştırılır.
• Üstte açılan bildirim çubukları. İçeriği aşağı itmek yerine üzerine bindirilir.
• Sonradan yüklenen içerik. Yer tutucu bloklar kullanılır.

CLS'in tamamen sıfıra indirilmesi çoğu projede mümkündür ve genellikle en düşük maliyetli iyileştirmedir.

İyileştirme sonrası sonuç ne zaman görünür?

Saha verisi 28 günlük kayan pencereden hesaplandığı için, canlıya alınan bir düzeltmenin raporlara tam yansıması yaklaşık dört hafta sürer. Search Console'un Core Web Vitals raporunda ise doğrulama süreci ayrıca zaman alır. Bu nedenle düzeltme sonrası ilk hafta rapora bakıp sonuç çıkarmak yanıltıcıdır.

Ara dönemde ilerlemeyi görmek için sitenize gerçek kullanıcı ölçümü eklenebilir. Tarayıcının web-vitals kütüphanesiyle toplanan değerler kendi analitiğinize gönderildiğinde, değişimin etkisi günlük olarak izlenebilir.

Hız çalışması sıralamayı doğrudan yükseltir mi?

Hayır, doğrudan bir yükselme beklenmemelidir. Google, sayfa deneyiminin sıralama sistemlerinde dikkate alındığını belirtir; ancak içerik alaka düzeyinin önüne geçmez. Zayıf içerikli hızlı bir sayfa, güçlü içerikli yavaş bir sayfayı geçmez.

Buna karşılık hız çalışmasının ölçülebilir bir yan etkisi vardır: mobil kullanıcıların sayfayı terk etme eğilimi azalır, form ve sepet adımlarında tamamlanma oranı artar. Bu nedenle hız iyileştirmesini bir sıralama işi değil, bir dönüşüm işi olarak planlamak daha gerçekçidir.

Üçüncü taraf betikler nasıl denetlenir?

Çoğu sitede performans sorununun kaynağı, zamanla biriken üçüncü taraf araçlardır: analiz kodları, sohbet pencereleri, reklam etiketleri, öneri motorları, çerez bildirimleri ve sosyal medya bileşenleri. Bunların her biri ayrı bir ağ isteği açar ve çoğu ana iş parçacığında kod çalıştırır.

Denetim için tarayıcı geliştirici araçlarının ağ ve performans sekmeleri kullanılır. Her betiğin indirdiği bayt miktarı, çalışma süresi ve ana iş parçacığını ne kadar meşgul ettiği listelenir. Ardından pazarlama ekibiyle birlikte, her aracın hâlâ kullanılıp kullanılmadığı gözden geçirilir. Uygulamada bu listenin önemli bir bölümünün artık kimse tarafından izlenmediği görülür.

Kalması gereken araçlar için üç yöntem vardır: yüklemeyi kullanıcı etkileşimine kadar geciktirmek, betiği ana iş parçacığından ayırmak ve sunucu tarafı etiketleme kullanmak. Sohbet pencereleri ve öneri modülleri, gecikmeli yüklemeye en uygun bileşenlerdir.

Hangi araç hangi aşamada kullanılır?

Sorunun teşhisi ile takibi farklı araçlar gerektirir. Aşama aşama kullanılan araçlar şunlardır:

• PageSpeed Insights. İlk bakış için; saha ve laboratuvar verisini bir arada gösterir.
• Chrome geliştirici araçlarının performans kaydı. Uzun görevlerin hangi kod satırlarından kaynaklandığını gösterir.
• Lighthouse. Sayfa bazında ayrıntılı öneri listesi çıkarır; sıralama etkisi olan bir puan değil, teşhis aracı olarak okunur.
• Search Console Core Web Vitals raporu. Site genelinde hangi sayfa gruplarının sorunlu olduğunu gösterir; benzer şablondaki sayfaları birlikte listeler.
• Gerçek kullanıcı ölçümü. Kendi analitiğinize gönderilen değerlerle günlük takip sağlar.

Search Console raporunun sayfaları şablona göre gruplaması, çalışmanın önceliklendirilmesini kolaylaştırır. Tek bir ürün sayfasını düzeltmek yerine, o şablonu kullanan binlerce sayfayı birlikte iyileştirmek mümkün olur.

Özetle: Core Web Vitals üç metrikten oluşur ve gerçek kullanıcı verisinden, yüzde 75'lik dilim üzerinden hesaplanır. LCP sunucu ve görsel tarafında, INP JavaScript tarafında, CLS ise düzen tanımlarında çözülür. Etkinin raporlara yansıması dört haftayı bulur; asıl kazanç sıralamadan çok kullanıcı davranışında görünür.