LCP dökümü ve LCP istek keşfi uyarıları nasıl giderilir?

İki ayrı uyarı, aynı ölçü

PageSpeed raporunda birbirine yakın iki başlık görünüyor: "LCP dökümü" ve "LCP istek keşfi".

İkisi de aynı ölçüyle ilgili: sayfadaki en büyük içerik öğesinin ne kadar sürede göründüğü.

Bu öğe çoğu sitede ilk ekrandaki büyük görsel. Bazen büyük bir başlık metni de olabiliyor. Rapor hangi öğenin ölçüldüğünü açıkça gösteriyor ve ilk bakılacak yer orası.

Ölçünün tanımı ve eşikleri web.dev üzerinde yayımlanıyor; iyileştirme yolları ayrı bir belgede anlatılıyor.

Dört aşama

"LCP dökümü" uyarısının değeri şurada: toplam süreyi dört parçaya ayırıyor ve hangisinin uzun olduğunu gösteriyor.

1. Sunucu yanıtı. Sayfa isteği gönderildikten sonra ilk baytın gelmesine kadar geçen süre.

2. Kaynak keşfi. Tarayıcının ana görseli fark etmesine kadar geçen süre.

3. İndirme. Görselin inmesi.

4. Çizim. Görselin ekrana çizilmesi.

Bu ayrım kritik çünkü her aşamanın çözümü farklı. Sunucu yanıtı uzunken görsel optimize etmek toplam süreyi eşiğin altına indirmiyor.

İpucu — Rapordaki döküm çubuğuna bakın: en uzun parça hangisiyse çalışma orada. Fırsatlar listesinin en üstündeki madde, o parçayla ilgili olmayabiliyor.

Kaynak keşfi — en sık sorun

"LCP istek keşfi" uyarısı özellikle bu ikinci aşamayla ilgili ve sahada en sık gördüğümüz sorun burada.

Tarayıcı, HTML'i okurken görselleri fark ediyor ve indirmeye başlıyor. Üç durumda bu keşif gecikiyor:

Görsele tembel yükleme uygulanmış. En yaygın sebep. Tembel yükleme keşfi bilerek geciktiriyor; ilk ekrandaki görsel için bu doğrudan zarar. Ayrıntısını tembel yükleme yazısında anlattık.

Görsel arka plan olarak yükleniyor. Stil dosyasından geliyorsa tarayıcı önce stil dosyasını indirmek zorunda. İki adımlı gecikme.

Görsel JavaScript ile ekleniyor. Tarayıcı HTML'i okuduğunda görsel henüz orada değil; betik çalışana kadar keşfedilmiyor.

Üçünün de çözümü aynı yöne bakıyor: görselin HTML'de, doğrudan ve erkenden bulunması.

Öncelikli yükleme

Keşif sorunu çözüldükten sonra bir adım daha var: tarayıcıya bu görselin önemli olduğunu söylemek.

Varsayılan davranışta tarayıcı bütün görselleri eşit önemde sayıyor ve sırayla indiriyor. Ana görsel sıranın sonundaysa geç geliyor.

Öncelik işareti eklendiğinde o görsel diğerlerinden önce iniyor. Tek satırlık bir değişiklik ve çoğu sitede ölçüyü belirgin şekilde iyileştiriyor.

Aynı işareti birden çok görsele vermek işe yaramıyor: her şey öncelikliyse hiçbir şey öncelikli değil. Yalnızca LCP öğesine verilmeli.

Dikkat — Öncelik işaretini vermeden önce rapordan LCP öğesinin hangisi olduğunu doğrulayın. Yanlış görsele öncelik vermek, doğru görselin daha da geç gelmesine yol açıyor.

Sunucu yanıtı uzunsa

Bu, diğer üç aşamayı anlamsız kılan durum. PageSpeed raporunda ayrı bir başlıkla da görünüyor: "Doküman isteğiyle ilgili gecikme", eski sürümlerde "İlk sunucu yanıt süresi". Ölçtüğü şey tarayıcının sayfa isteğini göndermesiyle sunucudan ilk baytın gelmesi arasındaki süre; tanımı ve eşikleri web.dev üzerinde yayımlanıyor.

