Core Web Vitals: LCP, INP ve CLS Nasıl İyileştirilir?

Core Web Vitals nedir, üç metrik neyi ölçer?

Core Web Vitals, Google'ın web sayfalarındaki kullanıcı deneyimini ölçmek için seçtiği üç temel metriktir. Her biri deneyimin ayrı bir yüzüne bakar 1:

• LCP (Largest Contentful Paint): Görünür alandaki en büyük içerik öğesinin (genellikle ana görsel veya başlık bloğu) ekrana çizilme süresi. "Sayfa ne zaman yüklenmiş gibi görünüyor?" sorusunun cevabı.
• INP (Interaction to Next Paint): Kullanıcı tıkladığında, dokunduğunda veya tuşa bastığında, ekranda bir sonraki görsel güncellemenin ne kadar sürede geldiği.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken ve kullanılırken öğelerin beklenmedik şekilde yer değiştirme miktarı. Okurken metnin aşağı kayması tipik bir CLS sorunudur.

Eşikler Search Console raporunda üç kademeyle gösterilir 4:

Önemli ayrıntı: web.dev, bir sayfanın hedefi tutturup tutturmadığını sayfa yüklemelerinin 75. yüzdeliğinde ve mobil ile masaüstünü ayırarak ölçmeyi öneriyor 1. Yani ziyaretlerin dörtte üçü eşiğin içinde kalmalı. Ortalama değer değil, yavaş kullanıcıların deneyimi belirleyicidir.

INP, FID'in yerini ne zaman ve neden aldı?

Etkileşim tepkisi önceden FID (First Input Delay) ile ölçülüyordu. Chrome ekibi, FID'in etkileşimin bazı yönlerini yakalamadığını görünce INP'yi Mayıs 2022'de deneysel metrik olarak tanıttı 2. INP, 12 Mart 2024 tarihinde resmi olarak Core Web Vital oldu ve FID'in yerini aldı 2. Geçiş planına göre FID, Search Console'dan aynı gün kaldırıldı; PageSpeed Insights ve CrUX gibi diğer araçlar ise altı aylık bir geçiş süresi tanıdı 2.

Pratik sonuç: 2024 öncesi hazırlanmış performans raporlarında FID'e göre "iyi" görünen bir site, INP ile değerlendirildiğinde sorunlu çıkabilir. Eski denetim belgelerini bu gözle yeniden okuyun.

Saha verisi ile laboratuvar verisi: hangisine bakmalı?

Performans konuşmalarındaki en büyük karışıklık buradan doğar.

Saha verisi (field data), gerçek kullanıcıların tarayıcılarından toplanır. Google'ın Chrome User Experience Report'u (CrUX), Chrome kullanıcılarının son 28 günlük ziyaretlerini örnekler ve 75. yüzdeliği performans değeri olarak raporlar 3. Search Console'daki Core Web Vitals raporu bu veriye dayanır; benzer sayfaları gruplar ve bir grubun durumunu en kötü metriğine göre belirler 4.

Laboratuvar verisi (lab data), tek bir cihaz ve ağ ayarıyla yapılan kontrollü testtir; Lighthouse en bilinen örneğidir. Laboratuvar araçları LCP ve CLS'yi ölçebilir ama gerçek bir kullanıcı etkileşimi olmadığı için INP yerine Total Blocking Time'ı vekil metrik olarak kullanır 1.

İki verinin farklı çıkmasının nedenleri: kullanıcıların cihaz ve bağlantı çeşitliliği, önbellekteki dosyalar, kişiselleştirilmiş içerik ve A/B testleri, geri-ileri önbelleği (bfcache) gibi tarayıcı optimizasyonları 3. PageSpeed Insights iki veriyi aynı ekranda gösterdiği için bu ayrımı görmenin en kolay yeridir: üstteki bölüm saha verisi, alttaki puan laboratuvar testidir.

Kural basit: sorunun var olup olmadığına saha verisiyle, nedenine laboratuvar verisiyle bakın.

Raporda veri yoksa ne olur?

Trafiği düşük yeni sitelerde Search Console "Veri yok" gösterebilir. Bunun iki nedeni vardır: mülk Search Console'a yeni eklenmiştir ya da seçilen cihaz türü için CrUX'ta anlamlı bilgi üretecek kadar veri yoktur 4. Kullanıcı gizliliği gereği bir URL grubunun raporda görünmesi için asgari miktarda veri gerekir; yeterli veri olmayan gruplarda Search Console daha üst düzeyde, alan adı (origin) bazında bir grup oluşturur 4. Bu durumda laboratuvar testleriyle ilerlemek ve kendi gerçek kullanıcı ölçümünüzü (RUM) kurmak mantıklıdır; örneğin Google'ın açık kaynak web-vitals JavaScript kütüphanesiyle metrikleri kendi analitik aracınıza gönderebilirsiniz.

