Largest Contentful Paint (LCP) Nasıl İyileştirilir?

Bir ziyaretçi sitenize tıkladığında, beyaz bir ekrana bakarak geçirdiği her saniye sabrını biraz daha tüketir. Sayfanın ana içeriği, yani kullanıcının "tamam, sayfa açıldı" diye düşündüğü o büyük başlık, kahraman görseli veya metin bloğu ne kadar geç görünürse, terk etme olasılığı o kadar artar. İşte bu deneyimi sayısal olarak ölçen metriğin adı Largest Contentful Paint, kısaca LCP'dir. LCP iyileştirme çalışmaları, modern web performansının en kritik konularından biridir; çünkü bu metrik hem kullanıcının algıladığı hızı hem de arama motorlarının sayfanıza biçtiği değeri doğrudan etkiler.

LCP, ekranda görünür alanda boyanan en büyük içerik öğesinin ne zaman tamamlandığını ölçer. Bu öğe genellikle büyük bir görsel, arka plan resmi, video poster karesi ya da geniş bir metin bloğu olur. Kullanıcı için "asıl içerik geldi" anı budur. Bu yüzden LCP, bir sayfanın yüklenme deneyimini tek bir sayıyla özetleyen, sezgisel ve güçlü bir göstergedir. Üstelik core web vitals ailesinin en görünür ve çoğu zaman en zorlayıcı üyesidir.

Bu rehberde LCP'nin tam olarak neyi ölçtüğünü, hangi değerlerin "iyi" sayıldığını, yavaş LCP'nin arkasındaki gerçek nedenleri ve en önemlisi bu metriği nasıl adım adım iyileştireceğinizi ele alacağız. Yazılım bilgisi olan da olmayan da bu metni okuduktan sonra kendi sitesinde nereye bakacağını ve hangi düzeltmeyi önce yapacağını bilecek. Amaç teorik bilgi yığmak değil; uyguladığınızda ölçülebilir sonuç veren, pratik bir yol haritası sunmaktır.

Largest Contentful Paint Tam Olarak Nedir?

Largest Contentful Paint, görüntülenen alanda (viewport) yer alan en büyük içerik öğesinin tarayıcı tarafından çizildiği anı, sayfa yüklemesinin başlangıcına göre ölçen bir zaman metriğidir. Burada anahtar kelime "en büyük"tür. Tarayıcı, sayfa yüklenirken aday öğeleri sürekli değerlendirir ve görünür alanda en geniş yüzeyi kaplayan öğeyi LCP öğesi olarak işaretler. Yükleme ilerledikçe daha büyük bir öğe boyandığında bu işaret güncellenir; ana içerik tamamen oturduğunda nihai LCP değeri belirlenir.

LCP öğesi olarak değerlendirilen başlıca öğe türleri şunlardır: <img> etiketleri, <svg> içindeki görsel öğeler, url() ile yüklenen arka plan görselleri olan bloklar, poster karesi olan <video> öğeleri ve büyük metin içeren blok düzeyindeki öğeler. Çoğu içerik ağırlıklı sayfada LCP öğesi bir kahraman görseli ya da büyük bir başlıktır.

Burada sık karıştırılan bir noktayı netleştirmek gerekir. LCP, sayfanın tamamının yüklendiği an değildir. Sayfanın altındaki onlarca görsel yüklenmeye devam ederken bile LCP çoktan tamamlanmış olabilir; çünkü LCP yalnızca ilk açılışta görünür olan alanı dikkate alır. Bu ayrım, doğru optimizasyon için kritiktir: kullanıcının ekranında görmediği şeyleri hızlandırmak LCP'yi düşürmez.

LCP, FCP ve diğer metriklerden nasıl ayrılır?

First Contentful Paint (FCP) ekranda boyanan ilk herhangi bir içeriği işaret ederken, LCP en büyük ve genellikle en anlamlı içeriği işaret eder. FCP "bir şeyler gelmeye başladı" der, LCP ise "asıl içerik geldi" der. Bu yüzden LCP, kullanıcının gerçek beklentisine FCP'den daha yakındır. Aynı şekilde, eski bir metrik olan ve etkileşim gecikmesini ölçen ölçütlerin yerini bugün INP almıştır; LCP ise tamamen yükleme hızıyla ilgilenir ve etkileşimi ölçmez.

