LCP Nedir ve Nasıl İyileştirilir? 2,5 Saniyenin Altına İndirme

PageSpeed Insights raporunu açıyorsunuz, üç metrikten ikisi yeşil, biri kıpkırmızı: LCP 4,8 s. Görselleri sıkıştırıyorsunuz, önbellek eklentisini kuruyorsunuz, skor 3 puan artıyor ama LCP hâlâ kırmızı. Bunun nedeni neredeyse her zaman aynıdır: LCP'yi "sayfa hızı" sanıp genel optimizasyon yapıyorsunuz, oysa LCP tek bir DOM öğesinin ne zaman ekrana boyandığını ölçen çok dar bir metriktir. O öğeyi bulmadan yaptığınız her iyileştirme kör atıştır.

Bu yazıda önce LCP nedir ve tarayıcı hangi öğeyi "en büyük içerik" sayar onu netleştireceğiz. Ardından kendi sitenizdeki LCP öğesini üç farklı yöntemle kesin olarak tespit edeceğiz. Sonrasında LCP süresini oluşturan dört alt bileşeni tek tek ayrıştırıp her biri için somut düzeltmeyi göstereceğiz: sunucu yanıt süresi, kaynak keşif gecikmesi, kaynak indirme süresi ve öğe render gecikmesi. preload, fetchpriority, doğru srcset, kritik CSS ve font yükleme davranışı gibi işi gerçekten çözen ayarları kopyalanabilir kodla vereceğiz. Yıllardır gördüğüm en yaygın hata, hero görselini lazy-load etmektir — ve bu tek satır çoğu sitede LCP'ye bir buçuk saniye ekler.

LCP Nedir ve Tarayıcı Hangi Öğeyi Ölçer#

LCP (Largest Contentful Paint, "en büyük içerikli boyama"), sayfanın görünür alanındaki en büyük içerik öğesinin ekrana boyanma anıdır. Sayfanın tamamının yüklenmesini değil, kullanıcının "ana içerik geldi" hissettiği anı ölçer.

Tarayıcı LCP adayı olarak sadece belirli öğe türlerine bakar:

• <img> öğeleri
• <image> (SVG içindeki)
• <video> öğesinin poster görseli
• CSS background-image ile yüklenen görseller (yalnızca url() ile)
• Metin içeren blok seviyesi öğeler (paragraf, başlık, liste)

Görünür alanın (viewport) dışında kalan hiçbir şey aday değildir. Sayfa yüklenirken bu adaylar sırayla boyanır ve tarayıcı her seferinde "şu ana kadarki en büyüğü" olarak yeni bir LCP değeri raporlar. Kullanıcı ilk kez etkileşime geçtiğinde (tıklama, tuşa basma) ölçüm durur ve son değer nihai LCP olur.

Eşikler nettir:

Bu eşikler saha verisinde %75'lik dilim üzerinden değerlendirilir. Yani ziyaretçilerinizin dörtte üçü 2,5 saniyenin altında görmelidir. Laboratuvar testinde 2,1 s alıp saha verisinde 3,8 s görmeniz gayet normaldir; laboratuvar sabit bir cihaz ve sabit bir ağ kullanır, gerçek kullanıcılar kullanmaz.

LCP Öğesini Kesin Olarak Bulma#

Optimizasyona başlamadan önce yapılacak tek doğru iş, hangi öğenin LCP olduğunu bulmaktır. Üç yöntem var, üçü de birkaç saniye sürüyor.

1. PageSpeed Insights raporundan. Rapordaki "Teşhis" bölümünde Largest Contentful Paint element başlıklı satırı açın. Öğenin HTML'i ve CSS seçicisi orada listelidir. Aynı bölüm LCP'yi dört alt aşamaya bölen bir dağılım da verir; birazdan o dağılımı kullanacağız.

2. Chrome DevTools Performance panelinden. Sayfayı kaydedin, zaman çizelgesinde Timings şeridindeki LCP işaretine tıklayın. Alt panelde "Related Node" satırı çıkar; üzerine gelince öğe sayfada mavi çerçeveyle vurgulanır. Bu, tartışmasız en kesin yöntemdir çünkü gerçek render sırasını gösterir.

