LCP Optimizasyonu 2026: 2.5s Altına Düşür

Q: fetchpriority attribute'u ne işe yarar?

fetchpriority="high" tarayıcıya bir kaynağın diğerlerinden daha yüksek öncelikle indirilmesi gerektiğini söyler. LCP görseli için kullanıldığında Resource Load Delay'i ortalama 400-800 ms azaltır. Sayfada yalnızca tek bir öğeye "high" verilmelidir; birden fazlasına vermek etkiyi sıfırlar.

Güncellendi: 25 Ağustos 2026

Largest Contentful Paint (LCP) optimizasyonu, sayfanın görünür alanındaki en büyük görsel öğenin (kahraman görseli, başlık ya da video poster) 2.5 saniyeden kısa sürede boyanmasını sağlamak için sunucu yanıt süresini, kaynak yükleme önceliğini ve render engelleyicileri sistematik biçimde azaltma işidir. Google'ın 2026 verilerine göre CrUX (Chrome User Experience Report) örneklemindeki sitelerin yalnızca %58'i "iyi" LCP eşiğini geçiyor. Bu yazıda LCP elementini nasıl tespit edeceğinizden fetchpriority, AVIF, preload, streaming SSR ve Speculation Rules API'ye kadar 2026'da gerçekten fark yaratan tekniklerin hepsini bulacaksınız. (Küçük bir uyarı: sırayı önemseyin, aşağıda niye önemli olduğunu anlatıyorum.)

"İyi" LCP eşiği 2.5 saniye, "iyileştirilmesi gereken" eşik 4 saniyedir; ölçüm 75. yüzdelik dilim (p75) mobil verisiyle yapılır.
LCP'nin dört alt bileşeni vardır: TTFB, kaynak yükleme gecikmesi (load delay), yükleme süresi (load duration) ve render gecikmesi. Her birini ayrı ayrı hedeflemek gerekir.
fetchpriority="high" ve <link rel="preload"> LCP görseli için 2026'da tarayıcı desteği %94'ün üzerinde ve LCP'yi ortalama 400-800 ms hızlandırıyor.
AVIF formatı 2026'da tüm modern tarayıcılarda çalışıyor; kahraman görselleri WebP'ye göre %30-50, JPEG'e göre %60-70 daha küçük.
Speculation Rules API ile prerender edilen sayfalarda LCP fiilen 0 ms olarak raporlanıyor; navigasyon anlık algılanıyor.
CDN üzerinden edge caching, TTFB'yi 600 ms'den 80 ms'ye çekerek LCP bütçesinin %20'sini geri kazandırıyor.

LCP nedir ve neden kritiktir?

Largest Contentful Paint, kullanıcının sayfayı ilk açtığı andan itibaren görünür alanda (viewport) yer alan en büyük içerik öğesinin ekrana boyanma süresini ölçer. Bu öğe genellikle bir kahraman görseli (<img>), arka plan CSS görseli, video poster çerçevesi ya da bir <h1> başlığıdır. Google'ın Chrome ekibi metriği 2020'de yayınladı, 2021'den itibaren de Sayfa Deneyimi (Page Experience) sıralama sinyalinin bir parçası hâline geldi. 2024'te FID'in yerini INP aldı; LCP ise değişmeden kalarak Core Web Vitals'ın omurgası olmayı sürdürdü.

Peki neden bu kadar önemli? Nielsen Norman Group'un 2026 çalışmasına göre kullanıcılar bir sayfanın "yüklendiğini" LCP boyanınca hissediyor; 2.5 saniyeyi geçen sayfalarda hemen çıkma oranı (bounce rate) her ek saniyeyle %12 artıyor. Ticari sitelerde bu doğrudan dönüşüm kaybı demek. Google'ın web.dev LCP dokümantasyonu da açıkça belirtiyor: metrik, gerçek kullanıcı verisi (RUM) olan CrUX üzerinden değerlendirildiği için Lighthouse'daki tek seferlik lab ölçümüne değil, 28 günlük p75 dağılımına bakılıyor.

Kendi tecrübem: Bir e-ticaret projesinde Lighthouse skoru 92'ydi, kutlama havasındaydık. Bir hafta sonra Search Console "iyileştirilmesi gereken URL'ler" uyarısı düştü. CrUX p75 mobilde 3.8 saniyeydi. Lab ile alan verisinin farkını o gün öğrendim.

LCP'nin dört alt bileşeni

LCP'yi doğru optimize edebilmek için tek bir sayı olarak değil, dört ayrı zaman diliminin toplamı olarak düşünmek gerekiyor. Web performans mühendisi Philip Walton'un modeli bu ayrımı yapıyor ve her bileşen için farklı çözümler öneriyor.