Sunucu ilk yanıtı 1,5 saniyede veriyorsa LCP en iyi ihtimalle 1,5 saniyeden başlıyor. Görseli ne kadar küçültürseniz küçültün, betikleri ne kadar erteleseniz de bu süre değişmiyor; tarayıcı tarafındaki her iş bu süre dolduktan sonra devreye giriyor. Belirtisi dökümde ilk parçanın diğer üçünün toplamından büyük olması.

Süre nerede geçiyor?

İlk bayt gelene kadar dört şey oluyor: istek sunucuya gidiyor (sunucu coğrafi olarak uzaktaysa bu süre uzuyor), sunucu sayfayı hesaplıyor (veritabanı sorgulanıyor, şablon işleniyor), varsa yönlendirmeler her biri yeni bir tur ekliyor ve yanıt tarayıcıya dönüyor. İkinci kalem çoğu sitede en uzun olan ve düzeltilmesi en mümkün olan.

Önbelleklenmeyen sayfa. Dinamik bir site her istekte sayfayı yeniden hesaplıyor; oysa içerik aynı. Sayfa önbelleği bu işi bir kez yapıp sonucu saklıyor.

Barındırma. Paylaşımlı barındırmada komşu sitelerdeki yoğunluk sizin yanıt sürenizi etkiliyor. Belirtisi net: site normal saatlerde hızlı, yoğun saatlerde çok yavaş. Bu durumda kod tarafındaki optimizasyonun sınırı var.

Yönlendirme zincirleri. Her yönlendirme ayrı bir istek turu; iki adımlık bir zincir süreyi iki kat artırabiliyor. www ve HTTPS yönlendirmeleri de bu kapsamda — www'suz adresten www'luya, oradan HTTPS'e giden üç tur tek kuralla tek adıma iniyor.

Coğrafi mesafe. Sunucu Türkiye'deki kullanıcılara uzaksa her istek o mesafeyi kat ediyor; içerik dağıtım ağı statik dosyalarda doğrudan, HTML'de sayfa önbelleklenebilirse çalışıyor.

Düzeltme sırası

1. Yönlendirme zincirlerini temizleyin. En ucuz ve en hızlı kazanç.
2. Sayfa önbelleği kurun. Dinamik sitelerde en büyük tek kazanç.
3. Veritabanı sorgularını ölçün. Yavaş tek bir sorgu süreyi ikiye katlayabiliyor.
4. Barındırmayı değerlendirin. İlk üç adım yetmiyorsa altyapı sınırında demektir.
5. İçerik dağıtım ağı ekleyin. Coğrafi mesafe belirleyiciyse.

Önbellek kurulu olduğu hâlde süre düşmüyorsa sebep genellikle aynı: oturum açmış kullanıcı için önbellek atlanıyor (yönetici olarak test ediyorsanız gerçek durumu görmüyorsunuz), sepet ya da karşılama mesajı gibi kişiye özel içerik önbelleği engelliyor ya da takip parametresi taşıyan adresler ayrı sayfa sayılıyor. Kontrol için gizli sekmede ölçün. Ölçümü de tek seferde bırakmayın: aynı sayfayı sabah, öğlen ve akşam ölçün. Fark küçükse sorun sabit bir yapısal gecikme, büyükse kapasite ve barındırma tarafında; bu ayrım barındırma değiştirme kararı için en somut kanıt.

LCP öğesi metin olduğunda

Görselin olmadığı ya da küçük olduğu sayfalarda LCP öğesi büyük bir başlık metni olabiliyor.

Bu durumda sorun genellikle yazı tipinde: yazı tipi dosyası inene kadar metin hiç görünmüyorsa, ölçü o beklemeyi de sayıyor.

Çözüm, yazı tipi gelene kadar yedek bir yazı tipiyle metnin gösterilmesi. Ayrıntısını yazı tipi görüntüleme yazısında anlattık.

