LCP (Largest Contentful Paint) Nedir? Nasıl İyileştirilir?

Bir sayfayı açtığınızda “yüklendi” hissini veren an, menünün veya logonun göründüğü an değildir. Aradığınız ürün görseli, haber başlığı ya da yazının ilk paragrafı ekrana geldiğinde sayfa sizin için açılmış olur. Largest Contentful Paint (LCP), tam olarak bu anı ölçer: görünür alandaki en büyük içerik öğesinin ekrana çizildiği süreyi.

LCP, Google’ın Core Web Vitals metriklerinden biridir ve yüklenme hızını temsil eder. Diğer iki metrik görsel kararlılığı ölçen CLS ile etkileşim hızını ölçen INP’dir. Bu üçlü arasında en çok başarısız olunan metrik genellikle LCP’dir; çünkü sunucudan görsel optimizasyonuna, yazı tiplerinden JavaScript’e kadar pek çok katmanın toplamından etkilenir.

LCP neden “en büyük” öğeye bakıyor?

Eski hız metrikleri ya çok erken ya da çok geç bir anı ölçüyordu. Sayfanın ilk pikselinin çizildiği an, kullanıcı için anlamlı değildir; sayfanın tamamen yüklendiği an ise çoğu zaman kullanıcının çoktan okumaya başladığı andan sonra gelir. Google’ın araştırmaları, ekrandaki en büyük içerik öğesinin görünmesinin, kullanıcının “ana içerik geldi” algısıyla en iyi örtüşen basit ölçüt olduğunu gösterdi. LCP bu nedenle tasarlandı.

LCP, yüklenmenin başlangıcını ölçen FCP ile karıştırılmamalıdır. FCP, ekrana herhangi bir içeriğin ilk kez geldiği anı ölçer; LCP ise ana içeriğin geldiği anı. İkisi arasındaki fark büyükse, sayfa hızlı başlıyor ama asıl içeriği geç getiriyor demektir.

LCP eşik değerleri

1. İyi: 2,5 saniye ve altı
2. İyileştirilmeli: 2,5 ile 4 saniye arası
3. Zayıf: 4 saniyenin üzeri

Değerlendirme, gerçek kullanıcı ziyaretlerinin 75. yüzdelik dilimine göre yapılır. Yani ziyaretlerin en az dörtte üçünde ana içeriğin 2,5 saniye içinde görünmesi gerekir. Bu eşik, hızlı bağlantıdaki masaüstü kullanıcılar için kolay, orta seviye telefonla mobil veride gezen kullanıcılar için ise zordur; mobil ve masaüstü değerlerinin ayrı raporlanmasının sebebi budur.

Hangi öğeler LCP adayı sayılır?

Tarayıcı, görünür alandaki şu öğe türlerini aday olarak değerlendirir:

1. <img> öğeleri (animasyonlu görsellerde ilk kare)
2. SVG içindeki <image> öğeleri
3. <video> öğelerinin kapak görseli (poster) veya ilk karesi
4. CSS ile url() üzerinden yüklenen arka plan görselleri
5. Metin içeren blok düzeyindeki öğeler (paragraflar, başlıklar, liste öğeleri)

Bazı öğeler bilinçli olarak dışarıda bırakılır: görünmez (opaklığı sıfır) öğeler, tüm ekranı kaplayan ve genellikle arka plan niteliğindeki görseller ve çok düşük bilgi içeren yer tutucu görseller. Sonuncusu önemlidir: bulanık, tek renkli önizleme görseliyle LCP’yi “kandırmak” mümkün değildir; tarayıcı bu tür düşük içerikli görselleri aday saymaz.

LCP öğesi yükleme sırasında değişebilir

Tarayıcı, sayfa yüklenirken en büyük öğeyi sürekli günceller. Önce büyük bir başlık metni aday olur; ardından ondan büyük bir görsel yüklenince aday değişir. Ölçüm, kullanıcı sayfayla ilk kez etkileşime girdiğinde (tıklama, dokunma, tuş basımı veya kaydırma) durur. Bu yüzden aynı sayfanın LCP öğesi farklı cihazlarda farklı olabilir: masaüstünde görsel, mobilde başlık metni en büyük öğe olabilir. İyileştirmeye başlamadan önce yapılacak ilk iş, hangi öğenin LCP olduğunu cihaz bazında tespit etmektir.

LCP’yi oluşturan dört alt aşama

LCP’yi iyileştirmenin en etkili yolu, onu tek bir sayı olarak değil dört parçanın toplamı olarak görmektir. Referans aldığımız birçok Türkçe kaynağın atladığı bu ayrım, hangi optimizasyonun gerçekten işe yarayacağını gösterir.