Metrik başına sık nedenler ve çözümler

Aşağıdaki tablo, web.dev'in optimizasyon rehberlerinden derlenen en sık nedenleri ve karşılık gelen çözümleri özetliyor.

LCP: dört alt parça

web.dev, LCP süresini dört ardışık parçaya ayırıyor: ilk bayta kadar geçen süre (TTFB), kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe çizim gecikmesi 5. Bu ayrım teşhisi hızlandırır. Örneğin sunucu hızlı ama LCP görseli geç başlıyorsa sorun "kaynak yükleme gecikmesi"dir ve çözüm görseli ilk HTML'de keşfedilebilir hale getirmek, gerekirse fetchpriority="high" eklemektir 5. Sık yapılan hata, LCP görseline de tembel yükleme uygulamaktır; tarayıcı görseli ancak düzen hesaplandıktan sonra ister.

INP: üç aşama

Bir etkileşim üç aşamadan oluşur: giriş gecikmesi (ana iş parçacığı meşgul olduğu için olay işleyicisinin başlayamaması), işleme süresi (olay işleyicilerin çalışması) ve sunum gecikmesi (bir sonraki karenin çizilmesi) 6. Uzun görevleri bölmek, ana iş parçacığına yol vermek, düzen hesaplamasını tetikleyen okuma-yazma döngülerinden (layout thrashing) kaçınmak ve DOM'u küçük tutmak temel çözümlerdir 6. E-ticaret sitelerinde filtre tıklamaları ve "sepete ekle" düğmeleri INP'nin en çok bozulduğu yerlerdir.

CLS: alan ayırmak

CLS'nin çoğu nedeni aynı ilkeyle çözülür: içerik gelmeden önce yerini ayırın. Görsellere genişlik ve yükseklik vermek, reklam ve gömülü içerik için minimum yükseklik tanımlamak, kullanıcı etkileşimi olmadan içerik eklememek ve animasyonlarda transform kullanmak web.dev'in önerileri arasında 7. Sayfanın geri-ileri önbelleğine uygun olması da tekrar ziyaretlerde kaymaları azaltır 7.

Sayfa deneyiminin sıralamadaki yeri nedir?

Burada beklentiyi doğru kurmak gerekir. Google, Core Web Vitals'ın sıralama sistemlerinde kullanıldığını söylüyor; ancak "sayfa deneyimi" adında tek bir sinyal olmadığını, sıralama sistemlerinin sayfa deneyimiyle uyumlu birçok sinyale baktığını belirtiyor 8. Aynı dokümanda iki cümle önemli: Search Console'da iyi sonuç almak sayfaların üst sıralarda yer alacağı anlamına gelmez ve Google, sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeye çalışır 8. Benzer alaka düzeyine sahip sayfalar arasında ise sayfa deneyimi daha belirleyici olabilir.

Bu yüzden Core Web Vitals'ı "sıralama hilesi" olarak değil, hemen çıkma ve dönüşüm kaybını azaltan bir kullanıcı deneyimi işi olarak ele alın. Genel teknik öncelik sırası için teknik SEO kontrol listemize bakabilirsiniz; indekslenmeyen bir sayfanın hızını iyileştirmek sonuç vermez.

Adım adım iyileştirme planı

Aşağıdaki sıra, sınırlı geliştirici zamanını en çok etkilenen sayfalara yönlendirir:

1. Search Console Core Web Vitals raporunu açın, mobil ve masaüstünü ayrı okuyun; "Kötü" grupları ve hangi metrikten kaynaklandığını listeleyin.
2. Her gruptan temsilî bir URL seçin ve PageSpeed Insights'ta saha verisi ile laboratuvar teşhisini birlikte inceleyin.
3. LCP için alt parçaları belirleyin: sorun sunucuda mı, keşifte mi, indirmede mi, çizimde mi?
4. INP için en sık kullanılan etkileşimleri test edin: menü, filtre, form, sepete ekle. DevTools Performance panelinde uzun görevleri bulun.
5. CLS için sayfayı yavaş bağlantıda yükleyip izleyin; hangi öğenin kaydığını not edin.
6. Düzeltmeleri şablon düzeyinde yapın. Tek sayfa yerine ürün, kategori veya blog şablonunu düzeltmek tüm grubu etkiler.
7. Yayından sonra Search Console'da doğrulamayı başlatın; 28 günlük izleme süresince yeni değişiklik eklemekten kaçının 4.
8. Sonucu saha verisiyle kaydedin ve bir sonraki sürümde gerilemeyi önlemek için performans bütçesi belirleyin.

Next.js veya React ile kurulmuş sitelerde istemci tarafı işleme hem INP'yi hem de içeriğin tarayıcılara ulaşmasını etkiler; ayrıntılar JavaScript SEO yazımızda. Şablon düzeyinde performans iş listesi için teknik SEO hizmetimize göz atabilirsiniz.