LCP (Largest Contentful Paint), bir web sayfasının görünür alanındaki en büyük içerik elementinin tarayıcı tarafından ekrana çizildiği anı ölçen bir performans metriğidir. Kullanıcı bir sayfayı açtığında, gözünün ilk gittiği büyük görsel, başlık veya metin bloğu ne kadar hızlı yüklenirse, sayfa o kadar hızlı “hazır” hissettirır. Google, bu algıyı ölçmek için LCP’yi Core Web Vitals setinin temel bileşenlerinden biri olarak belirlemiştir.

Bu rehberde LCP’nin teknik tanımından başlayarak hangi elementlerin ölçüme dahil edildiğine, eşik değerlerine, performansı etkileyen dört ana faktöre ve somut optimizasyon tekniklerine kadar her şeyi ele alacağız. Sayfanızın LCP skorunu iyileştirmek istiyorsanız doğru yerdesiniz.

LCP Nedir? Teknik Tanım ve Bağlam

Largest Contentful Paint, kullanıcının sayfayı navigasyonla açmasından itibaren görünür alan (viewport) içindeki en büyük içerik elementinin render edildiği zamana kadar geçen süreyi milisaniye cinsinden ifade eder. Tarayıcı, sayfa yüklenirken her yeni büyük element göründüğünde LCP değerini günceller; sayfa tamamen yüklendiğinde ya da kullanıcı bir etkileşimde bulunduğunda son LCP değeri sabitlenir.

LCP, web performansının algısal yük hızını ölçer. Teknik olarak ilk bayta kadar geçen süre (TTFB) veya DOM içeriğinin yüklenme süresi (DOMContentLoaded) gibi metrikler önemlidir; ancak bunların hiçbiri “kullanıcı sayfanın hazır olduğunu ne zaman hissetti?” sorusuna doğrudan yanıt vermez. LCP bu soruya en yakın cevabı üretir.

Google, LCP’yi 2020 yılında arama sıralama faktörlerine resmi olarak eklemiştir. Günümüzde hem mobil hem masaüstü sıralamalarını etkileyen bir sinyal olarak kullanılmaktadır. Teknik SEO hizmetleri kapsamında performans optimizasyonu yaparken LCP her zaman öncelikli inceleme noktasıdır.

Hangi Elementler LCP Olabilir?

Tarayıcı, LCP hesaplarken sayfadaki tüm elementleri değil yalnızca belirli element türlerini dikkate alır. Bu sınırlama, ölçümün anlamlı ve tutarlı olmasını sağlar.

`<img>` Elementleri

Sayfadaki standart resim etiketleri LCP adayıdır. Bir ürün fotoğrafı, blog kapak görseli veya hero bölümündeki büyük görsel genellikle sayfanın en büyük görsel elementi olduğundan çoğu sayfada LCP elementi <img> olur.

<!-- Tipik bir LCP adayı hero görseli -->
<img
  src="/images/hero-gorsel.webp"
  alt="Dijital pazarlama stratejisi sunum"
  width="1200"
  height="630"
/>

`<image>` ile `url()` Arka Plan Görselleri

CSS background-image: url() ile yüklenen görseller de LCP hesabına dahil edilir; ancak yalnızca görünür alanda ekrana çizilen kısmı değerlendirilir. Dikkat edilmesi gereken nokta: arka plan görselleri HTML’de değil CSS’te tanımlandığından tarayıcı bunları geç keşfeder ve bu da LCP süresini olumsuz etkiler.

`<video>` Poster Görseli

Video elementinin poster attribute’u ile belirtilen görsel, video yüklenene kadar placeholder olarak gösterilir. Bu görsel de LCP adayı sayılır.

<video
  poster="/images/video-kapak.jpg"
  controls
  preload="none"
>
  <source src="/video/tanitim.mp4" type="video/mp4" />
</video>

SVG İçindeki `<image>` Elementleri

<svg> etiketi içinde yer alan <image> elementleri LCP hesabına dahil edilebilir. Ancak satır içi SVG şekilleri (path, rect, circle gibi) LCP’ye dahil edilmez.

Block-Level Metin Elementleri

Görünür alandaki metin blokları da LCP adayı olabilir. <p>, <h1>, <h2> ve benzeri blok düzeyindeki elementlerin içindeki metin, görselden daha büyük bir alanı kaplıyorsa LCP elementi olur. Bu durum özellikle görsel kullanılmayan haber veya belge tarzı sayfalarda sık görülür.

LCP Olmayan Elementler