1. İlk bayta kadar geçen süre (TTFB): Kullanıcının isteği başlatmasından sunucudan ilk baytın gelmesine kadar geçen süre. Yönlendirmeler, DNS, bağlantı kurulumu ve sunucu işleme süresi bu kalemdedir.
2. Kaynak yükleme gecikmesi (resource load delay): İlk bayt geldikten sonra, LCP görselinin indirilmeye başlamasına kadar geçen süre. Tarayıcı görseli geç fark ediyorsa bu süre uzar.
3. Kaynak yükleme süresi (resource load duration): LCP görselinin indirilmesinin sürdüğü zaman. Dosya boyutu ve ağ hızı belirler.
4. Öğe çizim gecikmesi (element render delay): Görsel indikten sonra ekrana çizilmesine kadar geçen süre. Render’ı bloke eden CSS/JavaScript veya görseli JavaScript ile sonradan yerleştiren yapılar bu süreyi uzatır.

LCP öğesi metinse ikinci ve üçüncü aşama sıfırdır; süre TTFB ile çizim gecikmesinden oluşur.

Sağlıklı bir dağılım nasıl görünür?

İdeal bir sayfada zamanın büyük kısmı TTFB ve kaynak yükleme süresine gider; iki “gecikme” kalemi ise sıfıra yakın olmalıdır. Yani görsel, HTML gelir gelmez indirilmeye başlamalı ve iner inmez ekrana çizilmelidir. Uygulamada en sık gördüğümüz tablo bunun tersidir: görsel hızlıca iner ama indirmesi geç başlar ya da indikten sonra JavaScript beklediği için geç çizilir. Bu durumda görseli sıkıştırmak neredeyse hiçbir şey kazandırmaz; asıl sorun gecikme kalemlerindedir.

PageSpeed Insights ve Lighthouse’un tanılama bölümündeki LCP aşama dökümü, bu dört parçanın süresini ayrı ayrı gösterir. Optimizasyon kararını buna bakarak vermek, deneme yanılmayı ortadan kaldırır.

Her aşama için iyileştirme yöntemleri

TTFB’yi düşürmek

Sunucu yavaşsa üstüne yapılacak her şey sınırlı kazanç verir. Sayfa önbelleği, içerik dağıtım ağı (CDN) üzerinden HTML önbellekleme, gereksiz yönlendirmelerin kaldırılması ve veritabanı sorgularının iyileştirilmesi bu kalemi düşürür. Konunun tamamını TTFB yazımızda, ağ gecikmesinin etkisini ise RTT yazımızda ayrıntılı anlattık.

Kaynak yükleme gecikmesini sıfırlamak

Bu kalemin çözümü, tarayıcının LCP görselini mümkün olan en erken anda keşfetmesini sağlamaktır.

1. Görseli HTML’de doğrudan bulundurun. JavaScript ile sonradan eklenen veya yalnızca CSS arka planı olarak tanımlanan görseller, tarayıcının ön tarayıcısı (preload scanner) tarafından geç fark edilir.
2. LCP görselini asla tembel yüklemeyin. loading="lazy" niteliği, görünür alandaki ana görsele verildiğinde tarayıcı onu bilerek geciktirir. Uygulamada en sık rastladığımız LCP hatası budur; genellikle tema veya eklenti tüm görsellere toptan tembel yükleme uyguladığı için ortaya çıkar.
3. Önceliği yükseltin. LCP görseline fetchpriority="high" eklemek, tarayıcıya bu görselin diğerlerinden önce indirilmesi gerektiğini söyler.
4. Geç keşfedilen kaynaklar için önden yükleme yapın. Görsel CSS arka planındaysa veya başka bir dosya içinde tanımlıysa <link rel="preload" as="image"> ile erkenden bildirilebilir. Duyarlı görsellerde imagesrcset ve imagesizes nitelikleriyle doğru boyut seçilir.
5. Başka alan adından geliyorsa bağlantıyı önceden kurun. Görseller ayrı bir CDN alan adındaysa <link rel="preconnect"> ile bağlantı erkenden açılabilir.

Kaynak yükleme süresini kısaltmak

