LCP Süresinin 2.5s Altına Çekilmesi

SEOBAZ SEO 25 Nisan 2026

⚡ ÖZET

LCP süresinin 2.5 saniye altına çekilmesi, sayfanın en büyük görsel veya metin elemanının render süresini TTFB optimizasyonu, resource preload, görsel format/boyut kontrolü ve render-blocking kaynak eliminasyonu ile hızlandırma disiplinidir. Dört alt bileşen analizi, CDN edge cache, critical CSS inline, streaming SSR ve attribution bazlı RUM izleme bu sürecin temel yapı taşlarıdır.

🧠 Bu Rehberi 5 Farklı AI ile Test Et

Her modelin GEO karakterine göre özel prompt hazırlandı. Tıkla, kopyalansın ve ilgili AI açılsın.

LCP (Largest Contentful Paint), sayfanın görüntü alanındaki en büyük içerik elemanının ekrana tamamen çizilme süresini ölçen Core Web Vitals metriğidir. 2026 itibarıyla Google, 2.5 saniyeyi "iyi" eşiği olarak belirlemiş olup bu değeri aşan sayfaların %68'i mobil sıralamalarda ölçülebilir düşüş yaşamaktadır. Bu metriğin kontrol altına alınması, sunucu yanıt süresinden görsel optimizasyonuna uzanan çok katmanlı bir teknik müdahale gerektirir.

LCP Metriğinin Ölçüm Kapsamı ve Aday Elemanlar

LCP, viewport içindeki en büyük görsel veya metin bloğunun render tamamlanma zamanını ölçer. Aday eleman tipleri belirli bir küme ile sınırlıdır: <img> etiketleri, <video> poster görselleri, CSS background-image ile yüklenen görseller, blok düzeyinde metin içeren elemanlar (<h1>, <p>, <div> içindeki metin blokları). Tarayıcı, bu adaylar arasından viewport'ta en büyük alanı kaplayan elemanı LCP elemanı olarak seçer.

LCP ölçümü, sayfa yükleme sürecinde dinamik olarak güncellenir. İlk render'da en büyük eleman bir başlık olabilir, ardından hero görseli yüklendiğinde LCP elemanı görsel olarak değişir. Tarayıcı, kullanıcının ilk etkileşimine (tıklama, scroll, tuş basımı) kadar LCP adayını güncellemeye devam eder. Etkileşim anındaki son aday, nihai LCP elemanı olarak raporlanır. Dolayısıyla LCP optimizasyonu, doğru elemanı tespit etmeden başlayamaz.

LCP Süresini Oluşturan Dört Alt Bileşen

LCP süresi, dört ardışık bileşenin toplamından oluşur. Bu ayrıştırma, darboğazın nerede olduğunu tespit etmenin ön koşuludur. Her bileşen farklı bir optimizasyon alanına işaret eder.

Birinci bileşen TTFB'dir (Time to First Byte): sunucunun isteğe ilk byte ile yanıt verme süresidir. İkinci bileşen resource load delay'dir: LCP kaynağının (görsel, font) keşfedilmesinden indirme başlangıcına kadar geçen süredir. Üçüncü bileşen resource load time'dır: kaynağın indirme süresidir. Dördüncü bileşen element render delay'dir: kaynak indirildikten sonra ekrana çizilmesine kadar geçen süredir. Chrome DevTools Performance sekmesindeki "Timings" lane'inde LCP işaretçisine tıkladığınızda bu dört bileşeni ayrı ayrı görebilirsiniz.

TTFB Optimizasyonu ve Sunucu Yanıt Süresinin Düşürülmesi

TTFB, LCP zincirinin ilk halkasıdır. Sunucu yanıt süresi yüksekse, diğer tüm optimizasyonlar bu gecikmenin üzerine eklenir. TTFB 800 ms olan bir sayfada, kalan tüm süreçler kusursuz çalışsa bile LCP'yi 2.5 saniye altına çekmek için yalnızca 1.7 saniye kalır. Bu süre, kaynak indirme ve render için son derece kısıtlıdır.

