En Büyük İçerikli Boyama (LCP)

TL;DR — En Büyük İçerikli Boyama (LCP), ekrandaki en büyük öğenin — genellikle bir kahraman görseli veya büyük bir metin bloğu — birisi sayfanıza tıkladıktan sonra görünmesinin ne kadar sürdüğünü ölçer. 2,5 saniyenin altı iyidir. Google’ın üç Temel Web Verisi’nden biridir ve çoğu sitenin en çok zorlandığı metriktir.

LCP nedir

İnsanların siteniz hakkında edindiği ilk izlenim, sayfanın ne kadar hızlı göründüğüdür. LCP buna bir sayı koymaya çalışır. Görünüm alanındaki — kaydırmadan görebildiğiniz sayfa kısmı — en büyük görünür öğeyi yüklemenin ne kadar sürdüğünü ölçer.

Bu “en büyük öğe” genellikle iki şeyden biridir:

• Büyük bir görsel — bir kahraman banner’ı, bir ürün fotoğrafı, bir öne çıkan görsel.
• Büyük bir metin bloğu — görselle başlamayan makale sayfalarında yaygındır.

LCP, sayfa ilk yüklenmeye başladığı andan itibaren ölçülen, bu öğenin işlenmeyi bitirdiği andır. Sayı ne kadar düşükse, sayfanız o kadar hızlı hissedilir.

Puan

Google, LCP’yi üç gruba ayırır:

• İyi: 2,5 saniye veya daha az
• İyileştirme gerekli: 2,5 ila 4 saniye
• Zayıf: 4 saniyeden fazla

Hedefiniz o 2,5 saniyelik işarettir. Ve bu, sitenizin gerçek ziyaretçileri üzerinden değerlendirilir — bir kez çalıştırdığınız bir test değil — yani gerçek kitlenizin gerçek telefonlarında ve bağlantılarında aldığı deneyimdir.

Neden zor olabilir

LCP, insanların en çok zorlandığı Temel Web Verisi’dir. Bunun nedeni en çok hareketli parçaya sahip olmasıdır: sunucunuzun yanıt vermesi, tarayıcının görseli bulup indirmesi ve ardından onu gerçekten boyaması gerekir. Bu adımlardan herhangi birindeki bir yavaşlama tüm sayıyı yukarı çeker. Görsellerinizi sıkıştırmak yaygın bir ilk tahmindir — ve bazen yardımcı olur — ancak genellikle gerçek darboğaz değildir.

Ayrıca masaüstünden ziyade mobilde daha zordur, çünkü telefonlar daha yavaş bağlantılara ve daha az işlem gücüne sahiptir.

Önce ne yapmalı

En yaygın hataları düzelten üç hızlı kazanım:

1. Ana görselinizi tembel yüklemeyin. “Tembel yükleme”, tarayıcıya bir görseli getirmeden önce beklemesini söyler. Bu, sayfanın altındaki şeyler için harikadır — ancak bunu kahraman görselinize yaparsanız, ekrandaki en önemli şeyi kasıtlı olarak geciktiriyorsunuz demektir. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Tarayıcıya ana görselin önemli olduğunu söyleyin — bunu tam olarak yapan bir öznitelik vardır (fetchpriority="high"). Bunu gerçekten LCP adayınız olan tek görsele koyun; birkaç görsele eklemek sinyali zayıflatır.
3. Sunucunuzu hızlandırın. Sunucunuz yanıt vermekte yavaşsa, yaptığınız diğer hiçbir şey pek bir işe yaramaz.

Tam zihinsel modeli — LCP’nin dört alt parçası, LCP öğenizi nasıl bulacağınız, işleme ve yazı tipi konuları ve bunun sıralamalar için gerçekte ne kadar önemli olduğu — istiyor musunuz? Gelişmiş sekmesine geçin.

TL;DR — LCP, sayfa yüklenmeye başladığı ana göre, görünüm alanında görünen en büyük görsel veya metin bloğunun işleme süresidir. İyi, gerçek kullanıcıların 75. yüzdelik diliminde (cihaza göre ayrılmış) ≤ 2,5 s’dir; 2,5–4 s üzerinde çalışma gerektirir, 4 s üzeri zayıftır. Üç Temel Web Verisi’nden biridir ve dört alt parçaya ayrılır — TTFB, kaynak yükleme gecikmesi, kaynak yükleme süresi, öğe işleme gecikmesi — burada TTFB ve yükleme süresi genellikle baskındır (kılavuzlar, sabit paylar değil — kendi sayfanızı teşhis edin). En iyi düzeltmeler: LCP görselini asla tembel yüklemeyin, gerçek adaya fetchpriority="high" ekleyin, HTML’de olmadığında onu önceden yükleyin, işlemeyi engelleyen CSS/JS’i ortadan kaldırın ve TTFB’yi düzeltin. Bu bir saha metriğidir — laboratuvar araçları yalnızca yaklaşık değer verir — ve LCP öğesi yükleme sırasında değişebilir. Google, Temel Web Verileri’nin sıralama sistemlerini beslediğini doğrular ancak kesin bir LCP ağırlığı yayınlamaz veya buna bir eşitlik bozucu demez; içerik alaka düzeyi hâlâ baskındır.

LCP gerçekte neyi ölçer