1. Doğru boyutta sunun. 400 piksel genişlikte gösterilecek görsel için 2000 piksellik dosya indirmek, mobilde en büyük kayıptır. srcset ve sizes ile cihaza göre doğru boyutu verin.
2. Modern biçim kullanın. WebP ve AVIF, aynı görsel kalitede belirgin biçimde küçük dosya üretir.
3. Sıkıştırma ayarını dengeleyin. Ana görsel için makul kalite ayarı çoğu zaman gözle fark edilmeyen kayıpla ciddi boyut kazancı sağlar.
4. CDN kullanın. Görselin kullanıcıya yakın bir noktadan gelmesi indirme süresini kısaltır.
5. Rakip indirmeleri azaltın. Aynı anda indirilen çok sayıda dosya, bant genişliğini paylaştırır. İlk ekranda gerekmeyen görselleri tembel yüklemek, LCP görseline yer açar.

Çizim gecikmesini kaldırmak

1. Render’ı bloke eden CSS’i azaltın. İlk ekran için gereken kritik CSS’i sayfaya gömün, geri kalanını erteleyin.
2. Senkron JavaScript’i erteleyin. <head> içindeki senkron betikler çizimi durdurur; defer veya async kullanın.
3. İçeriği istemci tarafında oluşturmayın. Ana içeriği JavaScript çatısı yüklendikten sonra çizen yapılarda LCP, betiğin indirilip çalışmasını bekler. Sunucu tarafında oluşturma veya statik HTML bu gecikmeyi ortadan kaldırır.
4. A/B test ve kişiselleştirme betiklerine dikkat edin. Sayfayı gizleyip değişiklik yaptıktan sonra gösteren (anti-flicker) betikler, LCP’yi doğrudan geciktirir.
5. Metin LCP’lerinde yazı tipini beklemeyin. font-display: swap veya optional ile metnin yazı tipi gelmeden görünmesini sağlayın.

LCP nasıl ölçülür?

Search Console’daki Core Web Vitals raporu, sorunlu URL’leri benzer sayfa grupları hâlinde gösterir ve saha verisine dayanır. İşe buradan başlamak, hangi şablonun sorunlu olduğunu hızla gösterir.

PageSpeed Insights, üstte gerçek kullanıcı verisini (Chrome User Experience Report), altta Lighthouse laboratuvar ölçümünü gösterir. LCP öğesinin ne olduğunu ve aşama dökümünü laboratuvar bölümünde bulabilirsiniz.

Chrome geliştirici araçlarının Performans paneli, canlı ölçümde LCP öğesini ve zamanını işaretler; ağ panelinde LCP görselinin ne zaman istendiği ve hangi öncelikle indirildiği görülebilir. Araçların diğer kullanımları için geliştirici araçları rehberimize bakabilirsiniz.

Gerçek kullanıcı ölçümü için açık kaynaklı web-vitals kütüphanesi, her ziyaretin LCP değerini ve öğesini analitik aracınıza gönderebilir. Bu veri, laboratuvarda göremediğiniz cihaz ve bağlantı çeşitliliğini gösterir.

Saha verisi ile laboratuvar verisi

Lighthouse, sayfayı belirli bir cihaz ve ağ simülasyonuyla bir kez yükler. Gerçek kullanıcılar ise farklı cihazlardan, farklı bağlantılarla, bazen önbelleği dolu tarayıcılarla gelir. Bu yüzden iki değer sıkça farklıdır. Google’ın sıralamada dikkate aldığı veri saha verisidir; laboratuvar ise teşhis ve düzeltmeyi doğrulama aracıdır. Bu ayrımın hız çalışmasındaki pratik sonuçlarını site hızı yazımızda anlattık.

Sık yapılan LCP hataları

1. Ana görseli tembel yüklemek. En yaygın ve en kolay düzeltilen hatadır.
2. Ana görseli kaydırıcı (slider) içine koymak. Kaydırıcı betiği yüklenmeden ilk görsel çizilmez.
3. Ana görseli CSS arka planı yapmak. Tarayıcı onu CSS dosyasını indirip işleyene kadar keşfedemez.
4. Yalnızca görseli sıkıştırıp gecikme kalemlerine bakmamak. Asıl sorun genellikle görselin geç keşfedilmesidir.
5. Tüm görsellere yüksek öncelik vermek. Öncelik göreli bir kavramdır; her şeye yüksek öncelik vermek, hiçbirine vermemekle aynıdır.
6. Masaüstü ölçümüne bakıp karar vermek. Sorun neredeyse her zaman mobildedir.

LCP ve SEO

LCP, Google’ın sayfa deneyimi sinyallerinden biridir ve sıralamada kullanıldığı doğrulanmıştır. Ancak tek başına belirleyici değildir; içerik kalitesi ve alaka düzeyi hâlâ çok daha ağırdır. Doğrulanmış faktörlerin genel tablosunu sıralama faktörleri yazımızda bulabilirsiniz.