Aşağıdaki element türleri LCP hesabına dahil edilmez:

<svg> içindeki şekil elementleri (path, circle, rect)
<canvas> elementleri
opacity: 0 ile gizlenmiş elementler
visibility: hidden uygulanan elementler
Görünür alanın dışında kalan içerikler
Boyutu sıfır olan elementler

LCP Eşik Değerleri: İyi, Geliştir, Kötü

Google, LCP performansını üç kategoriye ayırır. Bu eşikler, alan verisi (field data) olan Chrome Kullanıcı Deneyimi Raporu’ndan elde edilen gerçek kullanıcı ölçümlerine dayanır.

Kategori	LCP Süresi	Kullanıcı Deneyimi
İyi	<2.5s	Hızlı, kullanıcı dostu
Geliştirme Gerekiyor	2.5s – 4s	Kabul edilebilir, iyileştirme önerilir
Kötü	>4s	Yavaş, yüksek terk oranı riski

Google’ın önerisi, sayfanın 75. persentil kullanıcı ölçümlerinin “İyi” kategorisinde kalmasıdır. Yani ziyaretçilerin en az yüzde yetmiş beşi sayfanızı 2.5 saniyenin altında yüklüyor olmalıdır.

Mobil ve masaüstü LCP değerleri ayrı ayrı ölçülür. Mobil bağlantılar genellikle daha yavaş olduğundan, mobil LCP skorları masaüstüne kıyasla daha çok dikkat gerektirir.

Cihaz	Tipik LCP Zorluğu	Öncelikli İyileştirme
Masaüstü	Görselin boyutu ve sunucu hızı	CDN, görsel sıkıştırma
Mobil	Ağ gecikmesi ve render-blocking kaynaklar	Preload, kritik CSS inline

LCP’yi Etkileyen 4 Temel Faktör

Google, LCP gecikmesini dört ana faktöre bağlar. Bu faktörlerin tümü bağımsız olmakla birlikte birbiriyle zincirleme etkileşime girer. Herhangi birindeki gecikme, sonraki adımları da erteleyerek LCP süresini uzatır.

1. Sunucu Yanıt Süresi (TTFB)

TTFB (Time to First Byte), tarayıcının sunucuya istek gönderdiği andan ilk byte’ı aldığı ana kadar geçen süredir. LCP zincirinin ilk halkasıdır; TTFB yüksekse diğer tüm adımlar da gecikmeli başlar.

TTFB’yi artıran başlıca nedenler:

Coğrafi mesafe: Sunucu Almanya’daysa İstanbul’dan yapılan istekler daha uzun sürer.
Sunucu işlem süresi: Dinamik sayfalarda veritabanı sorguları, şablon render süreleri eklendiğinde TTFB uzar.
Önbellek yokluğu: Her isteğin yeniden işlendiği uncached sayfalarda gecikme artar.
Yetersiz hosting: Paylaşımlı hosting ortamlarında kaynak rekabeti TTFB’yi olumsuz etkiler.

Hedef: TTFB <800ms olmalıdır.

2. Render-Blocking Kaynaklar

Tarayıcı, HTML’yi parse ederek sayfa ağacını (DOM) oluşturur. Bu süreçte <head> bölümündeki <script> ve <link rel="stylesheet"> etiketleri tarayıcıyı durdurur: kaynaklar indirilip işlenene kadar sayfa render edilemez. Bu duruma “render-blocking” denir.

<!-- Render-blocking örnek: tarayıcı bu satırda bekler -->
<link rel="stylesheet" href="/styles/main.css" />
<script src="/scripts/analytics.js"></script>

Render-blocking süresi uzadıkça tarayıcı LCP elementini ekrana çizmek için beklemek zorunda kalır. Bu gecikme doğrudan LCP metriğine yansır.

3. Kaynak Yükleme Süresi

LCP elementi tarayıcı tarafından keşfedildikten sonra sunucudan indirilmesi gerekir. Bu süre; görsel boyutu, görsel formatı, CDN kullanımı, HTTP/2 veya HTTP/3 desteği ve ağ hızı gibi etkenlere bağlıdır.

Büyük bir JPEG görsel, aynı içeriğin WebP veya AVIF versiyonuna kıyasla çok daha uzun süre ağ üzerinden aktarılır. Görsel, CDN yerine uzak bir kaynak sunucudan çekiliyorsa aktarım gecikmesi daha da artar.

4. Client-Side Rendering Gecikmesi