LCP, görünüm alanında (viewport) görünen en büyük görsel veya metin bloğunun, kullanıcının sayfaya ilk kez gitmesinden itibaren ölçülen işleme süresini raporlar. Google’ın kendi çerçevesi: ana içeriğin kullanıcıya görünme zamanının en yakın standartlaştırılmış vekilidir. İlk Anlamlı Boyama (First Meaningful Paint) ve Hız Endeksi (Speed Index) gibi daha önceki, daha belirsiz metriklerin yerini almıştır.

İnsanların hemen takıldığı birkaç şey:

• “Sayfa yükleme süresi” değildir. Bir sayfanın tüm kaynakları getirilmiş olsa bile, en büyük öğenin işlenmesi engellenmişse yine de yavaş bir LCP gösterebilir. LCP, tüm sayfayla değil, o tek öğeyle ilgilidir.
• FCP ile aynı şey değildir. İlk İçerikli Boyama (First Contentful Paint), herhangi bir içerik ilk kez göründüğünde tetiklenir; LCP ise en büyük öğeyi bekler. Bir sayfa hızlı bir FCP’ye (gezinme çubuğu boyanır) ve yavaş bir LCP’ye (kahraman görseli geç yüklenir) sahip olabilir.
• Dinamik bir metriktir. Tarayıcı, daha büyük bir öğe görünür hale geldiğinde her seferinde yeni bir LCP adayı gönderir. Kullanıcı etkileşime geçmeden (dokunma, kaydırma, tuşa basma) veya sayfa kapanmadan önceki son girdi, sayılan değerdir — etkileşim genellikle görünenleri değiştirir, bu nedenle raporlama orada durur. Daha sonra DOM’dan kaldırılan bir aday, kendi girdisini silmez — raporlama durmadan önce daha da büyük bir öğe işlenmedikçe, raporlanan öğe olarak kalır.

Eşikler — ve neden 2,5 saniye

Gerçek kullanıcı sayfa yüklemelerinin 75. yüzdelik diliminde, cihaz türüne göre ayrıştırılarak değerlendirilir. Yani bir kaynağın geçmesi için dört ziyaretten üçünün 2,5 saniyenin altında kalması gerekir.

Neden özellikle 2,5? Google’ın eşik metodolojisi iki şeye dayanıyordu: yaklaşık 1-3 saniyeyi “anında” hissettiren aralık olarak gösteren insan algısı araştırması ve 2,5 saniyenin iyi optimize edilmiş siteler için tutarlı bir şekilde ulaşılabilir olduğunu, ancak önemsiz derecede kolay olmadığını gösteren CrUX ulaşılabilirlik verileri. 1,5 s veya 2,0 s gibi daha sıkı hedefler yeterli sayıda kaynakta tutarlı bir şekilde ulaşılabilir değildi, bu yüzden seçilmedi.

LCP öğesi olarak kabul edilenler

LCP için dikkate alınan öğe türleri:

• <img> öğeleri
• Bir <image> içindeki <svg> öğeleri
• <video> öğeleri (poster görselinin yükleme süresi veya ilk kare, hangisi daha önceyse)
• CSS url() işleviyle yüklenen bir arka plan görseline sahip bir öğe
• Metin düğümleri veya diğer satır içi metin alt öğelerini içeren blok düzeyinde öğeler

Raporlanan boyut, görünüm alanında gerçekte görünendir — kırpılan veya kaydırılarak dışarı çıkan kısımlar sayılmaz ve görseller için görünür boyut veya doğal boyuttan hangisi daha küçükse odur. Kenar boşlukları, dolgular ve kenarlıklar yok sayılır. Bir avuç öğe, buluşsal yöntemlerle hariç tutulur: opacity: 0 olan her şey, tüm görünüm alanını kaplayan öğeler (arka plan olarak kabul edilir) ve düşük entropili yer tutucu görseller.

Sayfaların yaklaşık dörtte üçünde LCP öğesi olarak bir görsel bulunur — bu nedenle görsel işleri genellikle doğru ilk hamledir. Ama her zaman değil ve her zaman sıkıştırma da değil (bununla ilgili daha fazlası sonra). Kalan kısım metin LCP’leridir; burada kaldıraç tamamen farklıdır: görsel ağırlığı değil, yazı tipi yüklemedir.

Dört alt bölüm — çoğu makalenin atladığı kısım

Bu, herhangi bir LCP teşhisine başlayacağım çerçevedir. web.dev, LCP’yi dört sıralı alt bölüme ayırır:

1. İlk Bayta Kadar Geçen Süre (TTFB) — kullanıcının sayfayı yüklemeye başlamasından tarayıcının HTML’in ilk baytını almasına kadar. Tipik pay: toplam LCP’nin yaklaşık %40’ı.
2. Kaynak yükleme gecikmesi — TTFB ile tarayıcının LCP kaynağını yüklemeye başlaması arasındaki boşluk. Bu keşif süresidir. Tipik pay: %10’un altında.
3. Kaynak yükleme süresi — LCP kaynağının kendisinin indirilmesinin ne kadar sürdüğü. Tipik pay: yaklaşık %40.
4. Öğe işleme gecikmesi — kaynağın yüklenmesinin bitmesinden öğenin gerçekten boyanmasına kadar. Tipik pay: %10’un altında.

Tablonun arkasındaki ilke: LCP süresinin büyük çoğunluğu HTML belgesinin ve LCP kaynağının yüklenmesiyle geçmelidir. Hiçbirinin yüklenmediği her aralık, iyileştirme fırsatıdır.