LCP’nin asıl etkisi kullanıcı davranışındadır: ana içeriği geç gelen sayfalarda terk oranı yükselir, özellikle reklamla gelen trafikte bu kayıp doğrudan bütçeye yansır. Aynı reklam harcamasıyla daha fazla dönüşüm almanın en ucuz yollarından biri, açılış sayfasının LCP’sini iyileştirmektir.

Varsayımsal bir iyileştirme senaryosu

Dört aşamalı bakışın neden işe yaradığını somutlaştırmak için bir e-ticaret ürün sayfası düşünelim. Rakamlar örnek amaçlıdır; gerçek bir müşteri sonucu değildir.

Mobil LCP 4,2 saniye ölçülüyor. Aşama dökümü şöyle: TTFB 0,9 saniye, kaynak yükleme gecikmesi 1,8 saniye, kaynak yükleme süresi 0,6 saniye, çizim gecikmesi 0,9 saniye.

İlk bakışta akla gelen çözüm görseli sıkıştırmaktır. Oysa indirme süresi zaten yalnızca 0,6 saniye; görseli yarı boyuta indirmek en iyi ihtimalle 0,3 saniye kazandırır. Asıl kayıp 1,8 saniyelik yükleme gecikmesindedir. İncelendiğinde ürün görselinin bir kaydırıcı betiği tarafından sonradan yerleştirildiği ve tema tarafından tembel yüklendiği görülür.

Yapılan üç değişiklik şunlardır: ilk ürün görseli kaydırıcıdan bağımsız olarak HTML’e doğrudan yazılır, tembel yükleme kaldırılır ve fetchpriority="high" eklenir. Yükleme gecikmesi 0,1 saniyeye düşer. Ardından sepet ve taksit bloklarını çizen betik ertelenir, çizim gecikmesi 0,2 saniyeye iner. Son olarak sayfa önbelleği açılır ve TTFB 0,5 saniyeye düşer. Yeni toplam: 0,5 + 0,1 + 0,6 + 0,2 = 1,4 saniye.

Bu senaryonun dersi şudur: en büyük kazanç, en çok konuşulan optimizasyondan (görsel sıkıştırma) değil, zamanın gerçekten kaybedildiği aşamadan gelir.

Platforma göre LCP sorunları

WordPress

WordPress sitelerinde LCP sorunlarının büyük kısmı temadan gelir: tüm görsellere toptan uygulanan tembel yükleme, sayfa oluşturucu eklentilerinin getirdiği ağır CSS ve JavaScript, ana görselin kaydırıcı içinde sunulması. WordPress çekirdeği, sayfadaki ilk büyük görsele otomatik olarak yüksek öncelik vermeye ve onu tembel yüklemeden çıkarmaya çalışır; ancak tema veya optimizasyon eklentisi bu davranışı kolayca bozabilir. Platforma özgü adımları WordPress hızlandırma rehberimizde anlattık.

E-ticaret altyapıları

Ürün sayfalarında LCP öğesi neredeyse her zaman ilk ürün görselidir. Bu görselin galeri betiğine bağımlı olmaması, doğru boyutta ve modern biçimde sunulması en yüksek getirili düzeltmedir. Kategori sayfalarında ise LCP çoğunlukla bir kampanya görseli veya ilk ürün kartıdır; üstteki büyük kampanya görsellerinin gerçekten gerekli olup olmadığını sorgulamak da bir seçenektir. E-ticaret teknik SEO’sunun bütününü e-ticaret SEO rehberimizde ele aldık.

Tek sayfa uygulamaları

İçeriğin tamamen istemci tarafında oluşturulduğu uygulamalarda LCP, JavaScript çatısının indirilip çalışmasını ve veri isteğinin tamamlanmasını bekler. Bu yapılarda çizim gecikmesi çoğu zaman en büyük kalemdir. Sunucu tarafında oluşturma, statik ön oluşturma veya en azından ilk ekran içeriğinin HTML ile birlikte gönderilmesi temel çözümdür.

Gözden kaçan LCP etkenleri

