Geç yükleme, Largest Contentful Paint’inizi gerçekte nasıl etkiler

Geç yükleme bir zamanlama kararıdır, hız büyüsü değil

Geç yükleme genellikle bir performans iyileştirmesi olarak tanımlanır; bu, bavul hazırlamamanın ağırlık azaltımı sayılması kadar doğrudur. Yardımcı olur çünkü tarayıcı başlangıçta daha az iş yapar.

Bu ayrım, genellikle LCP olarak kısaltılan Largest Contentful Paint için önemlidir. LCP, görünüm alanındaki en büyük anlamlı öğenin ne zaman işlendiğini ölçer. Birçok sayfada bu öğe bir hero görselidir. Bazılarında ise büyük bir başlık, poster görseli, ürün fotoğrafı veya içerik bloğudur.

Geç yükleme, kaynakların ne zaman istendiğini değiştirir. Bir görselin daha hızlı çözülmesini, bir sunucunun daha hızlı yanıt vermesini veya bir fontun daha erken işlenmesini sağlamaz. Yanlış şeyi, özellikle de LCP olacak öğeyi geç yüklerseniz, tarayıcıya Core Web Vitals’ı geçmek için göstermesi gereken asıl şeyi getirmeden önce beklemesini söylemiş olursunuz.

Bu yüzden geç yükleme hem gereğinden fazla kullanılır hem de yeterince anlaşılmaz.

Bir görseli geç yüklediğinizde tarayıcı ne yapar

Yerel görsel geç yükleme genellikle şöyle eklenir:

<img src='hero.jpg' loading='lazy' alt='...'>

loading='lazy' ile tarayıcı, görselin gerekli olacağını düşündüğü ana kadar görseli getirmeyi erteleyebilir. Pratikte tarayıcılar görünüm alanına uzaklık, ağ koşulları, görsel boyutları ve başka sezgisel kurallar kullanır. Kesin kurallar uygulama ayrıntılarıdır ve değişebilir.

loading='eager' ile veya çoğu durumda lazy özniteliği olmadan, tarayıcı görseli normal yükleme sürecinin bir parçası olarak ele alır. Yine de CSS, JavaScript, fontlar, görseller ve diğer istekler arasında önceliklendirme yapması gerekir; ancak görsel hemen keşfedilebilir durumdadır.

Bu, geç yüklemenin temel olarak üç aşamayı etkilediği anlamına gelir:

• Keşif: tarayıcının kaynağı fark ettiği an.
• İstek başlangıcı: ağ üzerinden getirme işleminin başladığı an.
• İşleme zamanlaması: kaynağın sonunda çözümlenip boyanabildiği an.

LCP için tehlikeli olan istek başlangıcıdır. LCP görsel isteği geç başlarsa, ondan sonraki her şey de geçe kayar.

Basit kural: LCP adayı öğeyi asla geç yüklemeyin

Bir görsel ilk görünüm alanında görünüyorsa ve en büyük içerikli öğe olma olasılığı yüksekse, onu geç yüklemeyin.

Buna şunlar dahildir:

• hero görselleri
• ilk görünüm alanındaki birincil ürün fotoğrafları
• büyük makale giriş görselleri
• <img> olarak uygulanmış büyük arka plan benzeri görseller
• poster ana görsel öğe olduğunda video poster görselleri

Tarayıcı, LCP görselini istenmeden, aktarılmadan, çözümlenmeden ve boyanmadan işleyemez. Geç yükleme, ilk adımın önüne belirsizlik ekler. Küçük bir gecikme bile daha yavaş bir bağlantıda LCP’yi kabul edilebilir düzeyden kötüye çekmeye yetebilir.

Yaygın bir hata kalıbı şöyle görünür:

1. Sunucu HTML gönderir.
2. Tarayıcı ilk görünüm alanındaki bir görseli ayrıştırır.
3. Görselde loading='lazy' vardır.
4. Geç yükleme sezgisel kuralı bekleyebileceğini söylediği için tarayıcı bekler.
5. CSS ve JavaScript yüklenmeye devam eder.
6. Görsel isteği olması gerekenden daha geç başlar.
7. Görsel dosyanın kendisi makul ölçüde optimize edilmiş olsa bile LCP geç kalır.

Bu sinir bozucudur çünkü sayfa kod incelemesinde düzenli görünebilir. Sorun yalnızca dosya boyutu değildir. Sorun önceliktir.

Laboratuvar çıktısını okuyup LCP’nin gerçekten sorun olup olmadığını anlamaya çalışıyorsanız, Lighthouse raporunu paniklemeden okumaya yönelik rehberimiz özellikle pratiktir: kod değiştirmeye başlamadan önce saha verisini, laboratuvar ipuçlarını ve düzeltmeleri ayırın. (Not: yönlendirme sisteminiz büyük/küçük harfe duyarlıysa CMS’inizdeki tam URL’yi kullanın.)