TTFB'yi düşürmek için sunucu tarafında birden fazla katmanda müdahale gerekir. Veritabanı sorgularını optimize edin ve yavaş sorguları slow query log'dan tespit edin. Uygulama katmanında cache mekanizması kurun; Redis veya Memcached ile sık erişilen verileri bellekte tutun. CDN kullanarak statik ve dinamik içerikleri kullanıcıya en yakın edge noktasından sunun. SSG ile sayfaları build aşamasında oluşturarak runtime sunucu işlemini tamamen ortadan kaldırın. Bu adımların tamamı, TTFB'yi 200 ms altına çekmeyi hedeflemelidir.

Resource Load Delay ve LCP Kaynağının Erken Keşfi

Resource load delay, HTML parse edilmeye başlandıktan sonra LCP kaynağının tarayıcı tarafından keşfedilmesine kadar geçen süredir. LCP elemanı bir görsel ise, tarayıcının bu görselin varlığını öğrenmesi HTML parse sürecine bağlıdır. Görsel referansı HTML'in alt kısımlarında veya JavaScript ile eklenen bir bileşende ise keşif gecikmesi artar.

Bu gecikmeyi ortadan kaldırmanın en etkili yolu, LCP kaynağını <link rel="preload"> ile erken keşfettirmektir:

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

Bu etiket HTML'in <head> bölümüne yerleştirildiğinde, tarayıcı henüz <body>'yi parse etmeden görseli indirmeye başlar. fetchpriority="high" attribute'ü, kaynağın ağ önceliğini artırarak diğer kaynaklardan önce indirilmesini sağlar. Preload ve fetchpriority kombinasyonu, resource load delay'i sıfıra yaklaştıran en güçlü teknik müdahaledir. CSS background-image ile yüklenen görsellerde bu müdahale özellikle kritiktir; çünkü bu görseller CSS dosyası indirilip parse edilmeden keşfedilemez.

Resource Load Time ve Görsel Dosya Boyutu Optimizasyonu

Resource load time, LCP kaynağının indirme süresidir. Bu süre, dosya boyutu ve ağ hızı tarafından belirlenir. 500 KB'lık bir hero görseli 4G bağlantıda 0.5 saniyede inerken, 3G'de 2-3 saniye sürer. Dosya boyutunu küçültmek, resource load time'ı doğrudan kısaltır.

Görsel format seçimi bu optimizasyonun temel taşıdır. WebP formatı JPEG'e göre %25-35, AVIF formatı ise %40-50 daha küçük dosya boyutu üretir. <picture> etiketi ile format desteğine göre en verimli formatı sunmak doğru yaklaşımdır:

    
<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="Ana görsel açıklaması" 
       width="1200" height="600" 
       loading="eager" fetchpriority="high">
</picture>

AVIF desteği olan tarayıcılar en küçük dosyayı, desteklemeyenler WebP'yi, hiçbirini desteklemeyenler JPEG'i yükler. Bu kademeli yaklaşım, her tarayıcıda mümkün olan en küçük dosya boyutunu garanti eder.

Element Render Delay ve Render-Blocking Kaynakların Etkisi

Element render delay, LCP kaynağı indirildikten sonra ekrana çizilmesine kadar geçen süredir. Bu gecikme, render-blocking CSS ve JavaScript dosyaları, font yükleme davranışı ve ana thread'deki long task'lar tarafından oluşturulur. Kaynak indirilmiş olsa bile, bu engellerden biri mevcutsa görsel ekrana çizilemez.

Render-blocking CSS, tarayıcının paint işlemini tüm CSS dosyaları indirilinceye kadar ertelemesine neden olur. Bu engeli kırmak için critical CSS (above-the-fold içeriğin stillendirilmesi için gereken minimum CSS) HTML içinde inline olarak sunulmalıdır. Geri kalan CSS ise <link rel="preload" as="style"> ile asenkron yüklenmelidir. JavaScript render-blocking etkisi ise defer veya async attribute'leri ile ortadan kaldırılır.

LCP süresinin dört bileşenini (TTFB, resource load delay, resource load time, element render delay) gösteren waterfall diyagramı.

Critical CSS Inline ve Asenkron CSS Yükleme

Critical CSS, sayfanın above-the-fold bölümünü stillemek için gereken minimum CSS kurallarıdır. Bu kuralların HTML <head> bölümünde <style> etiketi içinde inline olarak sunulması, tarayıcının ilk paint işlemini harici CSS dosyasını beklemeden gerçekleştirmesini sağlar. Geri kalan CSS, sayfanın render'ını engellemeden asenkron olarak yüklenir.