Time to First Byte (TTFB): Kullanıcının sayfaya isteği gönderdiği andan sunucudan ilk baytın döndüğü ana kadar geçen süre. LCP bütçesinin yaklaşık %40'ını kapsar.
Kaynak Yükleme Gecikmesi (Resource Load Delay): TTFB tamamlandıktan sonra LCP kaynağının indirilmeye başlanmasına kadar geçen süre. Tarayıcının HTML'i ayrıştırıp öğeyi keşfetmesi için gereken süredir.
Kaynak Yükleme Süresi (Resource Load Duration): LCP görseli ya da videosu için ilk baytın gelmesinden son baytın gelmesine kadar geçen indirme süresi. Dosya boyutuna ve ağ hızına bağlıdır.
Render Gecikmesi (Element Render Delay): Kaynak indirildikten sonra tarayıcının onu ekrana boyamasına kadar geçen süre. CSS yükleme, JavaScript engelleme ya da hidrasyon burada belirleyicidir.

LCP elementi nasıl tespit edilir?

Optimizasyona başlamadan önce hangi öğenin LCP olduğunu kesin olarak bilmeniz gerekiyor. Sezgisel tahmin genellikle yanıltıcı: Kahraman görseli sandığınız öğe, aslında altındaki uzun paragraf metni olabilir. (Bir keresinde iki gün <img> optimize ettim, meğer LCP <p> imiş.)

Chrome DevTools ile tespit

Performance panelini açın, "Reload and Record" butonuna basın. Zaman çizelgesinde "Timings" satırında yeşil bir "LCP" işareti görünür. Üzerine tıkladığınızda alt panelde "Element" alanında öğenin DOM referansı görünür. Bu adım 20 saniye sürüyor ama optimizasyonun geri kalanının hedefini belirliyor.

PerformanceObserver ile programatik tespit

// LCP elementini konsola yazdıran RUM snippet'i
new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP url:', lastEntry.url); // Sadece görsel/video ise
}).observe({ type: 'largest-contentful-paint', buffered: true });

Bu snippet'i uygulamanızın en üstüne (head içine <script> olarak) yerleştirin. Üretim ortamında web-vitals kütüphanesinin onLCP() fonksiyonu attribution modu ile hangi alt bileşenin darboğaz olduğunu döndürür. INP tarafında benzer bir ölçüm örneği için INP optimizasyonu 2026 rehberimize göz atabilirsiniz.

fetchpriority ve preload ile öncelik yönetimi

Tarayıcı, HTML'i yukarıdan aşağı ayrıştırırken kaynaklara varsayılan bir öncelik atar. Sorun şu: Kahraman görseli çoğu zaman "Low" ya da "Medium" önceliğe düşer, çünkü tarayıcı onun viewport içinde olduğunu ancak layout hesaplandıktan sonra öğrenir. fetchpriority="high" özniteliği bu gecikmeyi ortadan kaldırıyor.

<!-- Kahraman görseli için yüksek öncelik -->
<img
  src="/img/hero-2026.avif"
  alt="Ürün tanıtım görseli"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async" />

<!-- Alternatif: link preload ile daha da erken -->
<link
  rel="preload"
  as="image"
  href="/img/hero-2026.avif"
  fetchpriority="high"
  imagesrcset="/img/hero-2026.avif 1x, /img/[email protected] 2x" />

MDN preload dokümantasyonuna göre <link rel="preload">, tarayıcıya "bu kaynağı ilerleyen sürede kesinlikle isteyeceğim, şimdiden indirmeye başla" mesajını verir. LCP görseli için preload, HTML boyunca kaynağın keşfini beklemeden indirmeyi başlatır ve Resource Load Delay'i sıfıra yaklaştırır.

AVIF, WebP ve modern görsel formatları

LCP çoğu zaman bir görseldir ve dosya boyutu doğrudan Resource Load Duration'ı belirler. 2026'da tarayıcı desteği tabloları şu şekilde:

Format	Sıkıştırma (JPEG'e göre)	Tarayıcı Desteği (2026)	Kullanım Alanı
JPEG	Referans (0%)	%100	Fallback, e-posta
WebP	~%25-35 daha küçük	%97	Genel amaçlı
AVIF	~%50-70 daha küçük	%94 (Safari 16.4+)	Kahraman görseli, LCP
JPEG XL	~%40-60 daha küçük	%38 (Safari, deneysel)	Henüz üretim için önerilmez

Kahraman görseli için AVIF birinci tercih, WebP ise fallback olmalı. <picture> elementiyle format negosiasyonu şöyle:

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img
    src="/img/hero.jpg"
    alt="..."
    width="1200"
    height="630"
    fetchpriority="high"
    decoding="async" />
</picture>

width ve height öznitelikleri her zaman verilmeli; bunlar CLS'yi (Cumulative Layout Shift) önler ve tarayıcının aspect-ratio hesaplaması için gerekir. Responsive tasarım için srcset ve sizes ekleyin; kullanıcının ekran boyutuna uygun daha küçük varyant (ör. mobilde 640px) sunulur.

TTFB ve CDN stratejisi

TTFB, LCP bütçenizin en büyük dilimidir. 2026'da global CDN'ler (Cloudflare, Fastly, Vercel Edge Network) statik HTML'i kullanıcıya coğrafi olarak en yakın PoP'tan (Point of Presence) sunarak TTFB'yi ~80 ms'ye indiriyor. Origin-only mimarilerde ise TTFB İstanbul'dan Frankfurt'a 90 ms, Frankfurt'tan Sydney'e 250 ms çıkabiliyor. Bunu deneyimlemek istiyorsanız bir VPN üzerinden Avustralya IP'siyle sitenize girin, kelimenin tam anlamıyla bekleme süresini hissedersiniz.

Edge caching stratejileri

Statik HTML: Blog yazıları, ürün sayfaları. Cache-Control: public, max-age=3600, s-maxage=86400 ile CDN'de bir gün, tarayıcıda bir saat tutulur.
Stale-While-Revalidate (SWR): stale-while-revalidate=604800 eklerseniz süresi dolmuş içerik anında sunulur, arka planda güncellenir. Algılanan LCP hızını hissedilir ölçüde iyileştirir.
ISR (Incremental Static Regeneration): Next.js, Astro ve SvelteKit'te 2026 desteği stabil. Dinamik veriyi CDN'de statik gibi cache'ler.

Sunucu tarafında gzip yerine brotli ya da zstd sıkıştırma kullanın; HTML dosya boyutu %20 kadar küçülür, TTFB doğrudan azalır. TTFB ölçüm ve düşürme teknikleri için INP optimizasyonu 2026 yazısındaki server response bölümü de tamamlayıcı okuma.

Streaming SSR ve erken flush

Klasik Server-Side Rendering'de sunucu tüm HTML'i hazırlar, sonra tek seferde gönderir. Bu, LCP'nin veri fetch süresine takılmasına neden olur. Streaming SSR ise HTML'i parça parça yollar: <head> ve kahraman görseli hemen flush edilir, ağır bileşenler (yorumlar, öneriler) sonradan akar.

// Next.js 15 App Router ile streaming SSR örneği
export default function Page() {
  return (
    <>
      {/* Kritik LCP içeriği hemen render edilir */}
      <Hero />

      {/* Suspense sınırı ile geciken içerik akış halinde gelir */}
      <Suspense fallback={<Skeleton />}>
        <Recommendations />
      </Suspense>
    </>
  );
}

Streaming SSR ile birlikte Early Hints (HTTP 103) göndermek TTFB'yi daha da hızlandırıyor: Sunucu tam yanıtı hazırlarken bile tarayıcıya "şu CSS ve LCP görselini şimdiden çekmeye başla" diyebilir. Cloudflare, Fastly ve Vercel 2026'da 103 Early Hints'i tam destekliyor. Küçük bir not: Origin sunucunuz da 103 üretmeli, sadece CDN'in tek başına yaptığı sihirli bir iş değil bu.

Render engelleyici CSS ve JavaScript

Kaynak indirilmiş olsa bile tarayıcı, sayfanın layout ağacını oluşturana kadar hiçbir şeyi boyayamaz. Render engelleyici (render-blocking) her CSS dosyası bu ağacın hesaplanmasını geciktirir; her senkron JavaScript ise parser'ı durdurur.

Kritik CSS'i inline gömme

Above-the-fold içeriğine ait CSS'i (~14 KB) <style> etiketi içinde HTML'e inline gömmek, dış CSS dosyasını beklemeden ilk boyamayı sağlar. Kalan CSS'i <link rel="stylesheet" media="print" onload="this.media='all'"> hilesiyle asenkron yükleyin. Critters ve beasties gibi araçlar bu işi otomatik yapıyor.

Üçüncü taraf script'lerini geciktirme

<!-- Analytics, chat widget, A/B testi. Hepsi LCP sonrası -->
<script src="https://analytics.example.com/tag.js" defer></script>
<script src="https://widget.example.com/chat.js" async></script>

<!-- Ya da tamamen etkileşim sonrasına ertele -->
<script>
  window.addEventListener('load', () => {
    setTimeout(() => {
      const s = document.createElement('script');
      s.src = 'https://tag.example.com/pixel.js';
      document.body.appendChild(s);
    }, 3000);
  });
</script>

Google Tag Manager, Facebook Pixel, Hotjar gibi taglar LCP'yi 500-2000 ms geciktiriyor. Bunları defer, async ya da idle callback ile ertelemek düşük efor-yüksek etkili optimizasyonlardan.

Speculation Rules API ile prerender

2026'nın en büyük LCP kazanımı Speculation Rules API'dir. Chrome 121+ ve Edge'de tam destekli, Firefox'ta 2026 Q3'te tam desteğe geçti. Bu API sayesinde, kullanıcının bir sonraki sayfayı ziyaret etme olasılığı yüksek olduğunda tarayıcı arka planda o sayfayı önceden render ediyor.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/urun/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "href_matches": "/blog/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

Prerender edilmiş sayfada kullanıcı linke tıkladığında LCP fiilen 0 ms olarak raporlanır; navigasyon anlıktır. eagerness parametresi conservative, moderate, eager ve immediate seçenekleriyle tarayıcının ne kadar agresif prerender yapacağını kontrol eder. Chrome Developers prerender rehberi tam kural sözdizimini içeriyor. E-ticaret sitelerinde ana kategori sayfasından ürün sayfasına LCP p75'inin %60 azaldığı raporlanmış. (Bunu bir müşteride canlı gördüm; ürün sayfası tıklaması gerçekten "boşluk yok" hissi veriyor.)

LCP nasıl iyileştirilir? Adım adım kontrol listesi

Yukarıdaki tekniklerin tümü ideal, ama sıralama önemli. Aşağıdaki liste en yüksek ROI'den en düşüğe doğru sıralanmıştır:

LCP elementini tespit edin (DevTools + PerformanceObserver). Tahmine dayalı optimizasyon yapmayın.
Alt bileşen dağılımını çıkarın: TTFB / Load Delay / Load Duration / Render Delay yüzdeleri. En büyük dilimi hedefleyin.
TTFB > 600 ms ise: CDN, edge caching, brotli sıkıştırma, ISR devreye alın.
Load Delay > 200 ms ise: LCP görseline fetchpriority="high" ekleyin, HTML head'ine <link rel="preload"> koyun.
Load Duration büyükse: AVIF'e geçin, responsive srcset ekleyin, gerekirse CDN üzerinde on-the-fly resize (Cloudinary, imgix, Vercel Image Optimization).
Render Delay büyükse: Kritik CSS inline, üçüncü taraf scriptleri defer/async, hidrasyonu Suspense ile bölün.
Speculation Rules ekleyin: En sık ziyaret edilen navigasyon adımları için prerender ya da prefetch tanımlayın.
RUM ile doğrulayın: Lab (Lighthouse) sonucu değil, CrUX ya da kendi RUM verinizle p75 mobil LCP'nin 2.5 sn altına indiğini doğrulayın. 28 gün beklemek gerekiyor.

Sıkça Sorulan Sorular

İyi bir LCP değeri ne kadardır?

Google'ın 2026 Core Web Vitals eşiklerine göre "iyi" LCP 2.5 saniye altı, "iyileştirilmesi gereken" 2.5-4 saniye, "kötü" ise 4 saniyenin üzeridir. Değerlendirme, gerçek kullanıcıların 75. yüzdelik dilimindeki (p75) mobil verisiyle yapılır.

LCP ve FCP arasındaki fark nedir?

First Contentful Paint (FCP) ekrana ilk piksel içeriğin (herhangi bir metin ya da görsel) boyandığı anı ölçer. LCP ise viewport'taki en büyük içerik öğesinin boyandığı andır. FCP genellikle LCP'den 500-2000 ms daha erken gerçekleşir; kullanıcı deneyimini LCP daha iyi temsil eder.

Kahraman görseli için hangi görsel formatı en iyisidir?

2026 için AVIF birinci tercih olmalıdır: JPEG'e göre %50-70, WebP'ye göre %30 daha küçüktür ve Safari 16.4+ dâhil tüm modern tarayıcılarda çalışır. WebP'yi ikinci fallback, JPEG'i son fallback olarak <picture> etiketiyle birlikte sunun.

fetchpriority attribute'u ne işe yarar?

fetchpriority="high" tarayıcıya bir kaynağın diğerlerinden daha yüksek öncelikle indirilmesi gerektiğini söyler. LCP görseli için kullanıldığında Resource Load Delay'i ortalama 400-800 ms azaltır. Sayfada yalnızca tek bir öğeye "high" verilmelidir; birden fazlasına vermek etkiyi sıfırlar.

Lighthouse LCP değeri neden CrUX'tan farklı çıkıyor?

Lighthouse, simüle edilmiş 4G mobil bağlantı üzerinde tek seferlik lab ölçümü yapar. CrUX ise gerçek Chrome kullanıcılarının 28 günlük p75 verisidir. Google sıralamada CrUX'u dikkate alır; Lighthouse yalnızca yerel test aracıdır. RUM (Real User Monitoring) kurmadan optimizasyon sonucunu doğrulayamazsınız.