React, Vue, Angular gibi JavaScript framework’leri ile oluşturulan sayfalarda içerik, JavaScript çalıştırılmadan önce ekrana çizilmez. Sunucudan gelen HTML neredeyse boştur; gerçek içerik JavaScript tarafından DOM’a eklenir.

Bu mimari, LCP elementinin tarayıcıya HTML içinde gönderilmediği anlamına gelir. Tarayıcı önce JavaScript’i indirmeli, parse etmeli, çalıştırmalı ve ardından DOM’u oluşturmalıdır. Bu zincir, LCP süresini ciddi ölçüde uzatabilir.

Çözüm yolları: Sunucu Taraflı Render (SSR), Statik Site Üretimi (SSG) veya en azından LCP elementinin içeriğinin sunucudan önceden işlenmiş HTML olarak gönderilmesidir.

LCP Optimizasyon Teknikleri

Teorik çerçeveyi anladıktan sonra sıra somut iyileştirmelere gelir. Aşağıdaki teknikler, LCP üzerinde en yüksek etkiyi yaratan yöntemlerdir.

CDN Kullanımı

İçerik Dağıtım Ağı (CDN), statik varlıklarınızı dünya genelindeki sunuculara dağıtarak kullanıcılara en yakın konumdan sunar. İstanbul’daki bir kullanıcı, Almanya’daki origin sunucu yerine İstanbul veya Frankfurt CDN node’undan içeriği alır. Bu tek adım TTFB’yi onlarca ila yüzlerce milisaniye kısaltabilir.

CDN seçerken dikkat edilecekler:

Edge konumlarının hedef kitlenize yakınlığı
HTTP/3 ve QUIC protokol desteği
Görsel optimizasyonu (otomatik WebP dönüşümü, boyutlandırma)
Önbellekleme kurallarının esnekliği

Cloudflare, Fastly, AWS CloudFront ve BunnyCDN yaygın tercihlerdir. Astro veya Next.js gibi framework’lerde Vercel Edge Network ya da Netlify Edge de benzer işlevi üstlenir.

Resource Hints: Preload, Preconnect, Prefetch

Tarayıcıya hangi kaynakların kritik olduğunu önceden bildirerek yükleme önceliğini yönetebilirsiniz.

`preload` — LCP Görselini Erkenden Keşfettirin

preload, tarayıcıya “bu kaynağa ihtiyacın olacak, şimdiden indir” mesajı verir. LCP görseli için kullanılması en güçlü tekniklerden biridir çünkü tarayıcı HTML’yi parse ederken görsellerle genellikle geç karşılaşır.

<head>
  <!-- LCP görselini en yüksek öncelikle yükle -->
  <link
    rel="preload"
    as="image"
    href="/images/hero-gorsel.webp"
    type="image/webp"
  />
</head>

Responsive görsel kullanıyorsanız imagesrcset ve imagesizes attribute’larını eklemeyi unutmayın:

<link
  rel="preload"
  as="image"
  href="/images/hero-gorsel.webp"
  imagesrcset="/images/hero-gorsel-480w.webp 480w,
               /images/hero-gorsel-800w.webp 800w,
               /images/hero-gorsel-1200w.webp 1200w"
  imagesizes="(max-width: 600px) 480px,
              (max-width: 1024px) 800px,
              1200px"
/>

`preconnect` — Üçüncü Taraf Bağlantılarını Hızlandırın

CDN, font sunucusu veya API gibi harici alan adlarına önceden TCP bağlantısı kurarak DNS çözümleme, TLS el sıkışması ve bağlantı kurma sürelerini gizleyin.

<head>
  <!-- Google Fonts için erken bağlantı -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

  <!-- CDN kaynağına erken bağlantı -->
  <link rel="preconnect" href="https://cdn.siteniz.com" />
</head>

preconnect, dns-prefetch’ten daha güçlüdür çünkü DNS çözümlemesinin ötesinde tam TCP/TLS el sıkışmasını tamamlar. Ancak aktif bağlantı tutmak kaynak tükettiğinden en fazla iki ila üç kritik üçüncü taraf için kullanın.

`prefetch` — Sonraki Sayfa İçin Hazırlan

prefetch, kullanıcının büyük olasılıkla ziyaret edeceği bir sonraki sayfanın kaynaklarını düşük öncelikli olarak önceden indirir. LCP’yi doğrudan etkilemez; ancak sonraki sayfa geçişlerini hızlandırır.

<!-- Kullanıcının büyük olasılıkla tıklayacağı sayfa -->
<link rel="prefetch" href="/blog/core-web-vitals-rehberi" />