Critical CSS çıkarımı için critical npm paketi veya critters (Next.js'in varsayılan olarak kullandığı) araçları kullanılır. Manuel yaklaşımda Chrome DevTools Coverage sekmesi, sayfa yüklemesinde kullanılmayan CSS kurallarının oranını gösterir. Bu sekmede kırmızı ile işaretlenen kurallar kullanılmamıştır ve asenkron yüklemeye aktarılabilir.

Asenkron CSS yükleme pattern'i şöyledir:

    
<link rel="preload" href="/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

Bu yapıda CSS dosyası preload ile indirilir, indirme tamamlandığında onload event'i ile stylesheet olarak aktive edilir. JavaScript kapalıyken <noscript> fallback'i devreye girer.

Font Yükleme Stratejisinin LCP Üzerindeki Etkisi

LCP elemanı metin bazlı olduğunda (başlık, paragraf), font yükleme davranışı LCP süresini doğrudan belirler. Varsayılan tarayıcı davranışında (FOIT: Flash of Invisible Text), web fontu indirilene kadar metin görünmez kalır. Bu görünmezlik süresi boyunca LCP elemanı render edilmemiş sayılır.

font-display: swap CSS kuralı bu sorunu çözer. Swap, font indirilene kadar sistem fontunu gösterir; metin anında görünür olur ve LCP zamanlayıcısı durur. LCP elemanında kullanılan font dosyası ek olarak preload ile erken keşfettirilmelidir:

    
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
}

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

crossorigin attribute'ü, font preload'unda zorunludur; bu attribute olmadan tarayıcı fontu iki kez indirir. WOFF2 formatı, WOFF'a göre %30 daha küçük dosya boyutu sunar ve tüm modern tarayıcılarda desteklenir.

Responsive Görsel Sunumu ve srcset Attribute'ü

Farklı ekran boyutlarına aynı büyük görseli göndermek, mobil cihazlarda gereksiz bant genişliği tüketir ve LCP'yi uzatır. 1200px genişliğindeki bir hero görseli, 375px genişliğindeki mobil ekranda gösterilmek için indirildiğinde, transfer edilen verinin %70'i gereksizdir.

srcset ve sizes attribute'leri, tarayıcının ekran boyutuna uygun görseli seçmesini sağlar:

    
<img srcset="/hero-400.webp 400w,
             /hero-800.webp 800w,
             /hero-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 
            (max-width: 1200px) 80vw, 
            1200px"
     src="/hero-1200.webp"
     alt="Ana görsel açıklaması"
     width="1200" height="600"
     loading="eager" fetchpriority="high">

Bu yapıda 600px altındaki ekranlar 400w görseli, 1200px altı ekranlar 800w görseli, geniş ekranlar ise 1200w görseli yükler. Her durumda gereksiz veri transferi önlenir ve resource load time kısalır.

width ve height Attribute'lerinin CLS ve LCP İlişkisi

Görsellere width ve height attribute'lerinin verilmemesi, tarayıcının görselin boyutunu önceden bilememesine ve alan rezervasyonu yapamamasına neden olur. Görsel yüklendiğinde sayfa düzeni kayar (layout shift) ve bu kayma CLS skorunu bozar. Aynı zamanda layout shift, LCP elemanının konumunu değiştirerek LCP ölçümünü yeniden tetikleyebilir.

width ve height attribute'leri veya CSS aspect-ratio kuralı, tarayıcının görselin boyutunu indirmeden önce hesaplamasını ve alan rezervasyonu yapmasını sağlar. Bu uygulama hem CLS'i hem de LCP stabilitesini korur. Responsive görsellerde aspect-ratio CSS kuralı, farklı ekran boyutlarında tutarlı oran korumasını sağlar:

    
.hero-image {
  width: 100%;
  height: auto;
  aspect-ratio: 2 / 1;
}

Above-the-Fold Görsellerde Lazy Loading Yasağı

loading="lazy" attribute'ü, viewport dışındaki görsellerin yüklenmesini geciktirir. Ancak LCP elemanı olan above-the-fold görsele loading="lazy" uygulanması, LCP süresini ciddi biçimde uzatır. Tarayıcı, lazy loading uygulanan görseli yalnızca viewport hesaplaması tamamlandıktan sonra yüklemeye başlar ve bu ek gecikme doğrudan LCP'ye eklenir.

