Core Web Vitals · LCP Tanılama
LCP Görseli Nasıl Bulunur?
LCP öğesinin kim olduğunu bilmeden LCP sorununu çözmek mümkün değil. Sayfada hangi öğenin bu metriği tetiklediği değişkendir: büyük bir hero görseli olabilir, bir başlık metni olabilir, hatta bazen CSS ile yüklenen bir arka plan görseli bile LCP olarak işaretlenebilir. Tarayıcı bu kararı viewport'a göre verir ve öğe ilk kez ekranda tam görününce ölçer.
LCP tanılamasında çoğu zaman atlanan adım şudur: hangi öğenin ölçüldüğünü görmeden yapılan optimizasyonlar, yanlış hedefe yapılan müdahalelerdir. Görsel sıkıştırmaya zaman harcanırken asıl LCP kaynağı büyük bir h1 metniyse, o çalışma metriği hiç iyileştirmez. FCP ve LCP arasındaki farkı anlamak bu nedenle önemlidir; iki metrik farklı öğeleri ölçer ve farklı tanılama yolları gerektirir.
Neyse ki tarayıcı araçları ve dış test platformları LCP öğesini doğrudan gösterebilir. Hangi araçta ne aranacağını bilmek, tanılama sürecini belirgin biçimde kısaltır.
LCP öğesi sayfadan sayfaya farklılaşır
LCP, viewport içindeki en büyük içerik öğesinin yüklenmesini ölçer. Bu öğe sabit değildir; sayfa yapısına, cihaz genişliğine ve yükleme sırasındaki DOM durumuna göre değişir. Masaüstünde hero görsel LCP öğesiyken mobilde font yüklemesi gecikmesinden dolayı bir başlık metni öne geçebilir.
Tarayıcı LCP'yi hesaplarken şu öğe tiplerini dikkate alır: <img>, <video> öğesinin poster görseli, background-image içeren blok öğeler ve metin içeren block-level öğeler. Bunlardan hangisi viewport'ta en büyük görünür alanı kaplıyorsa ve ilk render'da veya erken yükleme aşamasında ortaya çıkıyorsa LCP adayı olur. Birden fazla aday varsa tarayıcı en büyük olanı seçer; bu seçim sayfa yüklenirken güncellenebilir.
Chrome DevTools ile LCP öğesini tespit etmek
Performance panelini açın, sayfayı kaydedin. Kayıt tamamlandıktan sonra zaman çizelgesinde "LCP" etiketli bir işaretleyici görürsünüz. Bu noktaya tıklayın; sağ panelde "Largest Contentful Paint" bölümü açılır ve hangi öğenin ölçüldüğü, boyutu ve zaman değeri listelenir.
Öğeye tıkladığınızda DevTools sizi DOM'daki ilgili öğeye götürür. Böylece hangi selector'a sahip, hangi görseli veya metni içerdiği anında görülür. Bu yöntem, tanılamanın en doğrudan yoludur; tarayıcının gerçekten hangi öğeyi ölçtüğünü başka yoruma bırakmaz. Elements panelindeki görselin kaynak URL'sini de bu adımda kopyalayabilirsiniz.
Lighthouse raporu LCP öğesini nasıl gösterir?
Lighthouse, LCP metriğini raporun üst kısmında performans skoru yanında verir. Ancak öğenin kendisini görmek için "Diagnostics" bölümüne inmek gerekir. Burada "Largest Contentful Paint element" adlı tanılama kartı, hangi DOM öğesinin LCP olarak işaretlendiğini ve bu öğenin yüklenme bileşenlerini gösterir.
Lighthouse raporunun bir sınırı vardır: lab ortamında, tek bir simüle koşulda ölçüm yapar. Gerçek kullanıcılarda farklı öğeler LCP olabilir. Bu farkın nedenlerini anlamak için Lighthouse ve gerçek kullanıcı verisi neden farklı çıkar? sayfası açıklayıcıdır. Lab verisi doğru öğeyi işaret etmeyebilir; bu nedenle alan verisiyle karşılaştırmak tanılamayı tamamlar.
PageSpeed Insights'ta LCP kaynağını okumak
PageSpeed Insights hem lab hem de alan verisi (CrUX) içerir. Lab verisi bölümündeki Lighthouse tanılaması LCP öğesini gösterir. Alan verisi bölümü ise gerçek kullanıcıların yaşadığı LCP dağılımını sunar; burada öğe düzeyinde bilgi bulunmaz ama hangi sayfalarda ciddi LCP sorunu olduğu görülür.
PSI'da dikkat edilmesi gereken nokta: alan verisi çoğunlukla köken (origin) bazında veya URL grubuna göre toplanır. Belirli bir sayfanın LCP öğesini tespit etmek için lab verisi daha güvenilirdir. Bununla birlikte, alan verisindeki p75 değerinin lab ölçümünden belirgin biçimde yüksek olduğu durumlarda gerçek kullanıcı ortamında farklı bir öğenin LCP'yi taşıdığı düşünülebilir.
WebPageTest filmstrip ile görsel doğrulama
WebPageTest, filmstrip görünümüyle sayfanın hangi anda nasıl göründüğünü kare kare sunar. LCP anını filmstrip üzerinde görebilir, o karedeki görsel durumu inceleyebilirsiniz. Waterfall görünümünde ise LCP öğesine karşılık gelen kaynak isteği zamansal konumuyla birlikte yer alır; bu görsel genellikle waterfall'da kırmızı düşey çizgiyle işaretlenir.
WebPageTest ile Lighthouse karşılaştırıldığında görülür ki filmstrip yöntemi, Lighthouse'un metin tabanlı tanılamasına göre LCP öğesinin görsel bağlamını doğrulamak açısından daha güçlüdür. Özellikle arka plan görseli veya dinamik olarak yüklenen içerik LCP olduğunda filmstrip bu ayrımı netleştirir.
LCP adayı olan öğe tipleri
Dört ana öğe tipi LCP adayı olabilir. İlki <img> etiketiyle yüklenen görseller; hero banner ve ürün görselleri bu gruba girer. İkincisi <video> öğesinin poster özelliğiyle belirlenen önizleme görseli. Üçüncüsü CSS background-image ile arka plan görseli yüklenen blok öğeler. Dördüncüsü ise büyük metin bloklarını kapsayan <p>, <h1>, <div> gibi block-level öğeler.
Öğe tipinin bilinmesi optimizasyon yöntemini doğrudan belirler. <img> tabanlı LCP için fetchpriority="high" veya preload eklemek anlamlıyken, metin tabanlı LCP için font yükleme stratejisi gözden geçirilmelidir. Arka plan görseli LCP ise CSS keşif gecikmesini azaltmak öncelik taşır.
Arka plan görseli LCP olduğunda tespit nasıl farklılaşır
CSS background-image ile yüklenen bir öğe LCP adayı olduğunda DevTools'ta görünüm biraz farklılaşır. DOM incelemesinde görselin src özelliği değil, Computed Styles içindeki background-image değeri kaynağı gösterir. Network panelinde bu görselin yüklenme zamanını takip etmek daha dikkat gerektirir çünkü kaynak doğrudan HTML'de değil, CSS parse aşamasından sonra keşfedilir.
Bu gecikme önemlidir: CSS background-image kaynakları, <img src> kaynaklarına göre daha geç keşfedilir. Tarayıcı önce HTML'i, ardından CSS'i indirir ve parse eder; görsel URL'yi ancak bu noktada öğrenebilir. Bu yapı LCP süresine doğrudan ek gecikme katar ve kritik CSS ve ilk boyama süresi ilişkisiyle doğrudan bağlantılıdır.
Metin bloğu LCP olduğunda farklılaşan tanılama
LCP bir metin öğesiyse sorun genellikle görsel değil font ile ilgilidir. Font yükleninceye kadar metin ya tamamen gizlenir (FOIT) ya da fallback fontla gösterilir (FOUT). Her iki durumda da metin öğesi tarayıcı tarafından "tam yüklenmiş" sayılmaz ve LCP zamanı uzar.
Performance panelindeki LCP işaretleyicisine bakıldığında, öğenin boyutu ve konumu erken bilinse de zaman damgasının font yüklemesi tamamlanana kadar uzadığı görülür. Çözüm yolunu bulmak için font-display değerini ve font preload yapılandırmasını incelemek gerekir. font-display: optional kullanıldığında font yüklenmeden mevcut fallback ile LCP zamanı kesilebilir; bu bazen en hızlı yoldur.
LCP gecikmesinin dört bileşeni
Chrome, LCP süresini dört bileşene ayırır: kaynak keşif gecikmesi (resource load delay), kaynak yükleme süresi (resource load time), render engeli (render delay) ve element render gecikmesi (element render delay). Bu bileşenler Performance panelinde LCP ayrıntı bölümünde görülebilir.
Hangi bileşenin büyük olduğuna göre müdahale yeri değişir. Kaynak keşif gecikmesi büyükse kaynağın preload veya fetchpriority="high" ile önceliklendirme yapılandırması incelenir. Kaynak yükleme süresi büyükse dosya boyutu ve CDN konumu değerlendirilir. Render engeli büyükse render-blocking kaynaklar veya JavaScript müdahalesi araştırılır. Dört bileşeni birlikte okumak, hangi adımın en fazla kazanım sağlayacağını gösterir.
LCP kaynağı ne zaman keşfediliyor?
LCP öğesinin kaynağının geç keşfedilmesi yaygın bir sorundur. Tarayıcının preload scanner'ı, HTML içindeki <img src> özniteliklerini erken okur. Ancak JavaScript ile dinamik olarak eklenen görseller, CSS background-image kaynakları veya loading="lazy" özelliğiyle işaretlenmiş öğeler geç keşfedilir.
loading="lazy" özelliği doğrudan hero görsele uygulandığında LCP skoru ciddi biçimde bozulur. Lazy loading kullanım rehberi incelendiğinde görülür ki bu özellik yalnızca viewport dışındaki görseller için tasarlanmıştır. İlk viewport'taki en büyük görsel için lazy loading hem preload scanner'ı devre dışı bırakır hem de yüklemeyi kasıtlı geciktirir; bu kombinasyon LCP'yi doğrudan olumsuz etkiler.
Mobil ve masaüstünde LCP öğesi farklılaşabilir
Viewport genişliği değiştiğinde farklı öğeler görsel büyüklük sıralamasını değiştirebilir. Masaüstünde yan yana gelen iki büyük görsel, mobil viewport'ta üst üste geldiğinde her ikisi de küçülür; bu sayfalarda belki de artık bir başlık metni en büyük öğe konumuna geçer.
Performans testini mobilde mi masaüstünde mi önceliklendirmeli? sorusunun LCP tanılamasıyla doğrudan bağlantısı budur: mobil viewport'ta LCP öğesi farklıysa, optimizasyon adımları da farklı olmak zorundadır. Her iki cihaz profilinde ayrı ayrı tanılama yapmak, cihaz tipine özgü sorunları gözden kaçırmanın önüne geçer.
A/B testi ve dinamik içerikte LCP tutarsızlığı
A/B testi araçları, kişiselleştirme sistemleri veya önbellek katmanları sayfanın ilk içeriğini kullanıcıya göre değiştirebilir. Bu değişiklik LCP öğesini de doğrudan etkiler. Bir varyasyonda hero görsel A varken diğerinde farklı bir görsel veya metin bloğu öne çıkabilir; her iki kullanıcı grubu farklı LCP değerleri yaşar.
Bu durum, CrUX verilerinde görülen LCP dağılımının neden geniş olduğunu da açıklar. Tek bir Lighthouse çalışmasının yakaladığı LCP öğesi tüm kullanıcıların gördüğü öğeyle örtüşmeyebilir. Böyle sayfalarda alan verisiyle lab verisi arasındaki sapma büyükse, dinamik içerik varyasyonları öncelikli inceleme konusu olmalıdır.
LCP öğesini bulduktan sonra ne yapılır?
LCP öğesini tespit etmek, sorunu yarı yol çözmektir. Öğenin tipi ve hangi bileşende gecikme olduğu bilindiğinde yapılacak iş netleşir. Görsel LCP ise kaynağın preload'u, boyutu, formatı ve önceliklendirmesi incelenir. Metin LCP ise font stratejisi ve font-display değeri gözden geçirilir. Arka plan görseli LCP ise CSS yükleme zincirini kısaltmak için kaynak yapılandırması değerlendirilir.
Performans sorununu düzeltirken önce neye bakılmalı? yazısında anlatılan tanılama sırası, LCP öğesi tespit edildikten sonra hangi adımların izleneceğini netleştirir. LCP öğesini bilmeden yapılan iyileştirme girişimleri çoğunlukla doğru hedefe ulaşmaz; tanılama, optimizasyondan önce gelmelidir.
Alan verisiyle lab tanılamasını karşılaştırmak
Lab araçları (DevTools, Lighthouse) kontrollü koşullarda tek bir LCP öğesi gösterir. Alan verisi ise gerçek kullanıcıların geniş bir profilini yansıtır: farklı cihazlar, farklı ağlar, farklı coğrafyalar. Bu iki kaynak arasındaki LCP değeri farkı büyüdüğünde, lab'da görülen öğenin gerçek kullanıcıların çoğu için LCP olmayabileceği düşünülmelidir.
Örneğin lab'da masaüstü profilinde hero görsel LCP iken CrUX verisi p75 değerinin çok yüksek olduğunu gösteriyorsa, mobil kullanıcılar farklı bir öğeyle karşılaşıyor olabilir. Bu senaryoda mobil Lighthouse çalışması ve WebPageTest mobil testi ek veri sunar. İki kaynağı birlikte kullanmak, tek araçla görülemeyen tutarsızlıkları ortaya çıkarır.
LCP öğesini bulmak tek seferlik bir adım değildir. Sayfa içeriği değiştiğinde, yeni bir bileşen eklendiğinde veya A/B testi başlatıldığında hangi öğenin LCP'yi taşıdığı da değişebilir. Önemli içerik değişikliklerinin ardından tanılamayı yenilemek, optimizasyon çalışmalarının daima doğru hedefe yönelik ilerlediğini güvence altına alır.
Araçlar arasındaki fark da göz ardı edilmemelidir. DevTools anlık ve yerel koşulda çalışır; WebPageTest gerçek ağ koşullarını simüle eder; alan verisi gerçek kullanıcıların deneyimini yansıtır. Üçünü birlikte kullanmak, tek bir araçla görülemeyen tutarsızlıkları ortaya çıkarır ve yanlış hedefe yapılan müdahalelerin önüne geçer.
LCP tanılaması, sayfanın yükleme sürecini anlamanın en doğrudan yollarından biridir. Hangi öğenin, hangi anda, neden geciktiği bilindiğinde çözüm seçenekleri de netleşir. Tahmine dayalı optimizasyon yerine gözleme dayalı müdahale hem daha az çaba gerektirir hem de daha öngörülebilir sonuçlar verir.