Düzeltme: gerçek dahili URL’yi kullanın

Doğru Wux makale URL’si Lighthouse raporunu paniklemeden nasıl okursunuz. Ana fikir değişmiyor: yükleme davranışını değiştirmeden önce LCP öğesini belirleyin.

Geç yükleme LCP’yi ne zaman iyileştirebilir

Geç yükleme, kritik olmayan kaynakları tarayıcının yolundan uzak tutarak LCP’yi dolaylı olarak iyileştirebilir.

Üstte bir hero ürün görseli ve ilk görünüm alanının altında on iki öneri görselinden oluşan bir carousel bulunan bir ürün sayfası düşünün. On üç görselin tamamı eager yüklenirse, tarayıcı kullanıcının henüz göremediği görseller için bant genişliği ve bağlantı yuvaları harcayabilir. Kısıtlı bir ağda bu, hero görseliyle, CSS ile veya font dosyalarıyla rekabet edebilir.

İlk görünüm alanının altındaki carousel görsellerini geç yüklemek, ilk sayfa yüklemesi sırasında daha az kritik olmayan istek rekabet ettiği için LCP görselinin daha erken yüklenmesine yardımcı olabilir.

Geç yükleme için meşru performans kullanım durumu budur:

• ilk görünüm alanındaki LCP adayını eager yükleyin
• ilk görünüm alanının altındaki görselleri geç yükleyin
• önemli görselleri geç enjekte eden ağır scriptlerden kaçının
• layout shift’i önlemek için görsel boyutlarını HTML içinde tutun

Geç yükleme tek başına bir LCP optimizasyonu değildir. Bir kaynak önceliklendirme aracıdır. Kritik yolu koruduğunda yardımcı olur.

LCP görselleri için daha iyi kalıp

İlk görünüm alanındaki bir LCP görseli için amaç, tarayıcının onu erken keşfetmesini, erken istemesini ve layout kararsızlığı olmadan işlemesini sağlamaktır.

Sağlam bir başlangıç noktası şöyle görünür:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Önemli kısımlar süs değildir:

• loading='eager' geç yükleme gecikmesini önler.
• fetchpriority='high' tarayıcıya bu görselin önemli olduğunu söyler.
• width ve height alan ayırır ve layout shift’i azaltır.
• srcset ve sizes gereğinden büyük indirmeleri önler.
• Modern bir format, dikkatli kullanıldığında aktarım süresini azaltabilir.

Hâlâ her ekrana tek bir büyük JPEG sunuyorsanız, görsel formatı ve duyarlı boyutlandırma lazy-loading özniteliğinden daha önemli olabilir. Pratik bir karar ağacı için AVIF’in WebP’yi ne zaman geçtiğine ve ne zaman geçmediğine bakın.

Arka plan görselleri ekstra dikkat ister

CSS arka plan görselleri, normal HTML görselleri kadar erken keşfedilmez. Tarayıcının onları bilmesi için önce CSS’i getirip ayrıştırması gerekir. LCP öğeniz bir CSS arka plan görseliyse, keşfi zaten zorlaştırmışsınız demektir.

Bu, arka plan görsellerinin yasak olduğu anlamına gelmez. Bilinçli olmanız gerektiği anlamına gelir.

Dekoratif görseller için CSS arka planları uygundur. Anlamlı hero görselleri için bir <img> veya <picture> öğesi genellikle daha iyidir; çünkü HTML ayrıştırıcısı tarafından görülebilir, alt metni destekler ve duyarlı görsel öznitelikleriyle iyi çalışır.

LCP görseli için mutlaka CSS arka plan kullanmanız gerekiyorsa, onu preload etmeyi düşünün:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload da sihirli değnek değildir. Çok fazla görseli preload etmek, aynı öncelik sorununu farklı bir kostümle yaratır. Bunu tasarım sistemindeki her görsel için değil, gerçekten önemli olan tek görsel için kullanın.

JavaScript ile geç yükleme çoğu zaman işleri kötüleştirir

Yerel geç yükleme yaygın biçimde desteklenmeden önce, birçok site sayfa yüklemesinden sonra veya bir intersection observer tetiklendikten sonra data-src değerini src içine taşıyan JavaScript kütüphaneleri kullanıyordu. Bazıları hâlâ kullanıyor.

Bu, uzun makale sayfaları veya görsel ağırlıklı galeriler için makul olabilir. İlk görünüm alanındaki içerik için kötü bir tercihtir.