LCP İçin İyi Değer Nedir?

Bir metriği iyileştirmeden önce hedefin ne olduğunu bilmek gerekir. LCP için yaygın olarak kabul edilen eşik değerler, sayfanın mobil ve masaüstündeki gerçek kullanıcı verilerine göre değerlendirilir. Aşağıdaki tablo bu eşikleri özetler.

LCP Değeri	Değerlendirme	Anlamı
2,5 saniye ve altı	İyi	Kullanıcı ana içeriği hızlıca görür, deneyim akıcıdır
2,5 - 4,0 saniye	İyileştirme gerekli	Gözle görülür gecikme var, terk oranı yükselmeye başlar
4,0 saniyenin üzeri	Zayıf	Ciddi yavaşlık, dönüşüm ve sıralama kaybı riski yüksek

Bu değerler değerlendirilirken bir incelik daha vardır: tek bir ziyaretin değil, gerçek kullanıcıların dağılımının 75'inci yüzdelik dilimi dikkate alınır. Yani ziyaretlerin yüzde 75'inde LCP'nin 2,5 saniye veya altında olması "iyi" sayılmanız için gereklidir. Bu yaklaşım, ortalamanın gizlediği kötü deneyimleri ortaya çıkarır; çünkü hızlı bağlantılı bir avuç kullanıcı, yavaş cihazlardaki çoğunluğun yaşadığı sorunu maskeleyemez.

Bir başka önemli ayrım, laboratuvar verisi ile saha verisi arasındadır. Laboratuvar testleri kontrollü bir ortamda, tek seferlik ölçüm yapar ve hata ayıklamak için idealdir. Saha verisi ise gerçek kullanıcıların gerçek cihaz ve bağlantılarından toplanır; sıralama açısından asıl önemli olan budur. İkisini birlikte kullanmak en sağlıklısıdır: saha verisi sorunun var olduğunu söyler, laboratuvar verisi nedenini bulmanıza yardımcı olur.

Yavaş LCP'nin Arkasındaki Dört Temel Neden

LCP'yi iyileştirmenin en etkili yolu, geçen sürenin nereye gittiğini anlamaktır. LCP süresi genellikle dört ana bileşene ayrılır ve her bir bileşen ayrı bir iyileştirme alanıdır:

1. Sunucu yanıt süresi (TTFB): Tarayıcı isteği gönderdikten sonra sunucunun ilk baytı yollaması ne kadar sürüyor. Yavaş bir sunucu, sonraki her şeyi geciktirir.
2. Kaynak yükleme gecikmesi: LCP öğesinin (özellikle bir görselin) keşfedilip indirilmeye başlanmasına kadar geçen süre. Tarayıcı kaynağı geç fark ederse, yükleme de geç başlar.
3. Kaynak yükleme süresi: LCP kaynağının indirilmesinin fiilen ne kadar sürdüğü. Büyük ve sıkıştırılmamış dosyalar burada zaman kaybettirir.
4. Öğe render gecikmesi: Kaynak indirildikten sonra tarayıcının onu ekrana çizmesine kadar geçen süre. Render'ı bloklayan kaynaklar bu aşamayı uzatır.

İyi haber şu ki, bu dört bileşenin toplamı LCP'yi verir; dolayısıyla en büyük payı alan bileşeni bulup ona odaklanmak, en hızlı kazanımı sağlar. Çoğu sitede LCP süresinin önemli bir kısmı, görselin geç keşfedilmesi ve render'ı bloklayan kaynaklardan kaynaklanır. Aşağıdaki bölümlerde her bir nedeni teker teker ele alacağız.

Sunucu Yanıt Süresini (TTFB) Hızlandırın