1. Yönlendirme zincirleri. Reklam bağlantılarında veya eski adreslerde yaşanan her yönlendirme TTFB’ye eklenir. Yönlendirme rehberimizdeki zincir temizliği doğrudan LCP kazancıdır.
2. Çerez bildirimi. Büyük bir çerez bildirimi, özellikle mobilde LCP öğesinin kendisi olabilir. Bu durumda bildirimin ne kadar hızlı çizildiği LCP’yi belirler.
3. Geri-ileri önbelleği. Sayfa bu önbellekten yararlanabildiğinde geri dönüşlerde LCP neredeyse anlık olur ve saha verisindeki ortalamayı iyileştirir.
4. Önceden oluşturma. Tarayıcıların tahminli önceden yükleme özellikleri, kullanıcının tıklayacağı sayfayı önceden hazırlayarak LCP’yi sıfıra yaklaştırabilir. Doğru yapılandırıldığında büyük kazanç sağlar ama gereksiz sunucu yükü yaratmaması için dikkatli kurgulanmalıdır.
5. Üçüncü taraf betikleri. Etiket yöneticisi üzerinden yüklenen ağır betikler ana iş parçacığını meşgul ederek çizimi geciktirir.

LCP kontrol listesi

1. Mobil ve masaüstünde LCP öğesi tespit edildi mi?
2. LCP görseli HTML’de doğrudan bulunuyor mu?
3. LCP görselinde tembel yükleme kapalı ve fetchpriority="high" var mı?
4. Görsel cihaza uygun boyutta ve modern biçimde mi?
5. Render’ı bloke eden CSS ve senkron JavaScript azaltıldı mı?
6. TTFB 0,8 saniyenin altında mı?
7. Aşama dökümünde iki gecikme kalemi sıfıra yakın mı?
8. Değişiklik sonrası saha verisi 28 günlük pencerede izleniyor mu?

LCP’nin geçmişi ve değişen tanımı

LCP, 2020’de Core Web Vitals setiyle birlikte tanıtıldı ve 2021’de sayfa deneyimi sinyallerinin parçası olarak sıralamaya dahil edildi. O günden bu yana tanımı birkaç kez inceltildi: düşük içerikli yer tutucu görsellerin aday sayılmaması, tüm ekranı kaplayan arka plan görsellerinin dışarıda bırakılması ve animasyonlu görsellerle videolarda ilk karenin esas alınması bu değişikliklerden bazılarıdır.

Bu değişikliklerin ortak amacı, metriğin gerçekten kullanıcının gördüğü ana içeriği ölçmesini sağlamak ve “kandırılabilir” olmasını engellemektir. Pratik sonucu da nettir: LCP’yi yapay hilelerle değil, ana içeriği gerçekten hızlı göstererek iyileştirmek gerekir. Tanımdaki değişiklikler zaman zaman saha verisinde sebebi anlaşılmayan küçük sıçramalar yaratabilir; böyle durumlarda Chrome’un değişiklik kayıtlarına bakmak, sorunun sitenizde mi yoksa ölçümde mi olduğunu ayırt etmenizi sağlar.

LCP’yi kim düzeltmeli?

LCP sorunları çoğu zaman tek bir ekibin alanına girmez. TTFB sunucu ve altyapı ekibinin, kaynak yükleme gecikmesi ön yüz geliştiricisinin, görsel boyutu içerik ekibinin, üçüncü taraf betikleri ise pazarlama ekibinin sorumluluğundadır. Aşama dökümü, sorunu doğru ekibe yönlendirmenin de en hızlı yoludur: “LCP kötü” demek yerine “kaynak yükleme gecikmesi 1,8 saniye, ürün görseli geç keşfediliyor” demek, düzeltmeyi günler yerine saatler içinde mümkün kılar.

LCP’yi iyileştirirken diğer metrikleri bozmamak

LCP çalışmaları bazen diğer metrikleri istemeden bozar. Ana görseli önceliklendirmek için yazı tiplerini geciktirmek metin kaymasına ve CLS artışına yol açabilir. JavaScript’i tamamen ertelemek ise ilk etkileşimde ana iş parçacığını yoğunlaştırıp INP’yi kötüleştirebilir. Bu yüzden her değişiklikten sonra üç metriğe birlikte bakmak gerekir; tek bir metriği iyileştirip diğerini bozan çözüm, kullanıcı deneyimi açısından kazanç sayılmaz.

Özetle

LCP, görünür alandaki en büyük içeriğin ekrana geldiği anı ölçer ve 2,5 saniyenin altında olması hedeflenir. En etkili iyileştirme yolu, LCP’yi TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi ve çizim gecikmesi olarak dört parçaya ayırıp zamanın nerede kaybedildiğini görmektir. Uygulamada en büyük kazanç çoğu zaman görseli küçültmekten değil, onu erken keşfettirmekten ve tembel yüklemeden çıkarmaktan gelir. Teknik SEO çalışmanızın bütününü planlamak için SEO hizmetimizi inceleyebilirsiniz.