Core Web Vitals rehberi: LCP, INP ve CLS nasıl ölçülür, nasıl iyileştirilir?

Core Web Vitals, Google’ın bir sayfanın kullanıcıya nasıl hissettirdiğini ölçmek için seçtiği üç metriktir: LCP (en büyük içeriğin yüklenme süresi), INP (etkileşime verilen yanıt süresi) ve CLS (görsel kayma). Bu metrikler tek başına sıralamayı belirlemez; ama iki sayfa içerik olarak birbirine yakınsa hızlı ve sakin açılan sayfa hem ziyaretçide hem arama motorunda avantaj kazanır. Bu rehberde her metriğin ne ölçtüğünü, hedef değerleri ve sitenizde neyi değiştirmeniz gerektiğini anlatıyoruz.

Üç metrik neyi ölçer?

Google bu değerleri gerçek ziyaretçilerin verisiyle ve 75. yüzdelik dilimde değerlendirir. Yani ziyaretlerin en az dörtte üçünün “iyi” aralıkta kalması gerekir. Mart 2024’ten itibaren INP, eski FID metriğinin yerini almıştır; FID yalnızca ilk etkileşimin gecikmesine bakarken INP sayfa boyunca yapılan tüm etkileşimleri hesaba katar.

Ölçüm: laboratuvar verisi ile saha verisi farkı

Hız ölçerken iki tür veriyle karşılaşırsınız:

• Saha verisi (field data): Chrome kullanıcılarından toplanan gerçek deneyim verisidir (CrUX). PageSpeed Insights’ın üst bölümünde ve Search Console’daki “Core Web Vitals” raporunda görünür. Az trafik alan sitelerde bu veri hiç oluşmayabilir.
• Laboratuvar verisi (lab data): Lighthouse gibi araçların tek bir simüle cihazda yaptığı testtir. Sorunu bulmak ve düzeltmeyi denemek için idealdir, ama gerçek kullanıcıların yaşadığının birebir aynısı değildir.

Pratik yol şudur: Search Console’daki saha raporuyla hangi sayfa gruplarının sorunlu olduğunu bulun, ardından PageSpeed Insights ve tarayıcının geliştirici araçlarıyla nedenini teşhis edin. Kendi sitenizi hızlıca kontrol etmek için SEO ve hız testimizi de kullanabilirsiniz.

LCP nasıl iyileştirilir?

LCP öğesi çoğu sitede ana sayfanın büyük kahraman görseli ya da ilk büyük başlıktır. Gecikmenin dört kaynağı vardır: sunucu yanıtı, kaynağın keşfedilmesi, kaynağın indirilmesi ve ekrana çizilmesi.

1. Sunucu yanıt süresini (TTFB) düşürün. Sayfa önbelleği, güncel PHP sürümü, veritabanı sorgularının azaltılması ve CDN kullanımı ilk baytın gelmesini hızlandırır. TTFB 800 ms’nin üstündeyse diğer düzeltmeler sınırlı fayda sağlar.
2. LCP görselini erken keşfettirin. Görsel CSS arka planı olarak ya da JavaScript ile ekleniyorsa tarayıcı onu geç fark eder. Normal bir img etiketi kullanın ve gerekirse fetchpriority="high" ekleyin.
3. LCP görseline asla loading="lazy" vermeyin. Tembel yükleme ekranın altındaki görseller içindir; ilk ekrandaki görseli geciktirir.
4. Görseli küçültün. WebP veya AVIF biçimi, doğru boyutlandırma ve srcset ile mobil cihaza masaüstü boyutunda görsel göndermekten kaçının. Ayrıntılar için görsel optimizasyonu rehberimize bakın.
5. Oluşturmayı engelleyen kaynakları azaltın. Başlıkta yüklenen büyük CSS ve senkron JavaScript dosyaları sayfanın çizilmesini bekletir. Kritik CSS’i küçük tutun, betikleri defer ile yükleyin.
6. Web fontlarını dikkatli yükleyin. Başlık metni LCP öğesiyse ve font geç geliyorsa font-display: swap ve yalnız kullanılan ağırlıkları yüklemek fark yaratır.

INP nasıl iyileştirilir?

INP kötü çıkıyorsa sorun neredeyse her zaman ana iş parçacığını meşgul eden JavaScript’tir. Kullanıcı bir düğmeye bastığında tarayıcı o sırada başka bir uzun görevi bitirmeye çalışıyorsa yanıt gecikir.

• Kullanılmayan betikleri kaldırın. Eklenti, sohbet balonu, ısı haritası ve birden fazla analitik kodu yan yana çalıştığında ana iş parçacığı sürekli doludur. Her betik için “bu gerçekten gerekli mi?” sorusunu sorun.
• Uzun görevleri bölün. 50 ms’yi aşan JavaScript görevleri “uzun görev” sayılır. Ağır işleri parçalara ayırmak ya da kullanıcı etkileşiminden sonraya ertelemek INP’yi düşürür.
• Etkileşim sonrası işi azaltın. Bir filtreye tıklandığında tüm sayfayı yeniden çizmek yerine yalnız değişen bölümü güncelleyin.
• Üçüncü taraf kodlarını geciktirin. Reklam ve takip kodlarını sayfa yüklendikten sonra ya da kullanıcı onayından sonra çalıştırmak hem gizlilik hem hız açısından doğrudur.