Largest Contentful Paint zincirinin ilk halkası sunucudur. Eğer ilk bayt 800 milisaniyede geliyorsa, hiçbir görsel veya CSS optimizasyonu bu kayıp süreyi geri kazandıramaz. Bu yüzden iyileştirmeye genellikle buradan başlamak mantıklıdır.

• Önbelleğe alma kullanın: Sayfa çıktısını ya da sık erişilen veriyi önbelleğe alarak sunucunun her istekte sıfırdan iş yapmasını engelleyin. Statik ya da nadiren değişen sayfalarda tam sayfa önbelleği çok etkilidir.
• CDN'den yararlanın: İçerik dağıtım ağı, dosyalarınızı kullanıcıya coğrafi olarak yakın sunuculardan servis eder. Bu, hem ağ gecikmesini hem de kaynak sunucunun yükünü azaltır.
• Veritabanı ve sunucu kodunu optimize edin: Yavaş sorgular, gereksiz harici API çağrıları ve ağır şablon işlemleri TTFB'yi şişirir. Yanıtı oluşturmadan önce yapılan işi mümkün olduğunca azaltın.
• Erken bağlantı kurun: Kritik üçüncü taraf alan adları için preconnect ipuçları kullanarak DNS çözümleme, TLS el sıkışması gibi adımların yükleme başlamadan tamamlanmasını sağlayın.

Bir başka güçlü teknik, sunucunun yanıtı parça parça göndermesidir. Sayfanın <head> kısmı hazır olur olmaz tarayıcıya gönderilirse, tarayıcı geri kalan içeriği beklerken CSS ve önemli kaynakları keşfedip indirmeye başlayabilir. Bu sayede sunucu hâlâ çalışırken tarayıcı boş durmaz.

LCP Görselini Erken Keşfettirin ve Önceliklendirin

Çoğu sitede LCP öğesi büyük bir görseldir ve en büyük gecikme, tarayıcının bu görseli geç fark etmesinden kaynaklanır. Tarayıcı HTML'i baştan sona okur; eğer kritik görsel CSS arkasında, JavaScript tarafından eklenen bir öğede ya da geç bir noktada gizliyse, indirme de geç başlar. Hedefiniz, bu görseli tarayıcıya olabildiğince erken ve net şekilde göstermektir.

Görseli doğrudan HTML'e koyun

LCP görselini bir <img> etiketiyle doğrudan HTML belgesine yerleştirin. Görsel JavaScript ile sonradan ekleniyorsa ya da CSS background-image olarak tanımlanmışsa, tarayıcının ön tarayıcısı (preload scanner) onu erkenden bulamaz. Görselin doğrudan HTML'de olması, en erken keşfedilmesini sağlar.

fetchpriority ile önceliği yükseltin

fetchpriority="high" özniteliği, tarayıcıya bu görselin en yüksek öncelikle indirilmesi gerektiğini söyler. Tarayıcılar varsayılan olarak görselleri düşük öncelikli sayma eğilimindedir; bu öznitelik LCP görselini öne çıkarır. Ancak bunu yalnızca tek bir öğeye, gerçek LCP öğesine uygulayın; her şeye yüksek öncelik vermek hiçbir şeye öncelik vermemekle aynı kapıya çıkar.

Lazy loading tuzağına düşmeyin

Tembel yükleme (lazy loading), ekran dışındaki görseller için harikadır ama LCP görseline asla uygulanmamalıdır. loading="lazy" özniteliğini ilk ekranda görünen büyük görsele koyarsanız, tarayıcı onu geciktirir ve LCP'niz ciddi şekilde bozulur. Kural basittir: ilk ekranda görünen kritik görseli eager (varsayılan) bırakın, geri kalanını tembel yükleyin.

Gerektiğinde preload kullanın

Görsel HTML'de hemen keşfedilemiyorsa, örneğin bir CSS arka planıysa, <link rel="preload"> ile tarayıcıya bu kaynağı erken indirmesini söyleyebilirsiniz. Duyarlı görseller için imagesrcset ve imagesizes öznitelikleriyle birlikte kullanmak, doğru boyuttaki dosyanın önceden yüklenmesini sağlar.

Görseli Verimli Servis Edin