AVIF ve WebP: Modern Görsel Formatları

Görsel formatı seçimi, kaynak yükleme süresini doğrudan etkiler. Aynı görsel kalitesinde modern formatlar çok daha küçük dosya boyutu üretir.

Format	Tarayıcı Desteği	Ortalama Boyut Kazanımı
JPEG (referans)	Evrensel	—
WebP	>95%	JPEG’den %25-35 küçük
AVIF	>90%	JPEG’den %40-55 küçük

AVIF, WebP’ye kıyasla çok daha iyi sıkıştırma sunar; ancak encode süresi uzundur. Bu nedenle build zamanında dönüşüm yapmak veya CDN düzeyinde dönüşümü tercih etmek en pratik yaklaşımdır.

<picture> elementi ile tarayıcı desteğini kontrol ederek en iyi formatı sunun:

<picture>
  <source
    srcset="/images/hero-gorsel.avif"
    type="image/avif"
  />
  <source
    srcset="/images/hero-gorsel.webp"
    type="image/webp"
  />
  <img
    src="/images/hero-gorsel.jpg"
    alt="Dijital pazarlama stratejisi sunum"
    width="1200"
    height="630"
    fetchpriority="high"
  />
</picture>

Bu yapıda AVIF destekleyen tarayıcılar AVIF, WebP destekleyenler WebP, diğerleri JPEG alır.

Kritik CSS’i Inline Eklemek

Harici bir CSS dosyasına bağlantı vermek render-blocking yaratır. Çözüm: sayfanın başında görünür olan içerik (above-the-fold) için gerekli CSS stillerini doğrudan <style> etiketi içine yerleştirmek, kapsamlı CSS dosyasını ise asenkron yüklemektir.

<head>
  <!-- Kritik CSS: inline -->
  <style>
    /* Hero bölümü, navigasyon, üst kısım stilleri */
    body { margin: 0; font-family: system-ui, sans-serif; }
    .hero { display: flex; align-items: center; min-height: 60vh; }
    .hero__img { width: 100%; max-width: 1200px; height: auto; }
    .nav { display: flex; justify-content: space-between; padding: 1rem 2rem; }
  </style>

  <!-- Geri kalan CSS: asenkron yükleme -->
  <link
    rel="stylesheet"
    href="/styles/main.css"
    media="print"
    onload="this.media='all'"
  />
  <noscript>
    <link rel="stylesheet" href="/styles/main.css" />
  </noscript>
</head>

media="print" tekniği, tarayıcının CSS dosyasını render-blocking olmadan indirmesini sağlar. onload tetiklendiğinde media değeri all olarak güncellenir ve stiller uygulanır.

Hangi CSS’in kritik olduğunu belirlemek için Puppeteer tabanlı araçlar (Critical, Penthouse) veya Chrome DevTools’daki “Coverage” sekmesi kullanılabilir.

`fetchpriority="high"` ile Yükleme Önceliğini Artırın

HTML’de yükleme önceliğini açıkça belirtmek için fetchpriority attribute’u kullanılır. Bu özellik, tarayıcının kaynak tahmin mekanizmasını (Priority Hints) devreye sokar.

<!-- LCP görseline yüksek öncelik ver -->
<img
  src="/images/hero-gorsel.webp"
  alt="Ana sayfa hero görseli"
  width="1200"
  height="630"
  fetchpriority="high"
/>

<!-- Önemsiz görselde önceliği düşür -->
<img
  src="/images/dekoratif-arka-plan.webp"
  alt=""
  width="800"
  height="400"
  fetchpriority="low"
  loading="lazy"
/>

fetchpriority="high" özellikle şu senaryolarda kritik öneme sahiptir:

LCP elementi bir carousel’in ilk slaydındaysa
Görsel preload ile önceden yüklense bile render önceliği fetchpriority ile güçlendirilmelidir
<link rel="preload"> ile birlikte kullanıldığında en iyi sonucu verir

Tarayıcı desteği: Chromium tabanlı tarayıcılarda tam destek, Firefox’ta kısmi destek (115+), Safari’de güncel sürümlerde mevcuttur.

Lazy Loading’in Yanlış Kullanımı: En Sık Yapılan Hata

loading="lazy" attribute’u, görünür alanın dışındaki görsellerin sayfa yüklenirken indirilmesini erteler. Bu kesinlikle doğru bir optimizasyondur; ancak yanlış element üzerinde uygulandığında LCP’yi ciddi ölçüde bozar.