web.dev bu yüzdelerin kılavuz niteliğinde olduğunu, katı kurallar olmadığını açıkça belirtir — bunları mutlak saniye hedeflerine dönüştürmeyin ve her sayfayı bu dağılıma uymaya zorlamayın. Bunlar yalnızca birbirlerine göre anlamlıdır ve LCP’niz zaten tutarlı bir şekilde 2,5 saniyenin altındaysa, göreli oranlar hiç önemli değildir. Tabloyu, sizin sayfanızda hangi alt bileşenin orantısız bir pay aldığını tespit etmek için kullanın ve ardından yalnızca onu düzeltin — tam bir 40/10/40/10 dağılımını yakalamak için değil.

Ve işte yaygın varsayımı alt üst eden kısım: Şubat 2025 itibarıyla bu dört alt bileşen, görsel LCP’leri için CrUX API’sinde mevcuttur ve Chrome ekibinin HTTP Archive verileri analizi, görsel indirme süresinin genellikle LCP süresinin en küçük parçası olduğunu bulmuştur. Başka bir deyişle, “sadece görsellerimi sıkıştır” yaklaşımı genellikle yanlış alt bileşeni düzeltir. TTFB ve keşif gecikmesi genellikle daha büyük kaldıraçlardır.

LCP öğenizi nasıl bulursunuz

Herhangi bir şeyi optimize etmeden önce, hangi öğenin LCP’niz olduğunu ve hangi alt bileşenin darboğaz olduğunu öğrenin:

• PageSpeed Insights — Diagnostics bölümü LCP öğesini işaretler ve alan verileri sekmesi gerçek kullanıcı puanınızı gösterir.
• Chrome DevTools — Performance paneli, zaman çizelgesinde LCP düğümünü işaretler.
• web-vitals JS kitaplığı — kendi gerçek kullanıcı izlemenizden LCP’yi (ve öğeyi) günlüğe kaydedin.

LCP nasıl iyileştirilir

Her düzeltmeyi hedeflediği alt bileşenle eşleştirin:

Kaynak yükleme gecikmesini (keşif) düzeltin. Bu, en yüksek kaldıraçlı ve en yaygın olarak bozuk olanıdır.

• LCP görselinizi asla tembel yüklemeyin. LCP öğesindeki loading="lazy" her zaman gereksiz yükleme gecikmesi ekler. Tembel yüklemeyi yalnızca ekran altı görseller için ayırın.
• Muhtemel LCP görseline fetchpriority="high" ekleyin, böylece tarayıcı onu erken ve yüksek öncelikle getirir.
• Görsel ilk HTML’de keşfedilemediğinde — örneğin CSS veya JavaScript aracılığıyla yüklendiğinde — onu <link rel="preload"> ile önceden yükleyin. Kahraman görselini JS ile yüklemek, tam olarak URL’yi tarayıcının ön yükleme tarayıcısından gizlediği için bir anti-desendir.
• Kritik kaynakları aynı kaynakta barındırın, böylece tarayıcı ekstra bağlantı kurulumu ödemez.

Ön yükleme ve fetchpriority farklı sorunları çözer, bu yüzden alışkanlıkla ikisine de başvurmayın. Ön yükleme, tarayıcının ön yükleme tarayıcısının aksi takdirde geç keşfedeceği bir kaynağı (örneğin JS veya CSS ile yüklenen bir görsel) ortaya çıkarır; fetchpriority, tarayıcının zaten bulduğu bir kaynağın getirme önceliğini değiştirir. Keşif ve öncelik zaten doğruysa — görsel ilk HTML’de düz bir <img> ise — herhangi birini eklemek, ekstra isteklerin ötesinde çok az şey yapabilir. Bir izleme kontrol edin, gerçek sorunla eşleşeni uygulayın ve alan numarasının hareket ettiğini doğrulayın.

Öğe işleme gecikmesini düzeltin.

• İşlemeyi engelleyen CSS’i azaltın veya satır içine alın; kritik olmayan stilleri erteleyin.
• <head> içinde senkron komut dosyalarından kaçının.
• İşaretlemenin boyamaya hazır gelmesi için sunucu tarafı işlemeyi veya statik oluşturmayı tercih edin ve uzun ana iş parçacığı görevlerini bölün.

Kaynak yükleme süresini azaltın.

• Modern görsel biçimleri (WebP, AVIF), makul sıkıştırma ve bir CDN.
• Verimli Cache-Control. Ve ağ çekişmesini göz ardı etmeyin — diğer ekran altı görselleri tembel yüklemek, bant genişliğini boşaltarak LCP görselinin daha erken gelmesini sağlayabilir.

TTFB’yi azaltın.

• Yönlendirmeleri en aza indirin, gereksiz benzersiz URL parametrelerini kaldırın ve sunucu yanıt süresini optimize edin. LCP’nin önceki sayfadan kalan boşaltma süresini, bağlantı kurulumunu ve yönlendirme süresini içerdiğini unutmayın — bunların tümü TTFB’ye dahildir.

Özel durum: metin tabanlı LCP. En büyük öğe metin olduğunda, kritik yol yazı tipi yüklemedir, görüntü ağırlığı değil. font-display: optional veya sistem yazı tipleri, yazı tipi kaynaklı işleme gecikmesini ortadan kaldırır; font-display: swap yazı tipi dosyasını önceden yüklemeden bu gecikmeyi ortaya çıkarabilir.

Laboratuvar ve saha — bu ayrım önemlidir

LCP temelde bir saha metriğidir. Google, bunu CrUX aracılığıyla gerçek kullanıcılar üzerinde değerlendirir; PageSpeed Insights’ın saha sekmesinde ve Search Console Core Web Vitals raporunda görüntülenir. Sıralamaları besleyen şey bu saha verisidir.