3. Konsola yapıştırılabilir tek parça kodla. Herhangi bir sayfada, geliştirici konsolunda çalıştırın:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log('LCP:', Math.round(last.startTime), 'ms');
  console.log('Öğe:', last.element);
  console.log('URL:', last.url || '(metin öğesi)');
}).observe({ type: 'largest-contentful-paint', buffered: true });

Sayfayı yenilediğinizde konsol size hem süreyi hem de tam olarak hangi DOM düğümünü ölçtüğünü yazar. Ben sahada bu kodu kullanıyorum çünkü müşteri sunucusunda DevTools kaydı almak her zaman pratik olmuyor.

Sonuç genellikle üç şeyden biridir: hero/kapak görseli, ürün detay sayfasındaki ana ürün fotoğrafı, ya da içerik ağırlıklı sitelerde ilk paragrafın kendisi. Hangisi çıktıysa optimizasyonun tamamı o öğeye odaklanacak.

LCP Süresinin Dört Bileşeni#

LCP tek bir sayı gibi görünür ama aslında dört ardışık aşamanın toplamıdır. Doğru düzeltmeyi seçmek için hangi aşamanın şiştiğini bilmeniz gerekir.

PageSpeed raporundaki dağılım bu dört rakamı milisaniye olarak verir. Örneğin 4.100 ms'lik bir LCP'de dağılım şöyle çıkabilir: TTFB 900 ms, yükleme gecikmesi 1.850 ms, yükleme süresi 620 ms, render gecikmesi 730 ms. Buradaki asıl suçlu ortadaki 1.850 ms'dir — görsel küçüktür, sunucu makul hızdadır, ama tarayıcı o görseli 1,8 saniye boyunca keşfedememiştir. Görseli sıkıştırmak bu sitede hiçbir şey değiştirmez.

TTFB'yi Düşürmek: LCP'nin Taban Süresi#

TTFB, LCP'nin altına inemeyeceği tabandır; 1,2 saniyelik bir TTFB ile 2,5 saniyelik LCP'yi tutturmak neredeyse imkânsızdır.

Paylaşımlı hosting üzerindeki WordPress sitelerinde TTFB'yi şişiren tipik nedenler sırayla şunlardır: sayfa önbelleğinin olmaması, ağır sorgu üreten eklentiler, wp-cron'un her istekte tetiklenmesi, ve veritabanındaki şişmiş wp_options tablosu (özellikle autoload alanı yes olan büyük satırlar).

Kendi TTFB'nizi tek komutla ölçebilirsiniz:

curl -o /dev/null -s -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nToplam: %{time_total}\n" https://alanadiniz.com/

Çıktıda TTFB ile TLS arasındaki fark saf sunucu işlem süresidir. Bu fark 0,6 saniyenin üzerindeyse sorun ağ değil, uygulama tarafındadır.

Otoload sorgusuyla WordPress veritabanınızdaki en ağır satırları görün:

SELECT option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload = 'yes'
ORDER BY boyut DESC
LIMIT 20;

Burada silinmiş eklentilerden kalma yüz kilobaytlık transient kayıtları görmek çok yaygındır; her sayfa isteğinde bunların hepsi belleğe okunur. TTFB'nin nasıl parçalandığını ve hangi katmanda ne yapılacağını ttfb nedir ve nasıl düşürülür yazısında ayrıntılı ele aldık.

Kaynak Keşif Gecikmesi: En Sık Atlanan Kalem#

LCP görselinin indirilmeye ne kadar geç başladığı, çoğu sitede toplam sürenin en büyük payıdır — ve neredeyse hiçbir Türkçe rehber bundan bahsetmez.

Tarayıcı HTML'i yukarıdan aşağı okurken görsel etiketlerini görür ve indirmeye başlar. Görseliniz HTML'de değil de JavaScript ile sonradan enjekte ediliyorsa, ya da CSS background-image ile geliyorsa, tarayıcı onu ancak ilgili CSS/JS dosyasını indirip işledikten sonra keşfeder. Bu, saniyelerce gecikme demektir.