Yanlış Kullanım

<!-- YANLIŞ: LCP görseline lazy loading uygulamak -->
<img
  src="/images/hero-gorsel.webp"
  alt="Hero görseli"
  loading="lazy"
/>

Bu kod, tarayıcıya “bu görseli şimdi indirme, gerektiğinde indir” mesajı verir. Oysa hero görseli sayfa açıldığında zaten görünür alanda olduğundan, lazy loading yalnızca yüklemeyi geciktirir ve LCP süresini artırır.

Doğru Kullanım

<!-- DOĞRU: LCP görseli — lazy loading yok, fetchpriority yüksek -->
<img
  src="/images/hero-gorsel.webp"
  alt="Hero görseli"
  width="1200"
  height="630"
  fetchpriority="high"
/>

<!-- DOĞRU: Sayfa altındaki görseller — lazy loading uygun -->
<img
  src="/images/blog-kapak-2.webp"
  alt="Blog yazısı kapak görseli"
  width="600"
  height="400"
  loading="lazy"
/>

Kural: Sayfa açıldığında görünür alanda olan tüm görsellere loading="lazy" eklemeyin. Viewport’un ilk katında kalan her görsel, loading="eager" (varsayılan) ile yüklenmelidir.

Font Optimizasyonu ve LCP

Metin bir LCP elementi olduğunda, fontların yüklenme hızı LCP süresini doğrudan etkiler. Tarayıcı fontu indirinceye kadar metni göstermeyebilir (FOIT — Flash of Invisible Text), bu da LCP elementinin geç render edilmesine yol açar.

`font-display: swap` Kullanın

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-regular.woff2') format('woff2');
  font-display: swap; /* Sistem fontu göster, Inter hazır olunca değiştir */
}

font-display: swap, sistem fontunu hemen göstererek kullanıcının boş ekranla beklememesini sağlar. LCP elementi metin ise bu sayede tarayıcı elementı sisteme fontuyla hızla render edebilir.

Fontları `preload` ile Erken Yükleyin

<link
  rel="preload"
  as="font"
  href="/fonts/inter-regular.woff2"
  type="font/woff2"
  crossorigin
/>

crossorigin attribute zorunludur; aksi hâlde tarayıcı fontu iki kez indirir.

Sunucu Taraflı Render ve Statik Site Üretimi

Client-side rendering kullanan uygulamalarda LCP, JavaScript bundle boyutu ve çalışma süresiyle doğrudan ilişkilidir. Bu mimariden kaynaklanan LCP sorunlarına yönelik temel çözümler:

Statik Site Üretimi (SSG): Build zamanında tam HTML üretilir. Sunucu yalnızca statik dosyaları servis eder; JavaScript işlem süresi LCP’yi etkilemez. Astro, Next.js (static export), Eleventy bu modeli destekler.

Sunucu Taraflı Render (SSR): Her istek için sunucu HTML’yi dinamik olarak üretir. İlk HTML tam içeriklidir; tarayıcı JavaScript’i beklemeden LCP elementini render edebilir.

Partial Hydration: Astro gibi framework’lerin sunduğu bu yaklaşımda yalnızca etkileşimli bileşenler client-side JavaScript alır. LCP elementini içeren statik bölümler saf HTML olarak gönderilir.

LCP Ölçüm Araçları

LCP değerlerinizi doğru analiz etmek için hem laboratuvar (lab) hem alan (field) verilerini kullanmak gerekir.

Google PageSpeed Insights

PageSpeed Insights, hem Chrome Kullanıcı Deneyimi Raporu’ndan (CrUX) alınan gerçek kullanıcı verisini (field data) hem de Lighthouse motoruyla yapılan simülasyon ölçümünü (lab data) yan yana sunar. En hızlı başlangıç noktasıdır; URL girerek anında LCP değerini ve LCP elementini öğrenebilirsiniz.

Google Search Console

Search Console’daki Core Web Vitals raporu, sitenizin tüm URL’leri için alan verisi sağlar. Hangi URL gruplarının “İyi”, “Geliştirme Gerekiyor” veya “Kötü” kategorisinde olduğunu gösterir. LCP optimizasyon çalışmalarının gerçek etkisini değerlendirmek için 28 günlük periyotlar karşılaştırılabilir.

Chrome DevTools — Performance Paneli