LCP görselini erken keşfettirmek yarı yoldur; ikinci yarı, o görselin hızlı indirilmesidir. Burada amaç, görselin görsel kalitesini korurken dosya boyutunu mümkün olan en düşük seviyeye çekmektir.

• Modern formatları tercih edin: AVIF ve WebP gibi modern formatlar, eski JPEG ve PNG'ye kıyasla aynı kalitede çok daha küçük dosya boyutu sunar. Tarayıcı desteğine göre <picture> etiketiyle yedek format sağlayabilirsiniz.
• Doğru boyutta servis edin: Ekranda 600 piksel genişlikte görünecek bir görseli 3000 piksel genişlikte yüklemek saf israftır. srcset ve sizes öznitelikleriyle cihaza uygun boyutu gönderin.
• Sıkıştırmayı ayarlayın: Görselleri kalite kaybını gözle fark edilmeyecek bir seviyede sıkıştırın. Genellikle yüzde 75-85 arası kalite, dosya boyutu ile görünüm arasında iyi bir denge sunar.
• Boyut özniteliklerini belirtin: Görsele width ve height değerlerini vermek hem düzen kaymasını (CLS) önler hem de tarayıcının alanı önceden ayırmasını sağlar.

Eğer LCP öğeniz bir görsel değil de büyük bir metin bloğuysa, dikkatinizi yazı tiplerine çevirmelisiniz. Web fontları yüklenirken metnin görünmez kalması, LCP'yi geciktirir. font-display: swap kullanarak metnin önce sistem fontuyla anında görünmesini, font yüklendiğinde değiştirilmesini sağlayabilirsiniz. Kritik fontları preload ile erken yüklemek de metin tabanlı LCP için belirgin kazanç sağlar.

Render'ı Bloklayan Kaynakları Ortadan Kaldırın

Tarayıcı, sayfayı çizebilmek için CSS'in tamamını işlemesi gerektiğini varsayar. Bu yüzden CSS, doğası gereği render'ı bloklayan bir kaynaktır. Senkron yüklenen JavaScript de aynı şekilde ayrıştırmayı durdurur. Bu kaynaklar ne kadar büyük ve çok sayıdaysa, LCP öğesinin ekrana çizilmesi o kadar gecikir.

Kritik CSS'i satır içine alın

İlk ekranı çizmek için gereken minimum CSS'i belirleyip doğrudan HTML'in <head> kısmına satır içi (inline) olarak yerleştirebilirsiniz. Geri kalan, kritik olmayan stilleri ise asenkron yükleyerek render'ı bloklamasını engellersiniz. Bu sayede tarayıcı, harici bir CSS dosyasının inmesini beklemeden ana içeriği boyamaya başlar.

Kullanılmayan CSS ve JavaScript'i temizleyin

Birçok site, sayfanın gerçekte kullanmadığı yüzlerce kilobaytlık CSS ve JavaScript yükler. Kullanılmayan kodu tespit edip kaldırmak, hem indirme süresini hem de ayrıştırma yükünü azaltır. Büyük kütüphaneleri yalnızca gerçekten gerektiğinde, kod bölme (code splitting) ile parça parça yükleyin.

JavaScript'i erteleyin

Sayfanın ilk render'ı için gerekmeyen tüm betiklere defer ya da async özniteliği ekleyin. defer, betiğin HTML ayrıştırmasını engellemeden indirilmesini ve belge hazır olduğunda çalışmasını sağlar. Özellikle analitik, sohbet ve reklam betikleri gibi üçüncü taraf kodları neredeyse her zaman ertelenebilir.

Üçüncü taraf betikleri, kontrolünüzün en az olduğu ama LCP'yi en çok bozabilen unsurlardandır. Her eklediğiniz dış betik, ana iş parçacığını meşgul edebilir ve render'ı geciktirebilir. Sayfaya eklediğiniz her üçüncü taraf aracını "bu gerçekten ilk ekranda gerekli mi?" sorusuyla sorgulamak, çoğu zaman gereksiz yükü ortaya çıkarır.