CLS nasıl iyileştirilir?

CLS, okumaya başladığınız metnin aniden aşağı kaymasıdır. En sık nedenleri ve çözümleri şunlardır:

• Boyutsuz görseller: Her img ve video etiketine width ve height verin ya da CSS’te aspect-ratio tanımlayın. Tarayıcı yeri önceden ayırır.
• Sonradan eklenen bantlar: Çerez bildirimi, kampanya şeridi veya reklam alanı içeriğin üstüne itilerek ekleniyorsa sayfa kayar. Bu alanlar için yer ayırın ya da içeriğin üstüne bindirerek (overlay) gösterin.
• Web fontu değişimi: Yedek font ile asıl font arasındaki boyut farkı satırları kaydırabilir. size-adjust gibi ayarlarla yedek fontu asıl fonta yaklaştırmak bu etkiyi azaltır.
• Gömülü içerik: Harita, video ve sosyal medya gömmelerine sabit yükseklikli bir kutu verin.

Sık yapılan hatalar

1. Yalnız masaüstü skoruna bakmak. Google mobil deneyimi esas alır; mobil skor çoğu zaman çok daha düşüktür.
2. Lighthouse puanını 100 yapmak için gerçek kullanıcı deneyimini görmezden gelmek. Önemli olan saha verisidir.
3. Hız eklentilerini üst üste kurmak. Birbirinin yaptığını tekrar eden eklentiler sorunları çözmek yerine yenilerini yaratır.
4. Tek bir sayfayı düzeltip şablonu unutmak. Core Web Vitals sorunları genellikle şablon kaynaklıdır; bir blog yazısını düzeltmek bütün blog sayfalarını düzeltmez.

Uygulanabilir kontrol listesi

• Search Console’da Core Web Vitals raporunu açın ve “zayıf” URL gruplarını not edin.
• Her grup için bir örnek sayfayı PageSpeed Insights’ta mobil olarak test edin.
• LCP öğesini belirleyin; tembel yükleme varsa kaldırın, boyutunu küçültün.
• Tüm görsellere genişlik ve yükseklik verin.
• Kullanılmayan betikleri ve eklentileri listeleyip kaldırın.
• Değişikliklerden sonra 28 günlük saha verisinin güncellenmesini bekleyin; Search Console’da “Düzeltmeyi doğrula” düğmesini kullanın.

Örnek senaryo: yavaş açılan bir hizmet sayfası

Diyelim ki bir diş kliniğinin “İmplant tedavisi” sayfası mobilde LCP açısından 5 saniyenin üstünde ölçülüyor. Teşhis sırası şöyle ilerler:

1. LCP öğesini bulun. PageSpeed Insights raporunda “Largest Contentful Paint öğesi” satırı genellikle sayfanın üstündeki büyük klinik fotoğrafını gösterir.
2. Fotoğrafın boyutuna bakın. Telefonla çekilmiş 4000 piksel genişliğinde, 3 MB’lık bir JPEG olduğunu görürsünüz. Bu dosyayı 1200 piksel genişliğe indirip WebP’ye çevirmek boyutu çoğu zaman onda birine düşürür.
3. Yükleme özelliklerini kontrol edin. Görselde loading="lazy" varsa kaldırın, fetchpriority="high" ekleyin.
4. Sunucu yanıtını ölçün. TTFB 1 saniyenin üstündeyse sayfa önbelleğini açın ya da barındırma planınızı gözden geçirin.
5. Şablonu düzeltin. Aynı yapı tüm hizmet sayfalarında kullanılıyorsa düzeltmeyi şablonda yapın; böylece bir sayfa yerine onlarca sayfa iyileşir.

Bu tür bir düzeltmeden sonra laboratuvar testinde iyileşme hemen görünür; saha verisinin, yani gerçek kullanıcı ölçümlerinin güncellenmesi ise yaklaşık dört hafta sürer. Bu süre boyunca sayfayı tekrar tekrar değiştirmek yerine sonucu beklemek, hangi değişikliğin işe yaradığını anlamanızı kolaylaştırır.

Sonuç

Core Web Vitals’ı iyileştirmek, sihirli bir eklenti kurmaktan çok sayfanın ne kadar iş yaptığını azaltmakla ilgilidir: daha hızlı sunucu yanıtı, daha küçük görseller, daha az JavaScript ve önceden ayrılmış alanlar. Bu dört ilkeyi şablon düzeyinde uyguladığınızda yalnız puanınız değil, formu dolduran ve satın alan ziyaretçi sayınız da artar.