Laboratuvar araçları — Lighthouse, Chrome DevTools, WebPageTest — yalnızca simüle edilmiş koşullar altında yaklaşık değer verir ve aynı puanlamayı bile kullanmazlar. Lighthouse, saha standardından (≤ 2,5 s) daha katı masaüstü eşikleri (İyi ≤ 1,2 s) uygular. Bu nedenle, geçerli bir Lighthouse puanı geçerli bir CrUX puanını garanti etmez ve bunun tersi de geçerlidir. Hata ayıklamak ve yeniden üretmek için laboratuvar araçlarını kullanın; gerçek karar için saha verilerine güvenin.

Laboratuvar ve saha sayılarının farklılaşabilmesinin ikinci bir nedeni daha var; tuhaf bir okumanın sizi hayalet bir hatanın peşine düşürmemesi için bilmeye değer: mevcut LargestContentfulPaint tarayıcı API’si (hâlâ bir W3C Çalışma Taslağı) tek bir belge yüklemesiyle sınırlıdır. Geri/ileri önbellek (bfcache) geri yüklemelerinde veya aynı belge içi SPA gezinmelerinde kendiliğinden sıfırlanmaz ve ekran dışında başlayan sayfalar — arka plan sekmeleri, önceden işlenmiş sayfalar — zamanlama, sayfa gerçekten görünür olduğunda değil de yüklemeden itibaren çalıştığı için şişirilmiş değerler bildirebilir. Raporlama algoritması ayrıca nitelikli kullanıcı girişinde durur; bu nedenle ana içeriğiniz görüntülenmeden önce bir kullanıcı etkileşime girerse, LCP bunu yakalamaz. Bunların hiçbiri yukarıdaki eşik tablosunu değiştirmez; altta yatan gezinme düz bir ilk yükleme olmadığında belirli bir oturumun sayısının neden yanlış görünebileceğini açıklar.

LCP sıralamaları etkiler mi?

Evet, Google’ın Core Web Vitals’ın sıralama sistemlerini beslediğini onaylaması ve iyi puanlar almayı önermesi anlamında. Ancak mevcut Search Central belgeleri kesin bir LCP ağırlığı yayınlamıyor ve bunu bir eşitlik bozucu olarak tanımlamıyor — Google’ın kendi çerçevesi, sayfa deneyiminin, birden fazla sayfanın zaten karşılaştırılabilir ve ilgili içerik sunduğu sorgular için “Arama’da başarıya katkıda bulunabileceğini” ve iyi bir puanın sıralama artışını garanti etmediğini belirtir. İçerik alaka düzeyi ve kalitesi hâlâ baskındır. LCP’yi optimize edin çünkü daha hızlı hissettiren bir sayfa kullanıcılar (ve dönüşümler) için gerçekten daha iyidir — mekanizma sıralama eşitlik bozucu olarak belgelendiği için değil, çünkü öyle değil.

Verilerden birkaç gerçek: Core Web Vitals arasında LCP, sitelerin iyileştirmekte en çok zorlandığı metriktir ve masaüstünden ziyade mobilde belirgin şekilde daha zordur — daha yavaş CPU’lar ve bağlantılar. 3G ve daha yavaşında, 2,5 s eşiğine ulaşmak neredeyse imkânsız hissedilebilir.

Bu nereye uyuyor

LCP, Interaction to Next Paint ve Cumulative Layout Shift ile birlikte üç Core Web Vitals’tan biridir. İlk alt parçası olan Time to First Byte, kendi teşhis metriğidir ve First Contentful Paint, yükleme zaman çizelgesinde hemen yanında yer alır. Bunların tümünü PageSpeed Insights, Lighthouse ve Chrome User Experience Report’ta (CrUX) görürsünüz. Her biri bu kümede kendi derinlemesine incelemesidir.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• LCP = en iyi görünen en büyük görsel veya metin bloğunun işlenme süresi, sayfa yüklenmeye başladığı ana göre. “Ana içerik ne zaman görünür?” sorusunun standartlaştırılmış en yakın temsilcisidir.
• Eşikler: İyi ≤ 2,5 s, İyileştirme gerekli 2,5–4 s, Zayıf > 4 s — gerçek kullanıcıların 75. yüzdelik diliminde, cihaza göre ayrılmıştır. Üç Temel Web Verisi’nden biridir.
• Sayfa yükleme süresi değil, FCP değil. FCP = herhangi bir içeriğin ilk pikseli; LCP = en büyük öğe. LCP ayrıca dinamiktir — en büyük aday yükleme sırasında değişebilir; kullanıcı etkileşiminden önceki son aday sayılır.
• LCP öğeleri: <img>, <image> içinde <svg>, <video> posteri, CSS background-image: url() veya blok düzeyinde bir metin öğesi. Sayfaların yaklaşık 4’te 3’ünde görsel LCP’si vardır; geri kalanı metindir (burada kaldıraç görsel ağırlığı değil yazı tipleridir).
• Dört alt bölüm: TTFB (%40), kaynak yükleme gecikmesi (<%10), kaynak yükleme süresi (%40), öğe işleme gecikmesi (<%10) — web.dev bunlara sabit paylar değil kılavuz ilkeler der; kesin bir bölünme peşinde koşmak yerine sayfa bazında teşhis edin. CrUX 2025 verileri: görsel indirme genellikle en küçük kısımdır — bu nedenle “sadece görselleri sıkıştırın” genellikle yanlış şeyi düzeltir.
• En iyi düzeltmeler: LCP görselini asla tembel yüklemeyin; gerçek adaya fetchpriority="high" ekleyin; HTML’de değilse önceden yükleyin (önceden yükleme ve fetchpriority farklı sorunları çözer — alışkanlıkla ikisine de başvurmayın); işlemeyi engelleyen CSS/JS’i azaltın; TTFB’yi düşürün.
• Sahada, laboratuvarda değil. CrUX/Search Console sıralamaları yönlendirir; Lighthouse yalnızca yaklaşık değer verir ve daha katı masaüstü eşikleri kullanır (≤ 1,2 s). Mevcut LargestContentfulPaint API’si belge yüklemeleriyle sınırlıdır ve bfcache geri yüklemeleri veya aynı belge SPA gezinmeleri için kendini sıfırlamaz.
• Sıralamalar: Google, CWV besleme sıralama sistemlerini doğrular ancak kesin bir LCP ağırlığı yayınlamaz ve bunu bir eşitlik bozucu olarak adlandırmaz; içerik alaka düzeyi hâlâ baskındır. İyileştirilmesi en zor CWV’dir ve mobilde daha da zordur.

