Core Web Vitals: LCP, INP ve CLS’i sade anlatım ile

Google, sayfa deneyimini üç ölçümle değerlendiriyor: LCP, INP ve CLS. Bunlara topluca Core Web Vitals deniyor ve hem arama sıralamasında hem Google Ads kalite puanında rol oynuyorlar.

Bu yazıda üç ölçümü teknik jargona boğmadan açıklıyor, her biri için pratikte işe yarayan çözümleri sıralıyoruz.

LCP — En büyük içeriğin görünme süresi

Ne ölçer: Ziyaretçi sayfayı açtığında, ekrandaki en büyük görsel ya da metin bloğunun görünür hâle gelmesi ne kadar sürüyor?

Hedef: 2,5 saniyenin altı. 4 saniyenin üstü “kötü” kabul edilir.

Neden önemli: Bu, ziyaretçinin “sayfa açıldı” hissettiği andır. Bu süre uzadıkça terk oranı hızla artar.

Pratikte ne yapılır:

• Sunucu yanıt süresini düşürün. LCP’nin ilk parçası TTFB’dir. Sunucu 800 ms’de yanıt veriyorsa, LCP’yi 2,5 saniyenin altına indirmek için geriye çok az alan kalır.
• Hero görselini optimize edin. Çoğu sayfada LCP öğesi üstteki büyük görseldir. Bu görseli WebP ya da AVIF formatında, ekran boyutuna uygun ölçüde sunun.
• Hero görselini tembel yüklemeyin. Yaygın bir hata: tüm görsellere loading="lazy" eklemek. Ekranın üst kısmındaki görsel tembel yüklendiğinde LCP belirgin biçimde kötüleşir.
• Kritik CSS’i satır içine alın. Tarayıcının sayfayı çizmeye başlayabilmesi için CSS’i beklemesi gerekir. İlk ekranın CSS’ini satır içine alıp gerisini ertelemek işe yarar.
• Yazı tiplerini önceden yükleyin. Metin LCP öğesiyse, yazı tipi dosyası gelene kadar metin görünmeyebilir. preload ve font-display: swap kullanın.

INP — Etkileşime yanıt gecikmesi

Ne ölçer: Ziyaretçi bir düğmeye tıkladığında ya da bir menüyü açtığında, ekranda görsel bir tepki oluşması ne kadar sürüyor?

Hedef: 200 milisaniyenin altı. 500 ms üstü “kötü”.

Neden önemli: Bu, sitenin “takılıyor” hissi verip vermediğini belirler. Özellikle mobilde, işlemci gücü sınırlı olduğu için belirgin biçimde hissedilir.

Pratikte ne yapılır:

• JavaScript miktarını azaltın. INP’nin baş sorumlusu, ana iş parçacığını meşgul eden betiklerdir. Kullanılmayan eklentilerin JS dosyalarını kaldırın.
• Üçüncü taraf betiklerini erteleyin. Canlı destek, ısı haritası, sosyal medya butonları — bunların sayfa açılırken yüklenmesi gerekmez. Kullanıcı etkileşiminden sonra yükleyin.
• Ağır işleri parçalayın. Uzun süren bir JS işlemi ana iş parçacığını kilitler; o sırada tıklamalar yanıtsız kalır.
• jQuery bağımlılığını gözden geçirin. Eski temalar ve eklentiler hâlâ jQuery yükler. Modern tarayıcılarda çoğu işlem saf JavaScript ile çok daha hafif yapılabilir.

CLS — Sayfa yerleşiminin kayması

Ne ölçer: Sayfa yüklenirken içerik ne kadar oynuyor? Okumaya başladığınız metnin aşağı kayması ya da tam tıklayacakken düğmenin yer değiştirmesi bu ölçüme girer.

Hedef: 0,1’in altı. 0,25 üstü “kötü”.

Neden önemli: Yanlış tıklamaya yol açar. E-ticarette bu, yanlış ürünün sepete eklenmesi ya da istenmeyen bir sayfaya gidilmesi demektir — doğrudan dönüşüm kaybıdır.

Pratikte ne yapılır:

• Görsellere boyut verin. Her <img> etiketine width ve height ekleyin. Tarayıcı yeri baştan ayırır, görsel gelince kayma olmaz.
• Reklam ve gömülü içerik için yer ayırın. Dışarıdan yüklenen her bloğun (reklam, harita, video) yüksekliğini CSS ile önceden tanımlayın.
• Çerez bildirimini sayfanın üstüne itmeyin. Sayfanın üzerine binen (overlay) bir bildirim CLS üretmez; içeriği aşağı iten bir bildirim üretir.
• Yazı tipi değişimini yumuşatın. Yedek yazı tipi ile asıl yazı tipinin metrikleri farklıysa, yazı tipi yüklendiğinde metin yeniden akar. size-adjust ve benzeri özelliklerle bu fark azaltılabilir.

Laboratuvar verisi ile saha verisini karıştırmayın

PageSpeed Insights iki tür veri gösterir ve bu ayrım çoğu zaman gözden kaçar:

• Saha verisi (CrUX): Gerçek ziyaretçilerinizin son 28 günde yaşadığı deneyim. Google sıralamada bunu kullanır.
• Laboratuvar verisi (Lighthouse): Standart bir sanal cihazda o an yapılan tek bir ölçüm. Sıralamada kullanılmaz.

Laboratuvar puanınız 95 olabilir ama saha veriniz kötüyse, sıralamada bunun karşılığını alamazsınız. Tersi de geçerlidir. Bu yüzden puanı değil, saha verisindeki üç ölçümü takip edin.

Nereden başlamalı

Deneyimimize göre sıra şu olmalı: önce sunucu yanıt süresi, sonra görsel optimizasyonu, sonra JavaScript. Sunucu yavaşken diğer iyileştirmelerin etkisi sınırlı kalır — temeli düzeltmeden üst katmanla uğraşmak, zaman kaybıdır.