Core Web Vitals: üç metrik, gerçek kullanıcı verisi ve doğru sıralı düzeltmeler

Üç metrik, üç eşik: neye bakılır?

Eşikler Google’ın web.dev belgelerinde yer alır; INP için 200 ms altı “iyi”, 500 ms üstü “kötü”dür.¹⁵ Değerlendirme, sayfa yüklemelerinin 75. yüzdeliğinde mobil ve masaüstü ayrı ayrı yapılır.¹

Hangisine güvenilir: saha verisi mi, laboratuvar mı?

Lighthouse ve benzeri laboratuvar araçları kontrollü bir cihaz ve ağda tek bir yükleme simüle eder; hata ayıklamak için eşsizdir. Fakat Core Web Vitals kararı gerçek kullanıcılardan toplanan saha verisiyle verilir (Chrome Kullanıcı Deneyimi Raporu ve kendi RUM kayıtlarınız; RUM, gerçek ziyaretçilerin tarayıcısından toplanan ölçümdür). Özellikle INP laboratuvarda yanıltıcıdır: etkileşim yoksa ölçülemez, web.dev de yükleme sırasını ve yaygın kullanıcı akışlarını test etmeyi önerir.⁵

Ne yapmalı: önce Search Console’un Core Web Vitals raporunda hangi URL grubunun kötü olduğunu bulun, sonra o grubun tipik sayfasını laboratuvarda açıp sebebi arayın. Tersini yapmayın: laboratuvar skorundan yola çıkıp sağlıklı bir sayfayı düzeltmeye uğraşmak zaman kaybıdır.

LCP’yi iyileştirmek

LCP dört alt parçadan oluşur: ilk bayta kadar süre (TTFB), kaynağı keşfetme gecikmesi, kaynağı indirme süresi ve öğeyi çizme gecikmesi. web.dev’in yol gösterici oranları yaklaşık %40 TTFB, %10’dan az keşif gecikmesi, %40 indirme ve %10’dan az çizim gecikmesidir; yani süre çoğunlukla HTML’i ve LCP kaynağını yüklemeye gitmeli, “gecikme” parçaları sıfıra yakın olmalıdır.⁶

• Keşif: LCP görseli ilk HTML yanıtında bulunabilmelidir. Görsel yalnız CSS ya da JavaScript içinden çağrılıyorsa <link rel="preload"> ile öne alın.⁶
• Öncelik: LCP olması beklenen <img>’e fetchpriority="high" verin; ama çok sayıda görsele vermek etkisini düşürür.⁶
• Tembel yükleme: LCP görselini asla loading="lazy" yapmayın; keşif gecikmesini artırır.⁶
• TTFB: LCP, önceki sayfanın kapanışı, bağlantı kurma, yönlendirme ve TTFB gecikmelerini de içerir.³ Yönlendirme zincirini kısaltmak, önbellek ve CDN burada kazandırır.

INP’yi iyileştirmek

INP üç evreden oluşur: giriş gecikmesi (olay işleyicilerin başlamasını bekleme), işleme süresi ve sunum gecikmesi (işleyiciler bittikten sonra bir sonraki karenin çizilmesi). Giriş gecikmesinin yaygın sebebi ana iş parçacığındaki uzun görevlerdir.⁵ Pratikte sırayla şuna bakılır:

• Üçüncü taraf betikler (etiket yöneticisi, sohbet, A/B test): çoğu sitede uzun görevlerin ilk kaynağıdır. Gerçekten gerekmeyeni kaldırın, geri kalanı etkileşimden sonra ya da boşta yükleyin.
• Büyük DOM ve ağır yeniden düzenleme (layout) maliyeti sunum gecikmesini artırır.⁵
• Uzun görevleri bölün; kullanıcıya hemen görsel geri bildirim verin, ağır işi sonraya bırakın.

Kaydırma, üzerine gelme ve yakınlaştırma INP’ye girmez; tıklama, dokunma ve klavye girer.⁵

CLS’yi iyileştirmek

Kaymaların dört klasik sebebi vardır ve çözümleri nettir:⁴

• Boyutsuz görsel ve video: width/height (ya da aspect-ratio) tanımlayın, alanı önceden ayırın.
• Sonradan yüklenen içerik (reklam, gömülü içerik, çerez şeridi): yer ayırın, yüklenirken göstergeyi sabit alana koyun.
• Web yazı tipleri: yedek yazı tipinin ölçülerini web fontuna yaklaştırın; yazı tipi değişiminde metin bloğu zıplamasın.
• Animasyon: height/top yerine transform kullanın.

Kullanıcı girdisinden sonraki 500 ms içindeki kaymalar CLS’ye sayılmaz.⁴

Nereden başlamalı, ne beklemeli?

1. Önce kötü URL gruplarını bulun (şablon bazında: ürün, kategori, yazı). Tek şablonu düzeltmek yüzlerce URL’yi kurtarır.
2. Her şablonda tek metriğe odaklanın; ölçümün saha verisine yansıması takvim olarak haftalar sürer, çünkü Chrome verisi kayan bir pencerede toplanır.
3. Core Web Vitals’ı “sıralama kaldıracı” olarak görmeyin, başkasına da öyle sunmayın. Google, sayfa deneyiminde tek bir sinyal olmadığını, Core Web Vitals’ın sıralama sistemlerince kullanıldığını ama içeriğin alaka ve kalitesinin yerini tutmadığını belirtir.² Gerçek kazanç genellikle dönüşüm ve terk oranlarında görülür.

Şablon bazlı hızlı kazanım tablosu

Raporlama: hangi sayıyı yönetime gösterirsiniz?

Tek bir “hız skoru” yönetimi yanıltır. Şu üç kalemi birlikte sunun:

• “İyi” URL oranı (Search Console), şablon bazında; tek bir “skor” yerine.
• 75. yüzdelik değerleri (LCP, INP, CLS) mobil ve masaüstü ayrı.¹
• İş metriği bağı: aynı şablonun dönüşüm ve terk oranı. Hız çalışmasının yatırım getirisi çoğunlukla burada ortaya çıkar.

Laboratuvar skorundaki küçük oynamalar (örneğin Lighthouse’ta 3 puan) gürültüdür; kararı saha verisinin kalıcı değişimiyle verin. Sıradaki adım: aşağıdaki ücretsiz ölçümle kendi sayfanızın üç değerine bakın ve yukarıdaki tabloda size uyan belirtiyi bulun.