Üç somut düzeltme:

1. Hero görselini asla lazy-load etmeyin. WordPress 5.5'ten beri tüm görsellere otomatik loading="lazy" ekliyor. Görünür alandaki görselde bu, tarayıcının indirmeyi bilerek ertelemesi anlamına gelir.

<!-- YANLIŞ: görünür alandaki görsel geciktiriliyor -->
<img src="/kapak.webp" width="1600" height="900" loading="lazy" alt="Kapak">

<!-- DOĞRU -->
<img src="/kapak.webp" width="1600" height="900" loading="eager" fetchpriority="high" alt="Kapak">

WordPress'te ilk görseli lazy-load dışında bırakmak için tema functions.php dosyasına:

add_filter('wp_lazy_loading_enabled', function ($default, $tag_name, $context) {
    if ($context === 'the_post_thumbnail') {
        return false;
    }
    return $default;
}, 10, 3);

2. fetchpriority="high" ekleyin. Tarayıcı görselleri varsayılan olarak "düşük" öncelikle indirir; bu öznitelik LCP görselini stil dosyalarıyla aynı önceliğe çıkarır. Tek satırlık bir değişiklikle sahada 300–600 ms kazandığını defalarca ölçtüm.

3. CSS arka planı olan hero için preload kullanın. CSS background-image tarayıcı tarafından geç keşfedilir, çözümü <head> içinde erken bildirmektir:

<link rel="preload" as="image" href="/img/hero-1600.webp"
      imagesrcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
      imagesizes="100vw" fetchpriority="high">

⚠️ preload'u yalnızca gerçekten LCP olan tek bir kaynak için kullanın. Beş görseli birden preload etmek bant genişliğini böler ve LCP'yi yükseltir; bu, "iyileştirme" adına en sık yapılan geri tepen müdahaledir.

Görsel Boyutu, Formatı ve Doğru srcset#

LCP görselinin gerçek boyutunun ekranda kapladığı alandan büyük olmaması gerekir; 3000 piksel genişliğinde bir fotoğrafı 800 piksellik bir alana basmak indirme süresini boşuna dört katına çıkarır.

Doğru yaklaşım responsive görsel setidir:

<img src="/img/urun-1200.webp"
     srcset="/img/urun-400.webp 400w,
             /img/urun-800.webp 800w,
             /img/urun-1200.webp 1200w,
             /img/urun-1600.webp 1600w"
     sizes="(max-width: 768px) 100vw, 800px"
     width="1200" height="675"
     fetchpriority="high" decoding="async" alt="Ürün görseli">

sizes özniteliği kritiktir ve en çok yanlış yazılan yerdir: tarayıcıya "bu görsel ekranda kaç piksel yer kaplayacak" der. Yanlış sizes yazarsanız tarayıcı mobilde de 1600 piksellik dosyayı indirir ve tüm srcset emeği boşa gider.

Format tarafında WebP, aynı görsel kalitesinde JPEG'e göre gözle görülür biçimde küçük dosya üretir. Toplu dönüşüm için ImageMagick yeterlidir:

# Tek dosya
cwebp -q 82 kapak.jpg -o kapak.webp

# Klasördeki tüm JPEG'ler
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

Kalite değerini 82 civarında tutmak pratikte en iyi denge; 90'ın üzeri dosyayı büyütür, 70'in altı fotoğraflarda blok artefaktı üretir. Dönüşüm sürecini ve WordPress tarafındaki eklenti ayarlarını webp formatına dönüştürme yazısında adım adım anlattık.

Ayrıca width ve height özniteliklerini her zaman yazın. Bunlar yalnızca düzen kaymasını önlemekle kalmaz, tarayıcının yer ayırıp render'ı erken tamamlamasını da sağlar.

Render Gecikmesi: Görsel İndi Ama Boyanmıyor#

