Core Web Vitals nasıl iyileştirilir? LCP, INP ve CLS rehberi

“Lighthouse puanım iyi ama site telefonda yavaş” cümlesi şaşırtıcı değildir. Laboratuvar testi tek bir koşulu gösterir; gerçek ziyaretçilerin cihazları ve bağlantıları farklıdır. Core Web Vitals, yüklenme, etkileşim ve görsel kararlılığı birlikte okumayı sağlar.

1. Laboratuvar ve gerçek kullanıcı verisini ayırın

PageSpeed Insights ve Search Console, yeterli trafik varsa Chrome gerçek kullanıcı verisini gösterebilir. Lighthouse ise kontrollü bir test koşulu üretir. Saha verisi yoksa sayfa kötü demek değildir; yeterli örnek olmayabilir. Lighthouse bulgularını hata ayıklamada, saha verisini ise kullanıcıların yaşadığı etkiyi anlamada kullanın.

Ana sayfayla yetinmeyin. Ürün, blog, hizmet ve iletişim sayfalarında en büyük öğe ile önemli etkileşimler değişir. Ölçümü mobil ve masaüstünde ayrı yapın, test edilen URL’yi, tarihi ve yapılan değişikliği kaydedin.

  • Aynı URL için saha ve laboratuvar sonuçlarını yan yana kaydedin.

web.dev: Web Vitals ölçümüne başlama ↗

2. LCP: İlk büyük içeriği bekletmeyin

LCP çoğu sayfada büyük bir başlık veya hero görselidir. Önce DevTools ya da Lighthouse’ta LCP öğesini bulun. Görselse doğru boyutta dosya sunun, modern sıkıştırma kullanın ve ilk ekrandaki kritik görseli gereksiz lazy loading ile ertelemeyin. HTML’den keşfedilebilen bir kaynak kullanın; önemli görsel yalnızca geç çalışan JavaScript ile ekleniyorsa yükleme gecikir.

Video arka planı kullanıyorsanız poster görselini ve video dosyasının boyutunu değerlendirin. Video her ziyarette ilk saniyede indirilmek zorunda değilse yükleme stratejisini ayarlayın. Sunucu yanıtı yavaşsa yalnızca görsel sıkıştırmak yeterli olmaz; önbellek ve barındırma da incelenmelidir.

  • LCP öğesini belirleyin; onun indirme ve çizilme zamanını ayrı ölçün.

web.dev: LCP optimizasyonu ↗

3. INP: Tıklama ve yazma gecikmesini azaltın

INP, ziyaretçinin yaptığı etkileşimlere sayfanın ne kadar hızlı görsel yanıt verdiğini ölçer. Menü açılması, filtre seçimi, form yazma ve sepet işlemleri önemlidir. Uzun JavaScript görevleri, yoğun üçüncü taraf scriptleri veya her tuşta çalışan ağır işlemler ana iş parçacığını meşgul eder.

Performans panelinde en yavaş etkileşimi bulun. Gereksiz işlevleri azaltın, büyük hesaplamaları bölün, uygun yerde erteleyin ve kullanıcıya anlık geri bildirim verin. Bir tıklamayı yalnızca animasyonla gizlemek gerçek gecikmeyi çözmez.

  • Menü, filtre ve formu düşük güçlü bir telefonda deneyin.

web.dev: INP, FID’nin yerini aldı ↗

4. CLS: Sayfa yüklenirken yer değiştirmesin

Görsele genişlik ve yükseklik vermek, tarayıcının alanı önceden ayırmasına yardımcı olur. Reklam, çerez kutusu, açılır panel ve sonradan yüklenen yazı tipleri de düzeni değiştirebilir. Özellikle kullanıcı bir düğmeye basacakken düğmenin yer değiştirmesi hem sinir bozucu hem de hataya açıktır.

Geliştirme araçlarının düzen kayması izinde hangi öğelerin sıçradığını bulun. Sabit alan ayırın; sonradan gelen içeriği mevcut satırların üstüne itmek yerine ayrılmış bir bölgeye yerleştirin. Görünüm testini sadece ekran görüntüsüyle değil, sayfa yüklenirken izleyerek yapın.

  • İlk ekranda görsel, yazı tipi ve çerez bildirimi yüklenirken kayma olup olmadığını izleyin.

5. Bir iyileştirme sırası oluşturun

Önce gerçek kullanıcıları etkileyen en sorunlu sayfa türünü seçin. Tek seferde her şeyi değiştirmek yerine ana görseli, sonra kritik scriptleri, ardından düzen kaymalarını ele alın. Her adımda aynı test koşullarıyla ölçün; saha verisinin zaman içinde güncellendiğini unutmayın.

Hız tek başına proje başarısı değildir. Düşük kaliteli içerik, çalışmayan form veya anlaşılmayan teklif akışı hızlı da olsa kullanıcıya fayda sağlamaz. Performansı erişilebilirlik ve iş hedefleriyle birlikte değerlendirin.

  • İlk düzeltmeden önce ve sonra LCP, INP ve CLS ölçümlerini kaydedin.