Chrome DevTools Performance paneli, sayfa yükleme sürecinin her adımını görsel olarak kaydeder. LCP olayı bir belirleyici (marker) ile işaretlenir; hangi elementin LCP olduğunu, ne zaman keşfedildiğini ve ne zaman render edildiğini milisaniye hassasiyetiyle görebilirsiniz.

DevTools’u açın (F12)
Performance sekmesine geçin
Sayfa yenileme kaydı başlatın (Ctrl+Shift+R)
Kaydı durdurun; “LCP” etiketini zaman çizelgesinde bulun

Chrome DevTools — Network Paneli

Network panelinde LCP görseli için “Waterfall” görünümüne bakarak şunları analiz edin:

Tarayıcı görseli ne zaman keşfetti?
İndirme ne zaman başladı?
Ne kadar sürdü?
Sıraya alınma (queuing) gecikmesi var mıydı?

Lighthouse CLI

CI/CD pipeline’larına entegre ederek her deploy öncesi LCP performansını otomatik ölçebilirsiniz:

# Lighthouse CLI kurulumu
npm install -g lighthouse

# URL için LCP dahil tüm metrikleri ölç
lighthouse https://siteniz.com \
  --output json \
  --output-path ./lighthouse-rapor.json \
  --only-categories=performance

web-vitals JavaScript Kütüphanesi

Gerçek kullanıcıların LCP deneyimini kendi analitiğinize gönderebilirsiniz:

import { onLCP } from 'web-vitals';

onLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Elementi:', metric.entries[0]?.element);

  // Kendi analitik servisinize gönderin
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify({
      metric: 'LCP',
      value: metric.value,
      url: window.location.href,
    }),
  });
});

Bu yaklaşım, tüm ziyaretçilerin gerçek bağlantı hızları, cihaz performansları ve coğrafi konumlarına göre LCP dağılımını izlemenizi sağlar.

CrUX (Chrome User Experience Report)

Google’ın BigQuery üzerinden sunduğu CrUX veri seti, Google tarafından toplanan gerçek kullanıcı performans verilerini içerir. Alan adı veya URL bazında LCP dağılımını sorgulamak için kullanılabilir:

SELECT
  p75_lcp,
  fast_lcp,
  avg_lcp,
  slow_lcp
FROM
  `chrome-ux-report.materialized.device_summary`
WHERE
  origin = 'https://siteniz.com'
  AND yyyymm = 202606

LCP Alt Bileşenleri: Gecikmenin Kaynağını Bulmak

Google, Lighthouse 10 ve üzeri sürümlerde LCP süresini dört alt bileşene bölerek hangi aşamanın ne kadar sürdüğünü görünür hâle getirir. Bu ayrıştırma, optimizasyon çalışmalarını doğru hedefe yönlendirmeyi kolaylaştırır.

TTFB (Time to First Byte)

Navigasyon başlangıcından sunucunun ilk byte’ı tarayıcıya ulaştırdığı ana kadar geçen süredir. DNS çözümleme, TCP/TLS el sıkışması ve sunucu işlem süresi bu aşamaya dahildir. Hedef: <800ms.

Kaynak Yükleme Gecikmesi (Resource Load Delay)

Tarayıcının ilk byte’ı aldığı andan LCP kaynağının (genellikle görsel) indirilmeye başladığı ana kadar geçen süredir. Bu gecikme, LCP elementinin HTML’de geç konumlandırılmasından, render-blocking kaynaklardan veya discovery gecikmesinden kaynaklanır. İdeal: <200ms.

Kaynak Yükleme Süresi (Resource Load Time)

LCP kaynağının ağ üzerinden indirilmesi için gereken süredir. Görsel boyutu ve formatı, CDN performansı ve ağ hızı bu aşamayı belirler. AVIF/WebP formatına geçiş ve CDN kullanımı bu süreyi doğrudan etkiler.

Render Gecikmesi (Element Render Delay)

Kaynağın tamamen indirildiği andan tarayıcının elementi ekrana çizdiği ana kadar geçen süredir. Genellikle kısadır; ancak main thread’in JavaScript veya uzun görevlerle meşgul olması bu aşamayı uzatabilir. İdeal: <50ms.

LCP Süresi = TTFB + Kaynak Yükleme Gecikmesi + Kaynak Yükleme Süresi + Render Gecikmesi

Bu formülü gerçek bir örneğe uyguladığımızda:

Aşama	İyi Değer	Sık Görülen Sorun
TTFB	<800ms	Uzak sunucu, önbellek yok
Kaynak Yükleme Gecikmesi	<200ms	Preload eksik, geç discovery
Kaynak Yükleme Süresi	<1000ms	Büyük JPEG, origin sunucu
Render Gecikmesi	<50ms	Uzun JS görevleri