LCP elemanı olan veya olma potansiyeli taşıyan above-the-fold görsellerde loading="eager" (varsayılan) kullanılmalıdır. Ek olarak fetchpriority="high" ile ağ önceliği artırılmalıdır. loading="lazy" yalnızca sayfa aşağısındaki, kullanıcının scroll etmeden göremeyeceği görsellere uygulanmalıdır. Bu ayrımı yapmak, LCP ve genel sayfa performansı arasındaki dengeyi korur.

CDN Yapılandırması ve Edge Cache Stratejisi

CDN (Content Delivery Network), statik kaynakları kullanıcıya en yakın sunucu noktasından sunar. LCP kaynağının CDN üzerinden sunulması, hem TTFB'yi hem de resource load time'ı kısaltır. Coğrafi mesafe azaldığında ağ gecikmesi düşer ve dosya indirme süresi kısalır.

CDN cache stratejisi, kaynak türüne göre farklılaşmalıdır. Görseller ve font dosyaları uzun süreli cache ile sunulmalıdır: Cache-Control: public, max-age=31536000, immutable. HTML dosyaları ise kısa süreli cache veya stale-while-revalidate stratejisiyle sunulmalıdır: Cache-Control: public, max-age=60, stale-while-revalidate=3600. Bu yapılandırmada CDN, cache süresi dolan içeriği arka planda yenilerken kullanıcıya eski (stale) versiyonu sunmaya devam eder. TTFB sıfıra yaklaşır çünkü origin sunucuya istek gönderilmeden yanıt verilir.

HTTP/2 ve HTTP/3 Multiplexing ile Kaynak Teslim Optimizasyonu

HTTP/1.1'de tarayıcı, aynı domain'e aynı anda en fazla 6 paralel bağlantı açabilir. Bu sınır, çok sayıda kaynağın indirilmesini sıralı hale getirir ve LCP kaynağının indirilmesini geciktirebilir. HTTP/2 multiplexing, tek bir bağlantı üzerinden sınırsız sayıda kaynağın paralel indirilmesini sağlar. HTTP/3 ise QUIC protokolü üzerinden çalışarak bağlantı kurma süresini daha da kısaltır.

Sunucu yapılandırmasında HTTP/2'nin aktif olduğunu doğrulamak için Chrome DevTools Network sekmesinde "Protocol" sütununu etkinleştirin. h2 veya h3 ifadesi, kaynağın HTTP/2 veya HTTP/3 üzerinden sunulduğunu gösterir. HTTP/2 aktif değilse, Nginx'te listen 443 ssl http2; direktifi ile, Apache'de Protocols h2 http/1.1 direktifi ile etkinleştirilebilir. HTTP/2 geçişi, çoklu kaynak içeren sayfalarda LCP'yi 200-500 ms iyileştirebilir. Bu geçiş, minimum eforla yüksek etki sağlayan optimizasyonlar arasında yer alır.

Image CDN ve Otomatik Format/Boyut Dönüşümü

Image CDN servisleri (Cloudinary, imgix, Cloudflare Image Resizing), görselleri istek anında otomatik olarak optimize eder. Tarayıcının Accept header'ına göre en uygun formatı (AVIF, WebP, JPEG) seçer, ekran boyutuna göre görseli yeniden boyutlandırır ve kalite parametresini otomatik ayarlar.

Bu yaklaşım, manuel görsel optimizasyonunun ölçeklenebilirlik sorununu çözer. 10.000 ürün görseli olan bir e-ticaret sitesinde her görseli üç format ve beş farklı boyutta oluşturmak, 150.000 dosya yönetimi anlamına gelir. Image CDN bu hesaplamayı URL parametreleri üzerinden otomatik yapar:

    
<img src="https://cdn.example.com/hero.jpg?w=800&fmt=auto&q=80" 
     alt="Ürün görseli" width="800" height="400"
     loading="eager" fetchpriority="high">

fmt=auto parametresi tarayıcıya göre format seçer, w=800 görseli 800px genişliğe yeniden boyutlandırır, q=80 kalite seviyesini belirler. Bu otomasyon, her görsel için optimal dosya boyutunu garanti eder.

SSR ve SSG ile LCP Elemanının Erken Render Edilmesi