Tarayıcının preload tarayıcısı hızlıdır, ancak URL’si özel bir öznitelikte gizlenmiş bir görseli JavaScript çalışana kadar isteyemez. Hero görseliniz data-src='hero.jpg' olarak başlıyorsa, keşfi script indirme, ayrıştırma, yürütme ve framework hydration işlemlerinin arkasına ertelemiş olursunuz.

Bu, LCP için kötü bir takastır. Kritik görsel URL’lerini gerçek HTML içine koyun. Tarayıcının işini yapmasına izin verin.

LCP her zaman bir görsel sorunu değildir

Bazı sayfalarda LCP öğesi metindir. Bu durumda görselleri geç yüklemenin doğrudan etkisi az olabilir. Darboğazınız render-blocking CSS, yavaş sunucu yanıtı, istemci tarafı rendering veya web fontları olabilir.

Fontlar özellikle anılmayı hak eder; çünkü geç metin işlenmesinin sık görülen gizli nedenlerindendir. Büyük bir başlık LCP olabilir ve font yükleme davranışı bu başlığın ne zaman boyandığını geciktirebilir veya değiştirebilir. Görsel tarafındaki çalışmalarınız metriği değiştirmiyorsa, varsayım yapmak yerine LCP öğesini doğrudan inceleyin. Performans kazanımı olarak web fontları hakkındaki makalemiz genellikle işe yarayan sıkıcı düzeltmeleri ele alır: daha az ağırlık, modern formatlar, makul fallback’ler.

Kendinizi kandırmadan geç yükleme değişikliklerini nasıl test edersiniz

Ofis Wi-Fi’ında sayfanıza bakarak test etmeyin. İstek zamanlamasını görmeniz gerekir.

Şu iş akışını kullanın:

1. Chrome DevTools’u açın ve bir Performance izi kaydedin.
2. Fast 4G veya Slow 4G gibi ağ kısıtlamasını etkinleştirin.
3. Önbellek devre dışıyken sayfayı yeniden yükleyin.
4. LCP işaretçisini bulun.
5. LCP öğesini belirleyin.
6. Network panelinde bu kaynağın ne zaman yüklenmeye başladığını kontrol edin.

LCP kaynağı geç başlıyorsa nedenini sorun:

• Geç mi yüklendi?
• JavaScript tarafından mı enjekte edildi?
• CSS içinde mi gizlendi?
• Diğer görsellerin arkasında önceliği mi düşürüldü?
• Sunucu yanıt vermekte yavaş mı kaldı?

Ardından tek bir değişiklik yapın ve yeniden test edin. Ekipler aynı dağıtımda görsel formatını, geç yüklemeyi, preloading’i, JavaScript paketlerini ve CDN ayarlarını değiştirdiğinde performans çalışması dağınıklaşır. Sayfayı iyileştirebilirsiniz, ancak hangi değişikliğin önemli olduğunu bilemezsiniz.

Saha verisi de önemlidir. Laboratuvar araçları teşhis için faydalıdır, ancak LCP cihaz, ağ, görünüm alanı, önbellek durumu ve coğrafyaya göre değişir. Mümkün olduğunda gerçek kullanıcı izleme veya Chrome User Experience Report verilerini kullanın.

<!-- tool-cta:start -->

💡 Bunu deneyin: LCP görselinizi küçük ve öncelikli yüklenecek şekilde tutmak için onu Image Compressor üzerinden geçirin, böylece lazy loading gerektirmeden hızlıca render edilir.

<!-- tool-cta:end -->

Çoğu web sitesi için pratik bir politika

Çoğu pazarlama sitesi, ecommerce sayfası, dokümantasyon sitesi ve yayıncı sayfası için şu politika yeterlidir:

• İlk görünüm alanındaki birincil görsel: eager yükleyin, yüksek fetch priority düşünün.
• İlk görünüm alanının altındaki içerik görselleri: geç yükleyin.
• İkonlar ve küçük UI varlıkları: genellikle tek tek düşünmeye değmez.
• CSS arka plan hero: HTML görseli olarak yeniden değerlendirin veya dikkatli preload edin.
• JavaScript ile enjekte edilen hero görseli: mümkünse rendering mimarisini düzeltin.
• Carousel’ler: yalnızca ilk görünür slaytı eager yükleyin; kalanını geç yükleyin.

Uç durumlar vardır. Tarayıcı sezgisel kuralları gelişir. Framework’ler otomatik görsel bileşenleri ekler. Bazı platformlar artık görünüm alanına yakın tespit edilen görselleri geç yüklemekten kaçınır. Yine de ilke değişmez: kritik kaynaklar erken ve açık olmalıdır; kritik olmayan kaynaklar beklemelidir.

Geç yükleme bu ayrımı ifade ettiğinde değerlidir. En önemli içeriği, sayfa LCP yarışını kaybetmeye başladıktan sonraya kadar tarayıcıdan gizlediğinde zararlıdır.