Lighthouse performans raporunda “LCP Breakdown” bölümü bu dört aşamayı görsel olarak gösterir ve en uzun aşamayı vurgular. Hangi aşamanın dominant olduğunu tespit etmeden yapılan optimizasyonlar hedefsiz kalabilir.

Dinamik LCP Elementleri: Carousel ve Slider Tuzağı

Hero bölümünde slider veya carousel kullanan siteler özel bir LCP sorunuyla karşılaşır. Carousel’in ilk slaydı genellikle LCP elementi olur; ancak slider JavaScript tarafından kontrol ediliyorsa görselin gerçek anlamda render edilmesi gecikebilir.

Sorun

<!-- Slider JS yüklenene kadar görünmez kalan hero -->
<div class="slider" style="display:none;">
  <img src="/images/slide-1.webp" alt="İlk slayt" />
</div>
<script src="/js/slider.min.js" defer></script>

Bu yapıda display:none olan element LCP hesabına girmez. JavaScript çalışana ve slider görünür hâle gelene kadar LCP ötelenir.

Çözüm

İlk slider görselini JavaScript bağımsız görünür yapın ve LCP’ye dahil edin:

<!-- İlk slayt: her zaman görünür, fetchpriority yüksek -->
<div class="slider">
  <img
    src="/images/slide-1.webp"
    alt="İlk slayt"
    width="1200"
    height="600"
    fetchpriority="high"
    class="slider__first-slide"
  />
  <!-- Diğer slaytlar JS ile yüklenir -->
</div>
<script src="/js/slider.min.js" defer></script>

İlk görsel her zaman görünür ve yüksek öncelikle yüklenir; diğer slaytlar JS hazır olduğunda dinamik olarak eklenir.

LCP ve Diğer Core Web Vitals İlişkisi

LCP tek başına bir performans göstergesi olarak önemlidir; ancak diğer Core Web Vitals metrikleriyle birlikte değerlendirilmesi daha kapsamlı bir tablo sunar.

INP (Interaction to Next Paint) kullanıcı etkileşimlerine verilen yanıt hızını ölçer. JavaScript bloğu uzun çalışıyorsa hem INP hem LCP bozulur; çünkü main thread meşgulse tarayıcı LCP elementini de render edemeyebilir.

CLS (Cumulative Layout Shift) görsel kararlılığı ölçer. Boyutsuz görseller sayfada yer değiştirmeye yol açar. Üstelik CLS ve LCP birbirine bağlıdır: LCP elementi yüklenirken boyut değişirse hem CLS skoru hem de LCP zamanı olumsuz etkilenebilir.

Bu nedenle <img> elementlerine her zaman width ve height attribute’u eklemek LCP optimizasyonunun yanı sıra CLS’yi de iyileştirir:

<!-- Hem LCP hem CLS için doğru yaklaşım -->
<img
  src="/images/urun-fotografi.webp"
  alt="Ürün fotoğrafı"
  width="800"
  height="600"
  fetchpriority="high"
/>

Gerçek Dünyadan LCP Senaryoları ve Çözümleri

Senaryo 1: E-Ticaret Ürün Sayfası

Bir e-ticaret ürün sayfasında LCP elementi tipik olarak ürünün ana fotoğrafıdır. En sık karşılaşılan sorun, ürün görsellerinin sunucu taraflı render yerine client-side JavaScript ile yüklenmesidir. Kullanıcı sayfayı açtığında önce bir skeleton görünür; ürün görseli JavaScript API yanıtı geldikten sonra DOM’a eklenir.

Bu durumda çözüm, ürün görselini <noscript> içinde bile olsa SSR ile HTML’ye dahil etmek ya da görseli JavaScript’in yanı sıra <meta property="og:image"> benzeri önbellek mekanizmaları aracılığıyla önceden yüklemektir.

<!-- Ürün görseli SSR ile HTML'de mevcut -->
<img
  src="/urunler/beyaz-sneaker-800w.avif"
  srcset="
    /urunler/beyaz-sneaker-480w.avif 480w,
    /urunler/beyaz-sneaker-800w.avif 800w
  "
  sizes="(max-width: 600px) 480px, 800px"
  alt="Nike Air Max 270 beyaz erkek spor ayakkabı"
  width="800"
  height="800"
  fetchpriority="high"
/>

Senaryo 2: Blog veya Haber Sitesi