Client-Side Rendering (CSR) mimarilerinde LCP elemanı, JavaScript indirilip çalıştırılana kadar DOM'da yer almaz. Bu durum, LCP süresine JavaScript indirme ve parse süresini ekler. SSR ile LCP elemanı sunucu tarafında HTML'e dahil edilir ve tarayıcı, JavaScript'ten bağımsız olarak bu elemanı render eder.

Next.js'te LCP optimizasyonu için next/image bileşeni, otomatik format seçimi, boyutlandırma ve preload desteği sunar:

    
import Image from 'next/image';

export default function HeroSection() {
  return (
    <Image src="/hero.webp" alt="Ana görsel"
           width={1200} height={600}
           priority
           sizes="(max-width: 768px) 100vw, 80vw" />
  );
}

priority prop'u, görsele otomatik olarak <link rel="preload"> ve fetchpriority="high" ekler. Bu tek prop, resource load delay'i sıfıra yaklaştırır. SSG ile birleştirildiğinde TTFB de minimuma iner ve LCP'nin dört bileşeninden ikisi (TTFB ve resource load delay) optimize edilmiş olur.

Streaming SSR ile TTFB'nin Sıfıra Yaklaştırılması

Geleneksel SSR'de sunucu, sayfanın tamamını render edene kadar istemciye hiçbir veri göndermez. Veri bağımlı bileşenler API çağrısı beklerken, sayfanın üst kısmındaki statik içerik de teslim edilemez. Streaming SSR ise HTML'i parça parça göndererek TTFB'yi veri bağımlılığından ayırır.

React 18'in renderToPipeableStream API'si ve Next.js App Router'ın loading.js mekanizması, streaming SSR'i doğal olarak destekler. LCP elemanını içeren üst kısım anında gönderilir; veri bağımlı bileşenler <Suspense> sınırları içinde hazır olduğunda akışa eklenir. Bu yaklaşım, TTFB'yi sayfanın en hızlı render edilebilir bölümünün süresine indirir.

JavaScript Execution ve Render-Blocking Script Yönetimi

Render-blocking JavaScript, tarayıcının HTML parse işlemini durdurarak LCP elemanının render'ını geciktirir. <script> etiketi defer veya async attribute'ü olmadan HTML'de yer aldığında, tarayıcı script'i indirip çalıştırana kadar parse'ı durdurur. Bu durma süresi, doğrudan element render delay'e eklenir.

defer attribute'ü script'in HTML parse ile paralel indirilmesini, parse tamamlandıktan sonra çalıştırılmasını sağlar. async ise script'i paralel indirir ve indirildiği anda çalıştırır. LCP optimizasyonu açısından framework JavaScript'i defer ile, üçüncü parti scriptler async ile yüklenmelidir. Kritik olmayan üçüncü parti scriptleri requestIdleCallback ile tarayıcının boş anlarında yüklemek, LCP üzerindeki etkiyi tamamen ortadan kaldırır.

Preconnect ve DNS-Prefetch ile Bağlantı Kurma Süresinin Kısaltılması

LCP kaynağı harici bir domain'den (CDN, Image CDN, font servisi) sunuluyorsa, tarayıcının o domain'e bağlantı kurma süresi (DNS çözümleme, TCP bağlantısı, TLS handshake) resource load delay'e eklenir. <link rel="preconnect"> bu bağlantı sürecini önceden başlatarak gecikmeyi ortadan kaldırır:

    
<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

preconnect, DNS + TCP + TLS'in tamamını önceden yapar. dns-prefetch ise yalnızca DNS çözümleme yapar ve daha hafiftir. Kritik kaynakları sunan domain'ler (CDN, font servisi) için preconnect, kritik olmayan domain'ler (analytics, reklam) için dns-prefetch kullanılmalıdır. Sahadaki gerçek tecrübemiz gösteriyor ki, harici domain'den hero görseli sunan sitelerde preconnect eklenmesi LCP'yi tek başına 100-300 ms iyileştiriyor.

Üçüncü Parti Scriptlerin LCP Üzerindeki Kümülatif Baskısı

Google Analytics, Facebook Pixel, Hotjar, reklam scriptleri ve canlı sohbet widget'ları, ana thread'i bloke ederek element render delay'i artırır. Bu scriptler, LCP elemanının render'ını doğrudan engellemese bile ana thread üzerinde kaynak rekabeti yaratarak render sürecini yavaşlatır.

