LCP nasıl düşürülür.
LCP, bir sayfanın görünür alandaki en büyük içerik öğesinin boyanma süresidir ve Google 2,5 saniyenin altını iyi sayar.
Metrik, kullanıcının «sayfa geldi» dediği anı yakalamaya çalışıyor. Bir sayfanın ilk pikselinin ne zaman boyandığı değil, ASIL içeriğinin ne zaman göründüğü ölçülüyor — çünkü kullanıcı için sayfanın gelmesi, okuyacağı şeyin gelmesi demek.
Ölçülen öğe genelde ya bir görsel ya da bir metin bloğudur. Hangi öğenin LCP öğesi olduğu sayfaya göre değişir ve ilk yapılacak iş onu bulmaktır — tarayıcı geliştirici araçları performans panelinde bu öğeyi doğrudan işaretler. Yanlış öğeyi optimize etmek, en sık yapılan ve en çok zaman kaybettiren hatadır.
LCP dört parçadan oluşur
Süreyi düşürmek için önce nereye gittiğini bilmek gerekiyor. Google'ın kendi kırılımı dört aşama tanımlar ve her aşamanın ayrı bir tedavisi vardır.
- İlk bayt süresi — sunucu ilk yanıtı ne kadar sürede gönderdi? Barındırma, önbellek ve sunucu işi.
- Kaynak yükleme gecikmesi — tarayıcı LCP kaynağını keşfedip istemeye ne zaman başladı? Keşif sorunu.
- Kaynak yükleme süresi — kaynağın kendisi ne kadar sürede indi? Boyut ve format sorunu.
- Öğe render gecikmesi — kaynak geldikten sonra boyanmaya ne kadar süre kaldı? Render engelleyici sorunu.
Bu kırılım tanıyı hızlandırıyor. Süre birinci aşamada birikiyorsa sunucu tarafına bakılır; ikincide birikiyorsa keşif zincirine; üçüncüde boyuta; dördüncüde render engelleyen kaynaklara. Dördü için yapılacak işler tamamen farklıdır ve karıştırılması boşa emek demektir.
Keşif gecikmesi: en çok gözden kaçan
İkinci aşama pratikte en sık suçlu ve en az bilinen. Sorun şu: tarayıcı LCP görselini ancak onu keşfettiğinde istemeye başlar, ve keşif zinciri uzunsa geç başlar. Bir görsel CSS'in içinde arka plan olarak tanımlıysa, tarayıcının önce HTML'i, sonra CSS'i indirip ayrıştırması gerekir — ancak ondan sonra görselin varlığından haberi olur.
Aynı sorun JavaScript ile eklenen görsellerde daha da beter: kaynak, script indirilip çalıştırılana kadar hiç bilinmez. Karusel ve slider bileşenleri bu yüzden LCP açısından zayıftır — ilk kare genelde script tarafından yerleştirilir.
Çözüm, LCP kaynağının sunucudan gelen HTML'de doğrudan görünmesidir. Bir görsel etiketi olarak, arka plan olarak değil. Böylece tarayıcının ön tarayıcısı onu HTML ayrıştırılırken keşfeder ve hemen istemeye başlar.
Keşfi hızlandıran ikinci araç önceden yükleme bildirimidir: tarayıcıya «bu kaynağı öncelikli olarak indir» denebilir. Ama bu araç dikkatli kullanılmalı — her şeye öncelik vermek, hiçbir şeye öncelik vermemekle aynı sonucu verir ve gerçek LCP kaynağını yavaşlatabilir.
Yükleme süresi: boyut ve format
Üçüncü aşama en somut olanı ve genelde en büyük kazancın çıktığı yer. Bir hero görselinin boyutu, LCP'yi doğrudan belirliyor ve çoğu sitede o görsel gereğinden çok büyük geliyor.
- Modern format kullan — AVIF ve WebP, aynı görsel kaliteyi belirgin biçimde küçük dosyada verir.
- Duyarlı boyut ver — telefona masaüstü görseli göndermek, en yaygın israftır.
- Gerçek boyutta üret — ekranda 800 piksel görünen bir görselin 3000 piksel gelmesinin sebebi yoktur.
- Sıkıştırmayı ölç — kalite ayarını göz kararıyla değil karşılaştırarak seç.
- LCP görselini tembel yükleme — bu, en sık yapılan ters etkili optimizasyondur.
Son madde özellikle önemli. Tembel yükleme, görünür alanın DIŞINDAKİ görseller için bir kazançtır; LCP öğesi tanımı gereği görünür alandadır ve tembel yüklendiğinde keşfi geciktirilmiş olur. Bir sitede tüm görsellere toplu tembel yükleme uygulamak, LCP'yi doğrudan kötüleştirir.
Render gecikmesi: engelleyen kaynaklar
Dördüncü aşama, kaynak geldiği hâlde boyamanın beklemesidir. Sebebi neredeyse her zaman aynıdır: tarayıcı, stil dosyalarını indirip ayrıştırmadan hiçbir şey boyamaz. Her ek stil dosyası bir ek istek ve bir ek bekleme demektir.
Bu sitede tam olarak bu ölçüldü ve kapatıldı. Lighthouse mobil koşumunda iki ayrı stil dosyası render'ı bloke ediyordu: biri 821 milisaniye, diğeri 221 milisaniye. İki dosya tek dosyada birleştirildi ve yorumlar sıyrıldı — kaynak 67,4 kilobayt, gzip sonrası 12,4 kilobayt. Render'ı bloke eden dosyada ölçülen kazanç 11,4 kilobayttı.
Sıyırma bilerek muhafazakâr tutuldu: yalnız yorumlar, satır başı girintileri ve boş satırlar. Seçicinin ya da değerin içine hiç dokunulmadı, çünkü agresif sıyırma yalnız 747 bayt daha kazandırıyordu ve torun-pseudo desenlerini bozma riski taşıyordu. Kazanç ile risk ölçülüp karşılaştırıldı.
747 bayt için bir seçiciyi bozma riski alınmaz — kazanç ölçülür, risk de ölçülür.
Son bir hatırlatma: LCP tek bir sayı değil, bir dağılımdır. Saha verisinde bakılan değer 75. yüzdeliktir — yani kullanıcıların dörtte üçünün yaşadığı süre. Kendi cihazınızda ölçtüğünüz süre, o dağılımın en iyi ucundan bir örnektir ve tek başına hüküm vermeye yetmez.
Yaygın yanlış optimizasyonlar
LCP düşürme çabasının bir kısmı tersine çalışır ve bunlar iyi bilinen kalıplar oldukları için özellikle sinsidir. En yaygını, tüm görsellere toplu tembel yükleme uygulamaktır: görünür alan dışındaki görseller için doğru olan bu ayar, LCP öğesine uygulandığında keşfi geciktirir ve süreyi doğrudan artırır.
İkincisi, her şeye önceden yükleme bildirimi koymaktır. Bu bildirimin işi bir kaynağı öne almaktır; on kaynağa birden konduğunda hiçbiri öne alınmamış olur, üstelik gerçek LCP kaynağı bant genişliği için diğerleriyle yarışmaya başlar. Bir sayfada önceden yüklenecek kaynak sayısı genelde bir ya da ikidir.
Üçüncüsü, yazı tipi yüklemesini bloke edici hâle getirmektir. Metin bir LCP öğesi olabilir ve yazı tipi gelene kadar hiç boyanmazsa süre doğrudan uzar. Doğru davranış, yedek yazı tipiyle hemen boyamak ve gerçek yazı tipi geldiğinde değiştirmektir — ama o değişimin düzen kayması üretmemesi için yedek ailenin metrik olarak eşleşmesi gerekir.
Dördüncüsü, üçüncü taraf betiklerini görmezden gelmektir. Analitik, sohbet balonu ve reklam betikleri genelde LCP öğesinden sonra yüklenir gibi görünür ama bant genişliğini ve ana iş parçacığını paylaşırlar. Bir sohbet balonunu geciktirmek, çoğu sitede stil dosyası sıyırmaktan daha çok kazandırır.