İstemci Tarafı Render ve Geç Yüklemenin Etkisi

Tamamen istemci tarafında render edilen (client-side rendered) uygulamalarda LCP, ek bir engelle karşılaşır. Tarayıcı önce boş ya da iskelet bir HTML alır, ardından JavaScript indirilip çalıştıktan sonra içerik oluşturulur. Bu durumda LCP öğesi, JavaScript çalışana kadar var bile olmaz; dolayısıyla LCP doğal olarak gecikir.

Bu sorunu hafifletmek için sunucu tarafı render (SSR) ya da statik site üretimi (SSG) güçlü çözümlerdir. İçerik sunucuda önceden oluşturulup HTML olarak gönderildiğinde, tarayıcı JavaScript'i beklemeden LCP öğesini boyayabilir. Modern çatılar, ilk yüklemeyi sunucuda render edip ardından istemcide etkileşim kazandıran karma yaklaşımlar sunar; bu yaklaşım LCP açısından genellikle en sağlıklısıdır.

İstemci tarafı render kullanmak zorundaysanız, en azından ana JavaScript paketini küçük tutun, kritik içeriği önce render edin ve ekran dışı bileşenleri gecikmeli yükleyin. Ayrıca veri çekme işlemlerini paralel hale getirip kritik veriyi öne almak, ana içeriğin görünmesini hızlandırır.

LCP'yi Doğru Ölçmek ve İzlemek

Ölçemediğiniz şeyi iyileştiremezsiniz. LCP iyileştirme sürecinde doğru araçları kullanmak, hem sorunun kaynağını bulmanızı hem de yaptığınız değişikliklerin işe yarayıp yaramadığını görmenizi sağlar.

Saha verisi için tarayıcıların ve performans platformlarının topladığı gerçek kullanıcı ölçümleri (RUM) en değerli kaynaktır; çünkü gerçek cihaz ve bağlantı koşullarını yansıtır. Laboratuvar verisi için ise tarayıcı geliştirici araçlarındaki performans paneli ve standart performans denetim araçları işinizi görür. Bu araçlar size LCP öğesinin tam olarak hangi öğe olduğunu ve sürenin hangi bileşende harcandığını gösterir.

Pratik bir izleme yaklaşımı şu adımlardan oluşur:

1. Önce saha verisine bakarak gerçek kullanıcılarınızın LCP dağılımını ve 75'inci yüzdelik değerini öğrenin.
2. Sorunlu sayfaları laboratuvar aracında çalıştırarak LCP öğesini ve zaman dağılımını belirleyin.
3. En büyük payı alan bileşene (sunucu, keşif, yükleme veya render) yönelik bir düzeltme uygulayın.
4. Değişikliği yayınladıktan sonra hem laboratuvar hem saha verisinde sonucu doğrulayın.
5. İyileştirmeyi sürekli izlemeye alın; çünkü yeni eklenen bir görsel ya da betik metriği yeniden bozabilir.

Burada altını çizmek gereken nokta, LCP'nin tek seferlik bir iş olmadığıdır. Site içeriği büyüdükçe, yeni özellikler eklendikçe ve üçüncü taraf araçlar arttıkça LCP zamanla bozulabilir. Düzenli izleme, bu gerilemeyi erken yakalamanın tek yoludur.

Sıkça Sorulan Sorular

LCP ile sayfanın tamamen yüklenmesi aynı şey mi?

Hayır. LCP yalnızca ilk ekranda görünen en büyük içerik öğesinin boyandığı anı ölçer. Sayfanın altındaki görseller, betikler ve diğer kaynaklar yüklenmeye devam ederken bile LCP çoktan tamamlanmış olabilir. Bu yüzden kullanıcının ekranında görmediği öğeleri hızlandırmak LCP'yi düşürmez; odağınız her zaman ilk görünür alan olmalıdır.

LCP öğemin hangi öğe olduğunu nasıl bulurum?