Resmi dokümantasyon

Google’ın Chrome ve Arama ekiplerinden birincil kaynak rehberliği.

web.dev (Chrome ekibi)

• Largest Contentful Paint (LCP) — kanonik tanım: LCP öğesi olarak sayılanlar, boyutun nasıl hesaplandığı, raporlamanın ne zaman durduğu ve ölçüm API’leri.
• Optimize Largest Contentful Paint — dört alt bölüm çerçevesi ve eksiksiz optimizasyon oyun kitabı.
• Core Web Vitals — LCP’nin üç Temel Web Verisi arasındaki yeri.
• How the Core Web Vitals metrics thresholds were defined — 2,5 s işaretinin arkasındaki araştırma ve ulaşılabilirlik verileri.

Chrome for Developers

• LCP image subparts and RTT now available in CrUX — dört alt bölümün (yalnızca görsel LCP’leri) Şubat 2025 saha verisi sürümü.
• Largest Contentful Paint | Lighthouse — laboratuvar metriği ve cihaza özel puanlaması.

Google Search Central

• Understanding Core Web Vitals and Google search results — Temel Web Verileri’nin Arama’ya nasıl dahil olduğu.

Kaynaktan alıntılar

Google’ın dokümantasyonundan ve ekibinden kayıt altına alınmış ifadeler. Her bağlantı, alıntılanan pasaja atlayan bir derin bağlantıdır.