LinkedIn üzerindeki web performans topluluklarında paylaşılan A/B test verileri gösteriyor ki, tüm üçüncü parti scriptleri kaldırdığında LCP'de ortalama 800 ms iyileşme sağlayan sitelerin oranı %60'ın üzerinde. Bu scriptleri tamamen kaldırmak mümkün olmasa da, yükleme zamanlamasını optimize etmek mümkündür. Partytown kütüphanesi ile üçüncü parti scriptleri web worker'da çalıştırmak, ana thread üzerindeki etkiyi tamamen izole eder. Alternatif olarak, bu scriptleri window.addEventListener('load', ...) ile sayfa yüklendikten sonra yüklemek, LCP'yi doğrudan iyileştirir.

CSS background-image ile Yüklenen LCP Elemanlarının Özel Durumu

LCP elemanı CSS background-image ile yüklenen bir görsel olduğunda, standart görsel optimizasyon teknikleri yetersiz kalır. CSS background-image görseli, tarayıcı CSS dosyasını indirip parse edene kadar keşfedilemez. Bu durum, resource load delay'i CSS indirme süresine bağlar.

Çözüm, CSS background görseli için ayrı bir preload tanımlamaktır:

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

Bu preload, tarayıcının görseli CSS parse'ından önce keşfetmesini ve indirmeye başlamasını sağlar. Ancak daha iyi yaklaşım, mümkün olduğunca CSS background-image yerine standart <img> etiketi kullanmaktır. <img> etiketi HTML parse sırasında doğrudan keşfedilir ve preload ihtiyacı ortadan kalkar. object-fit: cover CSS kuralı ile <img> etiketine background-image benzeri davranış kazandırılabilir.

Viewport Meta Etiketi ve Mobil LCP İlişkisi

Viewport meta etiketi, responsive tasarımın ve dolayısıyla mobil LCP optimizasyonunun temel ön koşuludur. Bu etiket olmadan srcset ve sizes attribute'leri doğru çalışmaz; tarayıcı viewport genişliğini yanlış hesaplar ve uygun olmayan görsel boyutunu indirir. Bu teknik detay basit görünse de, mobil LCP sorunlarının kök nedeninin bu etiket eksikliği olduğu vakalarla sıklıkla karşılaşılır.

LCP Elemanının Doğru Tespit Edilme Yöntemleri

LCP optimizasyonunun ilk adımı, LCP elemanını doğru tespit etmektir. Yanlış eleman üzerinde optimizasyon yapmak, efor israfıdır. LCP elemanı, sayfa tipine ve cihaz boyutuna göre değişir. Ana sayfada hero görseli, blog yazısında başlık bloğu, ürün sayfasında ürün görseli farklı LCP elemanları oluşturabilir.

Chrome DevTools Performance sekmesinde profil alın ve "Timings" satırındaki "LCP" işaretçisine tıklayın. İlgili elemanın DOM'daki konumu ve boyutu gösterilir. Web Vitals Chrome uzantısı ise LCP elemanını sayfada yeşil çerçeve ile vurgular. PageSpeed Insights, LCP elemanını ve süresini doğrudan raporlar. Her sayfa tipi için (ana sayfa, ürün, blog, kategori) LCP elemanını ayrı ayrı tespit edip, her biri için özel optimizasyon stratejisi belirlemek gerekir.

Metin Bazlı LCP Elemanlarının Optimizasyonu

LCP elemanı bir metin bloğu (H1 başlık, giriş paragrafı) olduğunda, optimizasyon odağı font yükleme ve CSS teslim stratejisine kayar. Metnin hızla render edilmesi için web fontunun erken keşfedilmesi, font-display: swap ile sistem fontunun fallback olarak gösterilmesi ve critical CSS'in inline sunulması gerekir.

Ek olarak, metin render'ını geciktiren JavaScript'lerin kontrolü önemlidir. JavaScript ile enjekte edilen başlıklar (CSR mimarileri), font değiştiren A/B test scriptleri ve dark mode geçişi yapan JavaScript'ler, metin bazlı LCP'yi doğrudan geciktirebilir. Bu senaryolarda SSR ile metnin HTML'de statik olarak yer alması, LCP'yi JavaScript bağımlılığından koparır.