Render gecikmesi, kaynağın indirilmesi bittikten sonra ekrana çizilene kadar geçen süredir ve neredeyse her zaman render'ı bloklayan CSS veya JavaScript yüzündendir.

<head> içindeki her <link rel="stylesheet"> ve defer/async taşımayan her <script>, tarayıcının sayfayı boyamasını durdurur. Tipik bir WordPress kurulumunda <head> içinde 12–18 stil ve script dosyası bulmak sıradandır; bunların büyük kısmı sayfanın altındaki bir eklentiye aittir.

Üç adımlı yaklaşım:

1. Kritik CSS'i satır içine alın. Görünür alanı çizen kuralları (tipografi, hero bloğu, üst menü) <style> etiketiyle doğrudan HTML'e gömün, kalan stili gecikmeli yükleyin.
2. Kalan CSS'i bloklamadan yükleyin:

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

3. Her scripte defer verin. Analitik, sohbet, slider, sayaç — hiçbiri ilk boyamadan önce çalışmak zorunda değildir.

<script src="/js/slider.js" defer></script>

Hangi kaynakların bloklama yaptığını ve sırayla nasıl temizleneceğini render engelleyen kaynakları kaldırma yazısında ele aldık.

Font davranışı ayrı bir tuzaktır. LCP öğeniz metinse ve özel bir yazı tipi kullanıyorsanız, tarayıcı varsayılan olarak font inene kadar metni görünmez tutar (FOIT). Bu doğrudan LCP gecikmesidir:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  font-weight: 400;
}

font-display: swap metni hemen sistem fontuyla çizer, font gelince değiştirir. LCP'yi düşürür ama küçük bir düzen kayması riski getirir; bu dengeyi cls düzen kayması nasıl düzeltilir yazısında ayrıntılandırdık. Ayrıca fontları kendi sunucunuzdan sunun ve <head> içinde preload edin:

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

Sunucu ve Barındırma Tarafındaki Kazançlar#

Uygulama tarafını temizledikten sonra hâlâ yüksek bir taban süresi kalıyorsa, sorun altyapıdadır ve kodla çözülmez.

Sıkıştırma açık mı? Brotli, metin tabanlı dosyalarda gzip'ten daha iyi oran verir. Nginx üzerinde:

gzip on;
gzip_comp_level 5;
gzip_types text/css application/javascript image/svg+xml application/json;

brotli on;
brotli_comp_level 5;
brotli_types text/css application/javascript image/svg+xml application/json;

Doğrulama:

curl -sI -H "Accept-Encoding: br,gzip" https://alanadiniz.com/css/main.css | grep -i content-encoding

Statik dosyalar uzun ömürlü önbelleğe alınıyor mu?

location ~* \.(webp|jpg|jpeg|png|svg|woff2|css|js)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

immutable bayrağı, dosya adında hash bulunan varlıklar için tarayıcının doğrulama isteği bile göndermemesini sağlar.

Coğrafi mesafe. Ziyaretçileriniz Türkiye'deyse ve sunucunuz yurt dışındaysa, her istekte 80–150 ms'lik gidiş-dönüş cezası ödersiniz; bu, TTFB'ye doğrudan eklenir ve hiçbir kod optimizasyonu geri kazandırmaz. Barındırma türlerinin kaynak ve performans farkları için web hosting türleri yazısına bakabilirsiniz.

Kaynak limiti. Paylaşımlı pakette CPU ve giriş/çıkış limitine takılan bir site, trafik arttığında TTFB'yi katlar. Bu durumda tek gerçekçi çözüm izole kaynak, yani kendi sanal sunucunuzdur.

Düzeltmeden Sonra Doğru Ölçüm#

Laboratuvar testinde iyileşme görmek yetmez; Google sıralama sinyali olarak saha verisini kullanır ve bu veri 28 günlük yuvarlanan pencereyle güncellenir.

Doğru ölçüm sırası şudur:

1. Değişikliği yapın, tam sayfa önbelleğini ve varsa CDN önbelleğini temizleyin.
2. PageSpeed Insights ile mobil testi en az üç kez çalıştırın, ortanca değeri alın. Tek testin gürültüsü yüksektir.
3. DevTools'ta ağı "Slow 4G", CPU'yu "4x slowdown" yaparak tekrar ölçün. Gerçek mobil kullanıcı budur.
4. Search Console → Core Web Vitals raporunu takvimde işaretleyin; saha verisinin dönmesi haftalar alır.

Ölçüm sırasında yaptığınız değişikliğin gerçekten yayına çıktığından emin olun; önbellek katmanları yüzünden eski HTML'in servis edilmesi çok yaygındır. Bunu görmek için:

curl -s https://alanadiniz.com/ | grep -o 'fetchpriority="high"'

Çıktı boşsa değişikliğiniz ziyaretçiye ulaşmıyor demektir. Skoru bir bütün olarak yükseltme sırası ve öncelik listesi için pagespeed insights skoru yükseltme yazısı iyi bir tamamlayıcıdır.

Sıkça Sorulan Sorular#

LCP kaç saniye olmalı#

LCP, ziyaretçilerin %75'i için 2,5 saniyenin altında olmalıdır. 2,5 ile 4 saniye arası "iyileştirme gerekli", 4 saniye üzeri "zayıf" kabul edilir. Bu değerlendirme laboratuvar testine değil, gerçek kullanıcılardan toplanan saha verisine göre yapılır. Bu yüzden PageSpeed testinde 2,3 s görüp Search Console'da hâlâ sarı kalabilirsiniz; saha verisi 28 günlük penceredeki tüm ziyaretleri kapsar ve yavaş cihazlarla mobil bağlantıları da içerir.

LCP öğemin hangisi olduğunu nasıl anlarım#

PageSpeed Insights raporundaki "Largest Contentful Paint element" satırı size öğenin HTML'ini doğrudan verir. Daha kesin sonuç için Chrome DevTools'ta Performance kaydı alıp Timings şeridindeki LCP işaretine tıklayın; "Related Node" satırı öğeyi sayfada vurgular. Konsola PerformanceObserver ile largest-contentful-paint tipini dinleyen kısa bir kod yapıştırmak da işe yarar ve sunucuya erişiminiz olmadığında en pratik yöntemdir. Üç yöntem de aynı öğeyi göstermelidir; farklı çıkıyorsa sayfanız yükleme sırasında düzen değiştiriyor demektir.

Görselleri sıkıştırdım ama LCP düşmedi, neden#

Çünkü sorununuz büyük olasılıkla indirme süresi değil, keşif gecikmesidir. PageSpeed raporundaki LCP dağılımına bakın: "kaynak yükleme süresi" küçük ama "kaynak yükleme gecikmesi" büyükse, tarayıcı görseli geç fark ediyor demektir. Bunun tipik nedenleri hero görselinde loading="lazy" bulunması, görselin JavaScript ile sonradan eklenmesi veya CSS arka planı olarak tanımlanmasıdır. Çözüm sıkıştırma değil, fetchpriority="high", loading="eager" ve gerektiğinde <link rel="preload" as="image"> kullanmaktır.

fetchpriority ve preload aynı anda kullanılmalı mı#

Hayır, ikisini aynı kaynak için birlikte kullanmak genelde gereksizdir. Görsel HTML'de normal bir <img> etiketiyse fetchpriority="high" tek başına yeterlidir çünkü tarayıcı onu zaten erken keşfeder. preload ise tarayıcının geç keşfettiği kaynaklar için gereklidir: CSS arka plan görselleri, JavaScript ile enjekte edilen görseller ve web fontları. Kural şudur: HTML'de doğrudan görünüyorsa fetchpriority, görünmüyorsa preload.

Paylaşımlı hostingte LCP 2,5 saniyenin altına inebilir mi#

Evet, inebilir; paylaşımlı barındırmada iyi LCP almak tamamen mümkündür ve çoğu içerik sitesi bunu başarır. Belirleyici olan paket türü değil, sayfa önbelleğinin doğru çalışması, sunucunun ziyaretçiye coğrafi yakınlığı ve eklenti yükünün makul olmasıdır. Ancak trafiğiniz arttıkça ve paketin CPU/giriş-çıkış limitine yaklaştıkça TTFB dalgalanmaya başlar, saha verisi bozulur. Aynı sayfa gece 400 ms, gündüz 1,8 saniye TTFB veriyorsa sorun kodunuzda değil, paylaşılan kaynaklardadır.