Tarayıcının geliştirici araçlarındaki performans paneli, sayfa yüklemesini kaydederken LCP olarak işaretlenen öğeyi açıkça gösterir. Çoğu performans denetim aracı da raporunda "Largest Contentful Paint öğesi" başlığı altında bu öğeyi belirtir. Genellikle bu öğe büyük bir kahraman görseli ya da sayfanın en geniş metin bloğudur.

Lazy loading LCP'yi neden bozar?

Tembel yükleme, bir görselin yalnızca görünür alana yaklaştığında indirilmesini sağlar. Ancak LCP öğesi zaten ilk ekranda görünür durumdadır; ona loading="lazy" uygulamak, tarayıcının onu gereksiz yere geciktirmesine yol açar. Bu yüzden ilk ekrandaki kritik görseli her zaman hevesli (eager) yükleyin, tembel yüklemeyi yalnızca ekran dışı görsellere uygulayın.

Sunucum hızlı ama LCP hâlâ yüksek, neden?

Bu durumda gecikme büyük olasılıkla sunucudan sonraki aşamalardadır. En sık görülen nedenler şunlardır: LCP görselinin geç keşfedilmesi, render'ı bloklayan büyük CSS ve JavaScript dosyaları, optimize edilmemiş büyük görseller veya geç yüklenen web fontları. Laboratuvar aracında LCP zaman dağılımına bakarak hangi bileşenin en çok süre harcadığını görmek, kök nedeni netleştirir.

Mobil ve masaüstü LCP değerleri neden farklı?

Mobil cihazlar genellikle daha düşük işlemci gücüne ve daha değişken ağ koşullarına sahiptir. Aynı sayfa, mobilde JavaScript'i daha yavaş çalıştırır ve kaynakları daha geç indirir. Bu yüzden mobil LCP neredeyse her zaman masaüstünden daha yüksektir ve optimizasyon önceliğiniz çoğunlukla mobil deneyim olmalıdır.

LCP'yi iyileştirmek SEO sıralamamı doğrudan yükseltir mi?

LCP, core web vitals çerçevesinin bir parçasıdır ve sayfa deneyimi sinyalleri arasında değerlendirilir. Ancak sıralama tek bir metriğe değil, içerik kalitesi dahil birçok faktöre bağlıdır. İyi bir LCP, eşit kalitedeki sayfalar arasında size avantaj sağlar ve kullanıcı davranışını iyileştirerek dolaylı katkı sunar; fakat zayıf içeriği tek başına telafi etmez.

Sonuç

Largest Contentful Paint, bir sayfanın kullanıcıya ne kadar hızlı "açıldığını" en iyi özetleyen metriklerden biridir ve bu yüzden core web vitals içinde özel bir yere sahiptir. LCP iyileştirme çalışmasının özü, geçen sürenin nereye gittiğini anlamaktan geçer: sunucu yanıtı, kaynağın keşfi, indirilmesi ve ekrana çizilmesi. Bu dört aşamadan hangisinin en çok süre harcadığını bulduğunuzda, en yüksek getiriyi sağlayacak düzeltmeyi de bulmuş olursunuz.

Pratikte en sık karşılaşılan kazanımlar nettir: sunucu yanıtını önbellek ve CDN ile hızlandırmak, LCP görselini doğrudan HTML'e koyup fetchpriority ile önceliklendirmek, lazy loading tuzağından kaçınmak, görselleri modern formatlarda ve doğru boyutta servis etmek, render'ı bloklayan CSS ve JavaScript'i sadeleştirmek. Bu adımların her biri tek başına bile fark yaratır; birlikte uygulandığında ise LCP'nizi "zayıf" bölgeden "iyi" bölgeye taşıyabilir.

Son olarak unutmayın ki performans bir defalık proje değil, sürekli bir disiplindir. Gerçek kullanıcı verisini düzenli izleyin, her yeni özellik ve görsel eklendiğinde LCP'nin nasıl etkilendiğini kontrol edin ve gerilemeleri erken yakalayın. Bu alışkanlığı edindiğinizde, hızlı bir ilk izlenim hem ziyaretçilerinize hem de arama motorlarına sürekli olarak güçlü bir sinyal göndermeye devam edecektir.