web.dev — tanım ve davranış (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (çeviri) «LCP, kullanıcının sayfaya ilk kez gittiği ana göre ölçülen, görünüm alanında görünen en büyük görselin, metin bloğunun veya videonun oluşturulma süresini raporlar.» Alıntıya git
• Ne ölçüldüğü hakkında: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (çeviri) «LCP, CSS kullanılarak uygulanan kenar boşluklarını, iç boşlukları veya kenarlıkları dikkate almaz.» Alıntıya git
• Raporlamanın ne zaman durduğu hakkında: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (çeviri) «Tarayıcı, kullanıcı sayfayla etkileşime girdiği anda (dokunma, kaydırma veya tuşa basma yoluyla) yeni girdileri raporlamayı durdurur; çünkü kullanıcı etkileşimi genellikle kullanıcının gördüklerini değiştirir.» Alıntıya git
• Zamanlamaya nelerin dahil olduğu hakkında: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (çeviri) «LCP’nin önceki sayfadan herhangi bir kaldırma süresini, bağlantı kurulum süresini, yönlendirme süresini ve diğer Time To First Byte (TTFB) gecikmelerini içerdiğini not etmek önemlidir.» Alıntıya git

web.dev — optimizasyon (Philip Walton & Barry Pollard, Google)

• En önemli tek tembel yükleme kuralı: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (çeviri) «LCP görselinizi asla tembel yüklemeyin; çünkü bu her zaman gereksiz kaynak yükleme gecikmesine yol açar.» Alıntıya git
• Alt bölüm hedeflerinin arkasındaki ilke: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (çeviri) «LCP süresinin büyük çoğunluğu HTML belgesini ve LCP kaynağını yüklemeye harcanmalıdır.» Alıntıya git

Google Search Central — sıralamalar

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (çeviri) «Site sahiplerinin, Search’te başarılı olmak ve genel olarak harika bir kullanıcı deneyimi sağlamak için iyi Core Web Vitals elde etmelerini şiddetle öneriyoruz.» (Search Central Core Web Vitals belgesinden aktarılmıştır; nihai olarak kabul etmeden önce canlı sayfaya karşı doğrulayın.)

LCP düzeltme kontrol listesi

Kabaca yukarıdan aşağıya doğru çalışın — önce keşif ve TTFB, çünkü bunlar genellikle en büyük ve en sık bozulan kaldıraçlardır.

• Gerçek LCP öğesini buldun (PageSpeed Insights Diagnostics, DevTools Performance paneli veya web-vitals kütüphanesi) — körlemesine optimize etme.
• Herhangi bir şeyi değiştirmeden önce hangisinin darboğaz olduğunu görmek için dört alt parçayı kontrol ettin.
• LCP görseli loading="lazy" değil (yavaş yükleme yalnızca sayfanın alt kısmına aittir).
• LCP görselinde fetchpriority="high" var.
• LCP görseli ilk HTML’de bulunabilir — veya CSS/JS ile yükleniyorsa önceden yüklenmiş (<link rel="preload">).
• Hero görseli JavaScript ile yüklenmiyor (ön yükleme tarayıcısından gizler).
• Render’ı engelleyen CSS en aza indirildi/satır içine alındı; kritik olmayan stiller ertelendi.
• <head> içinde senkron script yok; uzun görevler bölündü.
• Modern görsel formatı (WebP/AVIF), makul sıkıştırma, iyi Cache-Control ile bir CDN üzerinden sunuluyor.
• Sayfanın altındaki görseller yavaş yüklendi, böylece LCP görseliyle bant genişliği için rekabet etmezler.
• TTFB ele alındı: yönlendirmeler en aza indirildi, sunucu yanıtı optimize edildi, gereksiz URL parametreleri kaldırıldı.
• Metin LCP? font-display: optional veya sistem fontları kullanılıyor ve değiştirilen herhangi bir font dosyası önceden yükleniyor.
• Yalnızca bir Lighthouse laboratuvar çalışmasıyla değil, saha verileriyle (CrUX / Search Console) doğrulandı.

LCP hile sayfası

Eşikler (gerçek kullanıcıların 75. yüzdelik dilimi, cihaza göre)

Dört alt parça — her biri nedir ve çözümü

LCP öğesi ne olabilir

• <img> · <image> içinde <svg> · <video> posteri · CSS background-image: url() · blok düzeyinde metin

Sezgisel yöntemle hariç tutulanlar: opacity: 0, tam görünüm alanı “arka plan” öğeleri, düşük entropili yer tutucular.

Hızlı bilgiler

• LCP bir saha metriğidir (CrUX / Search Console sıralamaları yönlendirir); Lighthouse yalnızca yaklaşık değer verir ve daha katı bir masaüstü İyi değeri olan ≤ 1,2 s kullanır.
• LCP öğesi yükleme sırasında değişebilir; kullanıcı etkileşiminden önceki son aday sayılır.
• Sayfaların yaklaşık 3’te 4’ünde görsel LCP vardır; geri kalanı metindir (fontlar kaldıraçtır).
• Görsel indirme süresi genellikle en küçük alt parçadır — sıkıştırma her zaman çözüm değildir.
• LCP ≠ FCP; LCP ≠ toplam sayfa yükleme süresi.

LCP’yi ölçmek ve düzeltmek için araçlar

Saha verileri (sıralamaların kullandığı)

• PageSpeed Insights — saha sekmesi gerçek kullanıcı CrUX LCP’nizi gösterir; Diagnostics LCP öğesini işaretler.
• Search Console — Core Web Vitals raporu — URL’leriniz genelinde LCP durumu, gruplandırılmış, gerçek kullanıcı verileriyle.
• Chrome User Experience Report (CrUX) — temel saha veri seti; Şubat 2025 itibarıyla API üzerinden dört görsel LCP alt parçasını içerir.
• web-vitals JS kütüphanesi — kendi gerçek kullanıcı izlemenizden LCP’yi ve LCP öğesini günlüğe kaydedin.

Laboratuvar verileri (hata ayıklama için)

• Lighthouse — hızlı laboratuvar LCP’si ve bir fırsat listesi (unutmayın: sahadan daha katı masaüstü eşikleri).
• Chrome DevTools — Performance paneli — LCP düğümünü ve tam render zaman çizelgesini işaretler.
• WebPageTest — hangi alt parçanın yavaş olduğunu belirlemek için şelale görünümü.

SEO tarayıcıları

• Ahrefs Site Audit — site genelinde ölçekte Core Web Vitals / performans sorunlarını yüzeye çıkarır.

Araçların kendileri nasıl puanlanıyor

Bu sayfanın açıkladığı metriğin canlı bir örneği — iyi bilinen sayfa hızı ve izleme hizmetleri, kendi gerçek kullanıcı mobil LCP’lerine (Chrome UX Report saha verileri) göre sıralandı:

LCP düzeltmeleri yanlış sorunu hedefliyor

Hero görselinin tembel yüklenmesi

loading="lazy", LCP olma olasılığı yüksek olan ekran üstü bir görselin keşfedilmesini geciktirir. Onu hevesli bir şekilde yükleyin, olası adaya fetchpriority="high" verin ve tembel yüklemeyi ekran altı görseller için saklayın.

Darboğazı bulmadan önce her görseli sıkıştırmak

Görsel indirme süresi, dört LCP alt bölümünden yalnızca biridir ve en küçüğü olabilir. LCP öğesini belirleyin ve bir düzeltme seçmeden önce TTFB, yükleme gecikmesi, yükleme süresi ve işleme gecikmesini inceleyin.

Hero görselini JavaScript aracılığıyla yüklemek

JS ile eklenen bir görsel, URL’sini tarayıcının ön yükleme tarayıcısından gizler ve kaynak yükleme gecikmesi yaratır. Görseli ilk HTML’e koyun veya CSS veya JS’nin sahip olması gerektiğinde önceden yükleyin.

Tek bir Lighthouse çalıştırmasından zafer ilan etmek

Lighthouse kontrollü bir tanılama aracıdır; Google’ın CWV kararı ise CrUX saha verilerinden gelir. Mekanizmayı doğrulamak için laboratuvar çalıştırmalarını kullanın ve p75 sonucunun iyileşip iyileşmediğini görmek için gerçek kullanıcı verilerini bekleyin.

LCP kaynağı geç başlıyor

Belirti: TTFB ile LCP kaynak isteği arasında uzun bir boşluk görünür. Olası neden: tembel yükleme, JS keşfi, bir CSS arka plan görseli veya düşük getirme önceliği. Düzeltme: kaynağı ilk HTML’de keşfedilebilir yapın, tembel yüklemeyi kaldırın, fetchpriority="high" uygulayın veya önceden yükleyin. İsteğin bir izlemede daha erken hareket ettiğini doğrulayın.

Kaynak yükleniyor ancak LCP hala geç tetikleniyor

Belirti: yükleme süresi LCP olayından çok önce biter. Olası neden: işlemeyi engelleyen CSS, eşzamanlı JavaScript, uzun bir görev veya metin LCP için yazı tipi işleme. Düzeltme: engelleyen işi azaltın ve metin için yazı tipi stratejisini test edin; öğe işleme gecikmesinin küçüldüğünü doğrulayın.

Laboratuvar LCP’si iyi ancak saha LCP’si zayıf

Belirti: Lighthouse geçerken CrUX veya Search Console geçmiyor. Olası neden: gerçek kullanıcıların farklı cihazları, ağları, önbellek durumları, coğrafyaları veya LCP öğeleri vardır. Düzeltme: saha verilerini bölümlere ayırın, RUM öğe/alt bölüm ayrıntılarını yakalayın ve yalnızca varsayılan laboratuvar profilini ayarlamak yerine yavaş bölümü yeniden üretin.

Bildirilen LCP öğesi çalıştırmalar arasında değişiyor

Belirti: DevTools farklı görselleri veya metin bloklarını tanımlar. Olası neden: duyarlı kesme noktaları, kişiselleştirme, geç DOM değişiklikleri veya rakip adaylar. Düzeltme: temsili görünüm alanlarını ve durumları test edin, ardından tek bir masaüstü hero’nun her kullanıcıyı kapsadığını varsaymak yerine her yinelenen adayı optimize edin.

Hero görseli keşfi: gecikmeli vs erken

Basitleştirilmiş bir gecikmeli uygulama, görseli JavaScript’in arkasına gizler:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

Tarayıcı bu sürümü HTML ayrıştırırken keşfedebilir ve önceliklendirebilir:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

CSS arka plan görseli: açıklanmamış vs önceden yüklenmiş

LCP görseli bir CSS arka planı olarak kalmalıysa, stil sayfası bitmeden önce onu açıklayın:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Ön yükleme yalnızca URL’si ve istek öznitelikleri gerçek kaynakla eşleştiğinde yardımcı olur.

Chrome DevTools’ta son LCP adaylarını listele

Bunu Chrome DevTools Konsolu’na yapıştırın, sayfayı yeniden yükleyin ve tarayıcının bildirdiği her adayı izleyin. Etkileşimden önceki son aday ilgili olanıdır.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Olası tembel yüklenen ekran üstü görselleri bul

Bunu DevTools Konsolu’nda çalıştırın. Üst kenarı geçerli görünüm alanında başlayan tembel görselleri listeler; özniteliği kaldırmadan önce gerçek LCP adayını doğrulayın.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Bir tarayıcıda görsel öncelik özniteliklerini çıkar

Yüksek öncelikli olarak işaretlenmiş görselleri döndürmek için Screaming Frog özel çıkarımında bu XPath’i kullanın:

//img[@fetchpriority='high']/@src

Bir LCP düzeltmesinin uygulandığını kanıtla

Keşif sırası testi

Çalıştırılacak test: hero görselini değiştirdikten sonra bir DevTools Performance izi kaydedin. Beklenen sonuç: LCP isteği daha erken başlar ve tembel yüklenmez. Başarısızlık yorumu: kaynak gizli kalır, önceliği düşürülür veya başka bir bağımlılığın arkasında engellenir. İzleme penceresi: anında laboratuvar sonucu. Geri alma tetikleyicisi: değişiklik başka bir kritik kaynağı geciktirir veya laboratuvar LCP’sini tutarlı bir şekilde kötüleştirir.

İşleme gecikmesi testi

Çalıştırılacak test: eşdeğer önceki/sonraki izlemelerde LCP kaynak tamamlama ve LCP olayını karşılaştırın. Beklenen sonuç: yeni bir düzen veya görsel gerileme olmadan öğe işleme gecikmesi azalır. Başarısızlık yorumu: CSS, JavaScript veya yazı tipleri hâlâ boyamayı engelliyor. İzleme penceresi: temsili görüntü alanlarında anında. Geri alma tetikleyicisi: bozuk işleme, eksik stiller veya daha kötü bir yinelenen LCP.

Saha sonucu testi

Çalıştırılacak test: dağıtımdan sonra URL düzeyinde CrUX veya birinci taraf RUM p75 LCP’yi izleyin. Beklenen sonuç: p75, INP veya CLS’yi gerilemeden İyi eşiğine doğru hareket eder veya bu eşikte kalır. Başarısızlık yorumu: laboratuvar durumu temsili değildi veya başka bir alt bölüm gerçek ziyaretlerde baskın. İzleme penceresi: RUM öncülük edebilir; CrUX’un dönen 28 günlük penceresinin dönmesi gerekir. Geri alma tetikleyicisi: sürümle bağlantılı kalıcı bir saha gerilemesi.

İzlemeye değer LCP metrikleri

Saha p75 LCP

Metrik: form faktörüne göre 75. yüzdelik dilimde LCP. Size ne söyler: gerçek kullanıcıların Core Web Vitals yükleme eşiğini karşılayıp karşılamadığını. Nasıl çekilir: CrUX, Search Console veya birinci taraf RUM. Kıyaslama / gerçekçi aralık: İyi, 2,5 saniye veya altıdır; mobil ve masaüstünü ayırın. Sıklık: CrUX dönen penceresi kaydedilerek haftalık.

LCP alt bölüm dağılımı

Metrik: LCP için TTFB, kaynak yükleme gecikmesi, yükleme süresi ve öğe işleme gecikmesi. Size ne söyler: beklemenin hangi aşamaya ait olduğunu. Nasıl çekilir: temsili laboratuvar izlemeleri ve mevcut olduğunda CrUX/RUM’dan görüntü-LCP alt bölümleri. Kıyaslama / gerçekçi aralık: makalenin yaklaşık 40/10/40/10 tanılama bölünmesini evrensel bir performans vaadi olarak değil, bir rehber olarak kullanın. Sıklık: şablon sürümlerinden sonra ve öncelikli şablonlar için aylık.

İyi-LCP URL kapsamı

Metrik: İyi saha LCP’sine sahip önemli URL grupları. Size ne söyler: iyileştirmenin geniş mi yoksa örnek bir sayfayla mı sınırlı olduğunu. Nasıl çekilir: Search Console CWV grupları artı öncelikli sayfalar için URL düzeyinde CrUX. Kıyaslama / gerçekçi aralık: şablona göre bir temel oluşturun; düşük trafikli URL’lerde bireysel saha verisi eksik olabilir. Sıklık: haftalık.

Kendinizi test edin: Largest Contentful Paint

LCP ölçümü ve tanısı hakkında beş hızlı soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What Is Largest Contentful Paint (LCP) & How To Improve It — Ahrefs blogundaki tam LCP rehberim.
• What Are Core Web Vitals (CWVs) & How To Improve Them — LCP’nin INP ve CLS ile nasıl uyum sağladığı ve neden düzeltilmesi en zor olan olduğu.
• The Beginner’s Guide to Technical SEO — sayfa performansının büyük resimde nerede durduğu.

Resmî (Google / Chrome)

• Largest Contentful Paint (LCP) ve Optimize LCP — kanonik çift.
• How CWV thresholds were defined — 2,5 s’nin arkasındaki neden.

Diğer kaynaklardan

• Fix your website’s Largest Contentful Paint by optimizing image loading — MDN’nin geliştirici odaklı yaklaşımı; bant genişliği rekabeti ve JS-görsel anti-deseni konularında güçlü.
• Performance — 2025 Web Almanac — HTTP Archive’in yıllık derinlemesine incelemesi; fetchpriority, preload kullanımı, görsel ve metin LCP dağılımları ve cihaz bazlı geçiş oranları için kaynak.
• Largest Contentful Paint (LCP) — DebugBear’ın dokümantasyonu, alt parçaları belirlemek için su basması analizini, progresif JPEG uyarılarını ve iframe/yumuşak gezinme uç durumlarını kapsar.
• Largest Contentful Paint (LCP): What It Is, How to Measure & Optimize — corewebvitals.io; gerçek RUM kıyaslamaları, iş etkisi vaka çalışmaları (Vodafone Italy) ve Google Flights fetchpriority sonucu.
• Largest Contentful Paint | MDN Web Docs — LargestContentfulPaint API’si, öğe türleri ve tarayıcı uyumluluğu için MDN referansı.

Alıntı yapmaya değer istatistikler

• LCP, geçilmesi en zor Core Web Vital’dır. En fazla bileşene sahiptir; bu yüzden siteler INP veya CLS’den daha çok LCP’de zorlanır. Kaynak
• Mobil, masaüstünden daha zordur. Daha yavaş CPU’lar ve bağlantılar LCP’yi yükseltir ve 3G/yavaş bağlantılarda 2,5 s eşiğine ulaşmak neredeyse imkânsızdır. Kaynak
• Görsel indirme süresi genellikle LCP’nin en küçük parçasıdır. Chrome’un HTTP Archive verileri analizi, indirme süresinin genellikle darboğaz olmadığını — genellikle TTFB ve keşif gecikmesinin olduğunu buldu. Kaynak
• CrUX kapsamı zayıftır. 42 milyon sayfalık çalışmamızda yalnızca ~%11,4’ünün ilişkili CrUX saha verisi vardı — çoğu sayfa ölçülecek kadar gerçek kullanıcı trafiği almıyor. Kaynak
• Mobil sayfaların %62’si, masaüstü sayfaların %74’ü İyi LCP elde ediyor (2025 Web Almanac). Mobil fark, daha yavaş CPU’ları ve ağ bağlantılarını yansıtır. Kaynak
• Mobil sayfaların yalnızca %2,1’i LCP görselini önceden yüklüyor, %76’sının LCP öğesi olarak bir görsele sahip olmasına rağmen — önemli bir kaçırılmış optimizasyon fırsatı (2025 Web Almanac). Kaynak
• fetchpriority="high" benimsenmesi 2022’de mobil sitelerin %0,03’ünden 2025’te %17,3’üne yükseldi, büyük ölçüde WordPress çekirdeğinin bunu eklemesiyle (2025 Web Almanac). Google Flights bu tek öznitelikle 700 ms’lik bir LCP iyileşmesi gördü. Kaynak

Videolar

• Google Search Central (YouTube) — Core Web Vitals ve sayfa deneyimi açıklayıcıları; Chrome ekibinin LCP optimizasyonu üzerine uygulamalı anlatımları dahil. Kanal

Değişiklik günlüğü