Örnek senaryo — LCP'si 4,1 saniye olan bir site düşünün. Fırsatlar listesinin en üstünde "kullanılmayan JavaScript" yazıyor. Ekip günlerce betik temizliğiyle uğraşıyor, ölçü ancak biraz kıpırdıyor. Sonra döküme bakılıyor: sürenin 2,6 saniyesi kaynak keşfinde geçiyor. Sebep tek — ana görsele tembel yükleme uygulanmış. O tek satır kaldırıldığında LCP genellikle betik temizliğinin hiç getirmediği kadar düşer.

Sıralı kontrol

LCP sorununu çözmenin sırası şu ve atlanmamalı:

1. Rapordan LCP öğesini bulun. Hangi görsel ya da metin ölçülüyor?
2. Dökümden en uzun aşamayı bulun. Çalışma orada.
3. Sunucu yanıtı uzunsa önce onu düzeltin. Diğerleri onun üstüne biniyor.
4. Keşif uzunsa tembel yüklemeyi kaldırın ve öncelik verin.
5. İndirme uzunsa görseli küçültün ve modern biçime çevirin.
6. Çizim uzunsa engelleyen dosyaları azaltın.
7. Dört hafta bekleyip saha verisine bakın.

Görsel tarafındaki işleri resim yayınlama yazısında, engelleyen dosyaları oluşturma engelleme yazısında ele aldık.

Mobil ve masaüstünde farklı öğe

Sık atlanan bir ayrıntı: LCP öğesi mobil ve masaüstünde farklı olabiliyor.

Masaüstünde geniş bir kapak görseli ölçülürken, mobilde o görsel gizlenmiş ve ölçülen şey bir başlık metni olabiliyor.

Bu yüzden iki raporu ayrı okumak gerekiyor. Mobilde yapılan düzeltme masaüstünü etkilemeyebiliyor ve tersi.

Önemsenmesi gereken taraf mobil; gerekçesini mobil öncelikli indeksleme yazısında anlattık.

Ne zaman yeterli?

Hedef ölçüyü sıfırlamak değil, eşiğin altına indirmek.

Eşik geçildiğinde daha da iyileştirmenin sıralama tarafında ek bir karşılığı olmuyor. Kullanıcı deneyimi açısından değeri var ama emek başına getirisi hızla düşüyor.

Bu yüzden LCP çalışmasında durma noktası, saha verisinde ölçünün yeşile dönmesi. Sonrasında emek başka bir yere kaymalı.

Ölçünün gerçek kullanıcıdaki karşılığı

Laboratuvar ölçümü tek bir simülasyon; saha verisi ise 28 günlük gerçek kullanıcı ortalaması.

İkisi arasında büyük fark olabiliyor. Laboratuvarda 2,1 saniye çıkan bir sayfa, saha verisinde 4,3 saniye görünebiliyor.

Sebebi kullanıcı çeşitliliği: yavaş cihazlar, zayıf bağlantılar, uzak konumlar. Simülasyon bir ortalama varsayıyor, gerçek kullanıcılar dağılıyor.

Karar her zaman saha verisine göre verilmeli. Laboratuvar ölçümü yalnızca sebebi bulmak için.

Sayfa tipine göre değişiyor

LCP tek bir sayı değil; her sayfa tipinde farklı olabiliyor.

Ana sayfa büyük bir kapak görseliyle geliyor, blog yazısı metinle başlıyor, ürün sayfası galeriyle. Üçünün LCP öğesi ve sorunu farklı.

Bu yüzden ölçüm tek sayfada değil, sayfa tiplerinde yapılmalı: ana sayfa, bir kategori, bir ürün, bir blog yazısı.

Search Console'un raporu bunu sayfa grupları hâlinde gösteriyor ve hangi şablonun sorunlu olduğunu doğrudan söylüyor.

Sonuç — LCP tek bir sayı ama dört ayrı sebepten uzayabiliyor. Dökümü okumadan yapılan düzeltme, çoğu zaman yanlış aşamaya harcanan emek oluyor.

Ölçüm ve düzeltmenin tamamını teknik SEO kapsamında yürütüyoruz; sitenizin bugünkü durumu SEO denetimi ve analiz çalışmasında çıkarılıyor. Yeni bir sitede bu yapı baştan doğru kuruluyor — web sitesi geliştirme.

Rapordaki diğer uyarılar için PageSpeed uyarıları yazısına bakabilirsiniz.