Blog ve haber sitelerinde LCP elementi çoğunlukla kapak görseli ya da büyük bir <h1> metnidir. Kapak görseli varsa AVIF formatı ve preload kullanımı önceliklidir. LCP elementi metin ise font yüklenme hızı belirleyicidir.

Haber sitelerinin sık yaptığı hata, bant genişliğini korumak amacıyla tüm görsellere loading="lazy" eklemektir. Her post listesindeki kapak görselinin lazy yüklenmesi makul görünse de makale sayfasının en üstündeki ana görsele loading="lazy" eklenmesi LCP’yi bozar.

Senaryo 3: Landing Page (Açılış Sayfası)

Açılış sayfalarında genellikle büyük bir hero görseli veya arka plan videosu bulunur. Video poster görseli LCP adayıdır; ancak video kendisi değil yalnızca poster görseli ölçülür. Bu nedenle:

<video
  poster="/images/hero-poster.avif"
  autoplay
  muted
  loop
  playsinline
  preload="none"
>
  <source src="/video/hero.mp4" type="video/mp4" />
</video>

preload="none" video dosyasının sayfa yüklenirken indirilmesini engeller ve bant genişliği tasarrufu sağlar. Poster görseli ise ayrıca preload ile yüklenebilir:

<link rel="preload" as="image" href="/images/hero-poster.avif" type="image/avif" />

LCP Optimizasyon Kontrol Listesi

Aşağıdaki adımları sırayla uygulayarak LCP sürenizi sistematik biçimde iyileştirebilirsiniz.

Sunucu ve Ağ Katmanı

TTFB değerini ölçün; 800ms üzerindeyse CDN veya sunucu iyileştirmesi yapın
Statik varlıklar için CDN aktif edin
HTTP/2 veya HTTP/3 desteğini doğrulayın
Sunucu önbelleğini yapılandırın (Cache-Control, ETags)
GZIP veya Brotli sıkıştırmayı etkinleştirin

HTML Baş Bölümü

LCP görseli için <link rel="preload" as="image"> ekleyin
Üçüncü taraf kaynakları için <link rel="preconnect"> ekleyin
Kritik CSS’i <style> olarak inline edin
Render-blocking scriptleri defer veya async yapın

Görsel Optimizasyonu

LCP görselini AVIF veya WebP formatına çevirin
<picture> elementi ile format fallback sağlayın
Görsel boyutunu gerçek kullanım alanıyla eşleştirin (oversized görselden kaçının)
fetchpriority="high" ekleyin
Viewport içindeki görsellere loading="lazy" eklemeyin
width ve height attribute’larını her zaman yazın

Metin ve Font

LCP elementı metinse font-display: swap kullanın
Kritik fontları <link rel="preload" as="font"> ile yükleyin
Sistem fontuna fallback tanımlayın
Gereksiz font varyantlarını yüklemekten kaçının

JavaScript ve Render

Client-side rendering varsa SSR veya SSG’ye geçiş değerlendirin
Main thread’i bloklayan uzun görevleri (long tasks) parçalara bölün
Third-party scriptleri defer ile yükleyin
JavaScript bundle boyutunu code splitting ile küçültün

Sonuç

LCP, kullanıcının bir sayfayı “yüklendi” olarak algıladığı kritik anı ölçer ve Google’ın arama sıralamalarında doğrudan bir sinyal olarak kullandığı Core Web Vitals metriklerinden biridir. 2.5 saniye altında tutmak, hem kullanıcı deneyimini güçlendirir hem de organik görünürlüğü korur.

LCP optimizasyonu tek bir teknikle değil, birbiriyle bağlantılı iyileştirmelerin bütünüyle sağlanır: CDN ile sunucu gecikmesini azaltmak, preload ile görseli erken keşfettirmek, AVIF/WebP ile dosya boyutunu küçültmek, kritik CSS’i inline ederek render bloğunu kaldırmak ve fetchpriority="high" ile tarayıcı önceliğini açıkça yönlendirmek. Bu adımların her biri birkaç yüz milisaniyeyi kurtarır; birlikte uygulandığında etki kümülatif olarak güçlenir.

Sayfanızın LCP performansını profesyonel bir gözle analiz etmek ve teknik SEO altyapınızı güçlendirmek için teknik SEO hizmetlerimizi inceleyebilirsiniz. Core Web Vitals’ın diğer bileşenleri olan CLS ve INP hakkında da kapsamlı bilgi edinmek istiyorsanız Core Web Vitals rehberimizi okumanızı öneririz.