LCP öğesini belirleme
Lighthouse teşhisinde en büyük içerik öğesini açın ve öğenin metin mi, görsel mi olduğunu doğrulayın. Responsive kırılımlarda LCP öğesi değişebilir; mobilde hero görseli, masaüstünde başlık veya farklı banner ölçülebilir. Şablondaki birkaç URL test edilmelidir.
TTFB ve belge yanıtı
HTML belgesi geç geliyorsa tarayıcı kritik kaynakları keşfedemez. Sunucu işlem süresi, yönlendirme zinciri, CDN, önbellek ve coğrafi gecikme incelenir. LCP öğesine preload eklemek yavaş başlangıç belgesini tek başına telafi etmez.
Kaynak keşif gecikmesi
LCP görseli ilk HTML’de bulunmalı ve lazy-load uygulanmamalıdır. CSS arka planı veya JavaScript ile sonradan eklenen görsel geç keşfedilebilir. Uygun preload veya fetchpriority yalnız gerçekten kritik tekil kaynak için düşünülür; aşırı öncelik bant genişliği rekabeti yaratır.
İndirme ve render gecikmesi
Doğru boyutta AVIF/WebP görsel, responsive kaynaklar ve uzun önbellek indirme süresini azaltabilir. Kaynak erken inse bile render engelleyici CSS, font veya ana iş parçacığı görevi öğenin çizilmesini geciktirebilir. Performance kaydıyla ağ bitişi ve ekrana çizim arasındaki boşluk incelenir.
Düzeltmeyi doğrulama
Aynı koşullarda birkaç laboratuvar testi çalıştırın ve bileşenlerdeki değişimi karşılaştırın. Ardından gerçek kullanıcı LCP verisinin yenilenmesini izleyin. Yalnız ana sayfayı değil aynı şablon ve bileşeni kullanan URL grubunu kontrol edin.
İlgili rehberler
Sık sorulan sorular
İyi LCP değeri nedir?
Core Web Vitals değerlendirmesinde 75. yüzdelikte 2,5 saniye veya daha iyi değer iyi aralık olarak kullanılır.
LCP her zaman görsel midir?
Hayır; büyük bir metin bloğu veya başka uygun içerik öğesi LCP olabilir.
LCP görseli lazy-load edilmeli mi?
İlk ekrandaki LCP görseli genellikle lazy-load edilmemeli ve erken keşfedilmelidir.
Preload her LCP sorununu çözer mi?
Hayır; TTFB, dosya boyutu ve render gecikmesi gibi bileşenler ayrıca düzeltilmelidir.