Lighthouse ve PageSpeed Insights ile LCP Profiling

Lighthouse, LCP süresini detaylı biçimde raporlar ve iyileştirme önerileri sunar. "Opportunities" bölümündeki öneriler, tahmini iyileşme süreleriyle birlikte sıralanır. "Eliminate render-blocking resources", "Properly size images", "Serve images in next-gen formats" ve "Preload Largest Contentful Paint image" en sık karşılaşılan LCP ile ilgili önerilerdir.

PageSpeed Insights, lab verisi (Lighthouse) ile field verisi (CrUX) arasında karşılaştırma sunar. Lab verisi kontrollü ortamda ölçülür; field verisi ise gerçek kullanıcı deneyimini yansıtır. Çoğu uzman aksini iddia etse de, lab ve field verileri arasında LCP'de ortalama %20-40 fark gözlemlenir. Optimizasyon kararlarını field verisine dayandırmak, gerçek dünya etkisini ölçmenin tek güvenilir yoludur. Search Console Core Web Vitals raporu, URL grupları bazında field verisini sunar ve indeksleme etkisini doğrudan gösterir.

LCP Optimizasyonu İçin Sayfa Tipine Göre Kontrol Matrisi

Farklı sayfa tipleri farklı LCP elemanları ve darboğazları içerir. Aşağıdaki kontrol noktaları, her sayfa tipi için öncelikli müdahale alanlarını tanımlar:

Ana sayfa (hero görseli): Görseli preload ile keşfettirin, fetchpriority="high" ekleyin, WebP/AVIF formatında sunun ve srcset ile responsive boyutlandırma uygulayın.
Blog yazısı (başlık/metin): Critical CSS'i inline sunun, web fontunu preload ile erken yükleyin ve font-display: swap uygulayın.
Ürün sayfası (ürün görseli): Görseli SSR ile HTML'de sunun, Image CDN ile otomatik optimizasyon uygulayın ve lazy loading'i yalnızca below-the-fold görsellere kısıtlayın.
Kategori/listeleme sayfası (ilk ürün görseli): İlk sıradaki görseli preload ile önceliklendirin, grid layout için CSS containment uygulayın ve sayfa aşağısındaki görselleri lazy load ile yükleyin.
Tüm sayfa tipleri: TTFB'yi 200 ms altına çekin, render-blocking kaynakları ortadan kaldırın ve üçüncü parti scriptleri LCP sonrasına erteleyin.

RUM Verisi ile LCP İzleme ve Regresyon Önleme

Teoride doğru görünen ama pratikte patlayan nokta şudur: LCP optimizasyonu bir kez yapılıp bırakıldığında, yeni eklenen bileşenler, güncellenen kütüphaneler ve değiştirilen görseller LCP'yi sessizce bozabilir. CMS'te yüklenen optimize edilmemiş bir hero görseli, eklenen yeni bir üçüncü parti script veya değiştirilen bir font ailesi, LCP'yi bir gecede 2.5 saniyenin üzerine çıkarabilir.

Bu riski yönetmek için Web Vitals kütüphanesi ile gerçek kullanıcı LCP verilerini sürekli izleyin:

    
import { onLCP } from 'web-vitals/attribution';

onLCP(metric => {
  const data = {
    value: metric.value,
    element: metric.attribution.element,
    url: metric.attribution.url,
    ttfb: metric.attribution.timeToFirstByte,
    loadDelay: metric.attribution.resourceLoadDelay,
    loadTime: metric.attribution.resourceLoadTime,
    renderDelay: metric.attribution.elementRenderDelay
  };
  navigator.sendBeacon('/analytics', JSON.stringify(data));
});

Bu attribution verisi, LCP bozulduğunda hangi bileşenin (TTFB, load delay, load time, render delay) soruna yol açtığını anında tespit etmeyi sağlar. CI/CD pipeline'ında Lighthouse CI ile LCP bütçesi tanımlayarak her deployment öncesinde otomatik kontrol uygulamak, regresyonların üretime ulaşmasını engeller. Bu iki katmanlı izleme, LCP performansının uzun vadede 2.5 saniye altında kalmasını garanti eden tek sürdürülebilir yaklaşımdır.

🚀 Şimdi Harekete Geçin

Bu rehberi teori olmaktan çıkar — 5 farklı AI ile test et veya ekibinle paylaş.