CDN kullanmak LCP'yi otomatik düşürür mü#

Hayır, otomatik düşürmez ve yanlış yapılandırılırsa yükseltebilir. CDN, statik dosyaların (görsel, CSS, JS) ziyaretçiye coğrafi olarak yakın bir noktadan sunulmasını sağlar; LCP öğeniz bir görselse ve ziyaretçileriniz coğrafi olarak dağınıksa gerçek kazanç verir. Ancak HTML sayfanız CDN'de önbelleklenmiyorsa TTFB değişmez, üstelik yeni bir alan adına bağlanma maliyeti (DNS + TLS) eklenir. Ziyaretçilerinizin neredeyse tamamı Türkiye'deyse ve sunucunuz da Türkiye'deyse CDN'in LCP katkısı sınırlı kalır.

LCP ile TTFB arasındaki ilişki nedir#

TTFB, LCP'nin altına inemeyeceği taban süredir ve tipik olarak LCP'nin yüzde 20 ila 40'ını oluşturur. Sunucunuz ilk baytı 1,4 saniyede gönderiyorsa, geri kalan her şey mükemmel olsa bile LCP'niz en az 1,4 saniye artı render süresi olur. Bu yüzden optimizasyona her zaman TTFB'den başlanır: önbellek, veritabanı ve PHP tarafı düzelmeden görsel optimizasyonu yapmak sınırlı sonuç verir. TTFB'yi 600 ms'nin altına çekmek çoğu site için gerçekçi bir hedeftir.

WordPress'te LCP'yi düşürmenin en hızlı yolu nedir#

Öncelik sırası şudur: önce sayfa önbelleğini etkinleştirin, sonra öne çıkarılan görselden loading="lazy" özniteliğini kaldırıp fetchpriority="high" ekleyin, ardından <head> içindeki bloklayan script ve stilleri defer veya gecikmeli yüklemeye alın. Bu üç adım tipik bir kurulumda toplam sürenin en büyük kısmını kapsar. Eklenti sayısını azaltmak da işe yarar ama bunu körlemesine yapmayın; önce hangi eklentinin yük ürettiğini ölçün, çünkü sık suçlanan eklentiler genelde suçlu değildir.

Kapanış#

LCP'yi düşürmenin sırrı genel hız optimizasyonu değil, tek bir öğeye odaklanmaktır. Önce LCP öğesini kesin olarak bulun, sonra PageSpeed raporundaki dört aşamalı dağılıma bakıp hangi aşamanın şiştiğini görün, düzeltmeyi yalnızca oraya uygulayın. Pratikte en büyük kazanç neredeyse her zaman aynı yerden gelir: görünür alandaki ana görselden lazy-load'ı kaldırmak, ona yüksek öncelik vermek, doğru boyutta ve WebP formatında sunmak, ve <head> içindeki bloklayan kaynakları temizlemek. Bu dört müdahale çoğu sitede LCP'yi bir ila iki saniye aşağı çeker.

Uygulama tarafını temizledikten sonra hâlâ yüksek bir taban süresi kalıyorsa sıra altyapıdadır. Ziyaretçilerinizin çoğu Türkiye'deyse yerli konumlu bir web hosting paketi tek başına yüz milisaniyelerce kazandırır; WordPress özelinde önbellek ve PHP ayarları hazır gelen WordPress hosting paketleri bu işi devralır. Trafiğiniz paylaşımlı paketin kaynak limitlerini zorlamaya başladıysa izole CPU ve bellek sunan bir VDS sunucu taban süreyi kalıcı olarak sabitler. Optimizasyonu kendiniz sürdürmek istemiyorsanız WordPress bakım hizmeti önbellek, görsel ve güncelleme yönetimini üstlenir.