Görsel LCP neden yavaş? İstek keşfi, boyut ve WebP/AVIF seçimi

Kısa cevap: önce hangi bölümün büyük olduğuna bakın

Görsel LCP yavaşsa ilk refleks görseli küçültmek ya da WebP veya AVIF'e çevirmek oluyor. Bazen doğru bir hamle, ama web.dev'in LCP rehberi LCP süresinin dört alt bölüme ayrıldığını ve bunlardan kaynak yükleme süresinin, yani dosyanın inme süresinin, çoğu sitede anlamlı bir darboğaz olmadığını söylüyor. Yani önce teşhis gerekiyor: zaman sunucuda mı, görselin geç keşfedilmesinde mi, indirmede mi, yoksa çizimde mi harcanıyor?

Bu yazı, hızlı bir web deneyimi yazısındaki görsel bütçesi fikrinin devamı. O yazıda bir görsel bütçesi bölümü var; burada tek bir göstergeye, görsel LCP'ye ve onu yavaşlatan nedenleri birbirinden ayırmaya odaklanıyoruz: istek keşfi, boyut ve oran, biçim.

Son kontrol: 25 Ekim 2026. Yazıdaki rakamlar iki kaynaktan geliyor: web.dev ve MDN belgelerinden aktarılan eşikler ile yüzdeler, bir de açıkça "tasarım örneği" diye işaretlenen sentetik waterfall değerleri. Harici bir kullanıcı sitesi ya da gerçek bir performans artışı iddiam yok; bu yazı için gerçek bir tarayıcı ölçümü de yapmadım.

LCP ve dört alt bölüm

LCP, Largest Contentful Paint, görünür alandaki en büyük görselin, metin bloğunun ya da videonun çizilme zamanıdır. web.dev'e göre uygun öğeler arasında img öğeleri, svg içindeki image öğeleri, video poster görselleri, url() ile yüklenen arka plan görselleri ve metin içeren blok öğeler var. İyi LCP, ziyaretlerin %75'inde 2,5 saniye veya altıdır; 4,0 saniyenin üstü kötü sayılır. Ölçüm, mobil ve masaüstü olarak ayrılmış sayfa yüklemelerinin 75. yüzdeliğine bakar.

Google Arama'nın Core Web Vitals belgesi de aynı LCP hedefini (ilk 2,5 saniye), INP için 200 milisaniyenin altını ve CLS için 0,1'in altını yazıyor; bu metriklerin, başka sayfa deneyimi unsurlarıyla birlikte, çekirdek sıralama sistemlerinin ödüllendirmeye çalıştığıyla uyumlu olduğunu söylüyor. Bu bir sıralama garantisi değil, yalnızca bir hedef.

web.dev, LCP süresini dört alt bölüme ayırıyor. Bu ayrım teşhisin omurgası.

Lab ve saha farkı da burada önemli. web.dev, LCP'nin boşaltma süresini, bağlantı kurulumunu, yönlendirmeleri ve TTFB gecikmelerini de kapsadığını, sahada bu gecikmelerin anlamlı olabileceğini ve lab ile saha ölçümleri arasında fark çıkabileceğini yazıyor. Bu yüzden tek bir lab çalıştırmasının sonucu, gerçek ziyaretçilerin 75. yüzdeliğiyle aynı şey değildir.

Waterfall okumak: geç keşif ile uzun indirme farklı teşhislerdir

Yukarıdaki iki çubuk aynı dört bölümün iki farklı yüzünü gösteriyor. A örneğinde kaynak yükleme gecikmesi büyük: tarayıcı görseli geç buluyor. B örneğinde kaynak yükleme süresi büyük: tarayıcı görseli erken buluyor, ama dosya uzun sürede iniyor. İki durumun çözümü birbirinden farklı. İlkinde dosyayı küçültmek sorunu çözmez, ikincisinde de preload eklemek tek başına yetmez. Rakamlar sentetik bir tasarım örneğidir, bir ölçüm değildir.

Aynı hesabı küçük bir betikle yapabilirsiniz. Betik her senaryo için dört zaman damgasından (TTFB, kaynağın yüklenmeye başladığı an, bittiği an ve LCP anı) alt bölümleri çıkarıyor, paylarını yüzde olarak yuvarlıyor ve TTFB dışındaki en büyük bölümü yazıyor. Paylar yuvarlandığı için toplamları tam 100 olmayabilir.

01SCENARIOS = {02    "A": {"ttfb": 600, "resource_start": 1500, "resource_end": 2000, "lcp": 2100},03    "B": {"ttfb": 600, "resource_start": 700, "resource_end": 2200, "lcp": 2300},04}05 06for name, t in SCENARIOS.items():07    parts = {08        "ttfb": t["ttfb"],09        "load_delay": t["resource_start"] - t["ttfb"],10        "load_duration": t["resource_end"] - t["resource_start"],11        "render_delay": t["lcp"] - t["resource_end"],12    }13    assert sum(parts.values()) == t["lcp"]14    share = {key: round(100 * value / t["lcp"]) for key, value in parts.items()}15    after_ttfb = {key: value for key, value in parts.items() if key != "ttfb"}16    print(name, parts, "total", t["lcp"])17    print(" share", share)18    print(" load_delay_share_over_10", share["load_delay"] > 10, "render_delay_share_over_10", share["render_delay"] > 10)19    print(" largest_after_ttfb", max(after_ttfb, key=after_ttfb.get))20 

01A {'ttfb': 600, 'load_delay': 900, 'load_duration': 500, 'render_delay': 100} total 210002 share {'ttfb': 29, 'load_delay': 43, 'load_duration': 24, 'render_delay': 5}03 load_delay_share_over_10 True render_delay_share_over_10 False04 largest_after_ttfb load_delay05B {'ttfb': 600, 'load_delay': 100, 'load_duration': 1500, 'render_delay': 100} total 230006 share {'ttfb': 26, 'load_delay': 4, 'load_duration': 65, 'render_delay': 4}07 load_delay_share_over_10 False render_delay_share_over_10 False08 largest_after_ttfb load_duration

A senaryosunda kaynak yükleme gecikmesinin payı %43. web.dev'in yönergesi bu bölümün %10'dan az olmasını öneriyor; yani A, geç keşfin ilk şüpheli olduğu bir örnek. B'de gecikme yalnızca %4 ve en büyük bölüm kaynak yükleme süresi, yani indirme. Bu iki hükmü sıralamak için toplama bakmayın: A'nın toplamı 2100 ms, B'ninki 2300 ms, ama teşhis toplamdan değil, hangi bölümün büyük olduğundan çıkıyor.

Bir uyarı daha: 2,5 saniyelik eşik, ziyaretlerin 75. yüzdeliği için tanımlı. Bu örneklerin toplamları 2,5 saniyenin altında olsa bile bu "iyi" demek değildir; tek bir çalıştırma bir yüzdelik değildir. Örnek yalnızca alt bölümleri ayırmayı gösteriyor.

İstek keşfi: görsel HTML'de görünmeli, gecikmemeli

Kaynak yükleme gecikmesini azaltmanın temeli, LCP görselinin ilk HTML yanıtında keşfedilebilmesi. web.dev keşfedilemeyen durumları sayıyor: JavaScript ile eklenen bir img, data-src ile geç yüklenen görseller ve CSS arka plan görselleri. MDN de nedenini anlatıyor: tarayıcı sayfa yüklenirken CSS ve JavaScript'i yorumlamaya başlamadan önce görselleri indirmeye başlıyor; bu yüzden seçimin bildirimsel olması, yani HTML'de görünmesi gerekiyor.

loading="lazy", MDN'ye göre görselin görünür alana belirli bir uzaklığa gelene dek ertelenmesini söyler. Bu, sayfanın aşağısındaki görseller için yararlı; LCP görseli için tam tersi. web.dev "LCP görselini asla tembel yüklemeyin" diyor, çünkü bu her zaman gereksiz bir kaynak yükleme gecikmesi yaratır.

fetchpriority="high", MDN'ye göre bir ipucu: görselin diğer görsellere göre yüksek öncelikle çekilmesini ister. web.dev, LCP öğesi olması muhtemel bir img için bunun iyi bir fikir olduğunu, ama bir ya da ikiden fazla görselde yüksek öncelik vermenin öncelik ayarını yararsız kıldığını yazıyor. Erken ama görünmeyen görsellere (örneğin bir carousel'in sonraki slaytlarına) fetchpriority="low" verilebilir.

Preload ise koşullu bir araç. web.dev, görselin yalnızca harici bir CSS ya da JavaScript dosyasından başvurulduğu durumda preload önerir; görsel zaten HTML'de bir img olarak görünüyorsa tarayıcı onu erken keşfeder. MDN, aynı kaynağın birden çok türü için preload yapmayı önermiyor: çoğunluğun kullanacağı tür için yapın. Preload bir dosyanın indirilmesini zamanlar; yanlış dosya için preload, yanlış dosyayı indirir.

Aşağıdaki betik, sentetik bir HTML'deki img öğelerini tarıyor ve şu nedenleri işaretliyor: görselin HTML'de görünmemesi, loading="lazy", eksik width ya da height, sizes olmadan genişlik tanımlayıcılı srcset (bu durumda MDN'ye göre varsayılan 100vw geçerli) ve fetchpriority="high" sayısı. Bu bir sezgiseldir: HTML'deki ilk görsel LCP adayı olabilir, ama gerçek LCP öğesi sayfa çizildikten sonra belli olur.

01import re02from html.parser import HTMLParser03 04PAGE = """<body>05<img src="/img/hero-1600.jpg" loading="lazy" alt="Hero" width="1600" height="800">06<img data-src="/img/banner.jpg" alt="Banner">07<img src="/img/photo-800.avif" srcset="/img/photo-800.avif 800w, /img/photo-1600.avif 1600w"08     sizes="(width <= 600px) 100vw, 800px" width="800" height="450" fetchpriority="high" alt="Photo">09<img src="/img/thumb.jpg" srcset="/img/thumb-400.jpg 400w, /img/thumb-800.jpg 800w" width="400" alt="Thumb">10</body>"""11 12 13class Images(HTMLParser):14    def __init__(self):15        super().__init__()16        self.images = []17 18    def handle_starttag(self, tag, attrs):19        if tag == "img":20            self.images.append(dict(attrs))21 22 23parser = Images()24parser.feed(PAGE)25high = 026for number, img in enumerate(parser.images, 1):27    flags = []28    if "src" not in img and "srcset" not in img:29        flags.append("not_discoverable_in_html")30    if img.get("loading") == "lazy":31        flags.append("lazy")32    if "width" not in img or "height" not in img:33        flags.append("no_dimensions")34    if re.search(r"\d+w\b", img.get("srcset", "")) and "sizes" not in img:35        flags.append("default_sizes_100vw")36    if "sizes" in img and "srcset" not in img:37        flags.append("sizes_without_srcset")38    high += img.get("fetchpriority") == "high"39    print(number, img.get("src") or img.get("data-src"), ",".join(flags) or "ok")40print("fetchpriority_high", high)41 

011 /img/hero-1600.jpg lazy022 /img/banner.jpg not_discoverable_in_html,no_dimensions033 /img/photo-800.avif ok044 /img/thumb.jpg no_dimensions,default_sizes_100vw05fetchpriority_high 1

Çıktıda ilk görsel tembel yükleniyor: bu görsel sayfanın üstündeyse LCP adayı olabilir ve kaynak yükleme gecikmesi yaratır. İkinci görselin src'si yok, adres yalnızca data-src içinde; HTML'den keşfedilemiyor. Üçüncü görsel temiz. Dördüncüsünde height yok ve genişlik tanımlayıcılı bir srcset var ama sizes yok. Betik düzeltmeyi söylemez; hangi görsele bakmanız gerektiğini gösterir.

Boyut ve oran: srcset, sizes, width ve height

Üç karar görsel hâlâ HTML'deyken verilir: hangi dosya (boyut), ne kadar yer (oran) ve hangi biçim. Aşağıdaki şema üçünü yan yana koyuyor.

srcset ve sizes birlikte çalışır. MDN'ye göre srcset, tarayıcının seçebileceği dosyaları ve genişliklerini (800w gibi, px değil w birimiyle) tanımlar; sizes ise hangi ekran koşulunda görselin ne kadar yer kaplayacağını söyler. Tarayıcı ekran boyutuna, piksel yoğunluğuna, yakınlaştırma düzeyine, yöne ve ağ hızına bakar, ilk doğru olan koşulun slot boyutunu kullanır ve piksel yoğunluğunu da dikkate alarak uygun adayı seçer. Seçimi yalnızca dosya genişliğini CSS slot genişliğiyle karşılaştırarak tahmin etmeyin; yüklenen adayı Network panelinde doğrulayın. Seçimi tarayıcı yapar; siz seçenekleri ve ipuçlarını verirsiniz.

İki kural sık atlanıyor. srcset içindeki w değeri dosyanın içsel genişliğiyle eşleşmeli ve sizes yalnızca genişlik tanımlayıcılarıyla kullanılmalı; genişlik ile yoğunluk (x) tanımlayıcılarını karıştırmak yanlış. sizes verilmezse varsayılan 100vw, yani görsel tüm görünüm alanı genişliğinde varsayılır; görsel aslında bir sütunda küçük duruyorsa tarayıcı gereğinden büyük bir dosya seçebilir.

01<picture>02  <source type="image/avif"03          srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"04          sizes="(width <= 800px) 100vw, 800px">05  <img src="/img/hero-800.jpg"06       srcset="/img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w"07       sizes="(width <= 800px) 100vw, 800px"08       width="800" height="450" fetchpriority="high"09       alt="Sentetik hero görseli">10</picture>

Örnekte picture içindeki source AVIF'i type ile bildiriyor; tarayıcı bu türü desteklemiyorsa o kaynağı atlayıp img içindeki JPEG adaylarına geçiyor. img üzerinde width ve height var; görsel hero olduğu için loading yok (varsayılan eager) ve fetchpriority="high" tek görselde. Adresler sentetik; bu işaretleme sizin sayfanızda sınanmadan kopyalanacak bir şablon değil.

width ve height öznitelikleri görselin içsel boyutunu verir. MDN'ye göre bunlar, tarayıcının görsel inmeden önce en-boy oranını hesaplamasını sağlar; yer ayrılır ve düzen kayması azalır ya da önlenir. web.dev, görsel ve video öğelerinde her zaman width ve height kullanmayı ya da CSS aspect-ratio kullanmayı öneriyor; Chrome bunu DevTools'ta aspect-ratio: auto 640 / 360 gibi gösteriyor. CLS için iyi eşik, ziyaretlerin %75'inde 0,1 veya altı. Oran doğrudan LCP süresini değil CLS'yi ilgilendirir; yine de iki metriği birlikte izlemek gerekir.

Biçim: AVIF, WebP, PNG ve JPEG bağlama göre seçilir

MDN'nin görsel biçimleri rehberi basit bir ilke veriyor: raster görsellerde WebP ya da AVIF genellikle PNG, JPEG ve GIF'ten daha iyi sıkıştırır; ekran görüntüsü, diyagram, logo ve çizgi çizimde kayıpsız kodlama tercih edilir, çünkü metin ve keskin kenarlardaki bulanıklık ve renkli saçaklar çok görünür; fotoğraf gibi sürekli tonlu görseller çoğu zaman kayıplı sıkıştırmayı kaldırır. Aşağıdaki tablo bu rehberi özetliyor.

AVIF'in aşamalı işlemeyi desteklememesi, dosyanın tamamı inmeden gösterilememesi demek; bu yüzden biçimi yalnızca dosya boyutuna bakarak seçmeyin. Biçim yedeği için picture ve type kullanın: MDN, WebP, AVIF ya da JPEG XL'i desteklemeyen tarayıcılar için PNG ya da JPEG yedeği öneriyor. Tarayıcı desteği sürüm listeleri zamanla değiştiği için güncel listeye MDN'den bakın; bu yazı sürüm numarası vermiyor.

WebP'yi PNG'ye çevirmek bir hız ya da kalite hamlesi değildir. Kayıplı bir WebP dosyasında kaybolan ayrıntı PNG'ye çevrildiğinde geri gelmez; PNG kayıpsızdır ama yalnızca elinizdeki, zaten kayıplı pikselleri kayıpsız saklar. Dosya da büyüyebilir, yani hız beklentisi yanlış olur. Bir iş akışınız ya da aracınız PNG istiyorsa WebP PNG dönüştürücü dönüşümü tarayıcıda yapar; sayfanın LCP görseli için ise önce yukarıdaki dört bölümden hangisinin büyük olduğuna bakın.

Görseli küçültmek için resim küçültme aracı JPG ya da WebP çıktısı verir ve önceki ile sonraki boyutu karşılaştırır; sonucu kendi sayfanızda yeniden ölçmeden bir kazanç saymayın. Paylaşım görseli (Open Graph) ise LCP görselinden ayrı bir iştir: Open Graph görseli oluşturucu tam 1200×630 piksellik görsel üretir.

Ölçüm: lab, saha ve tek fixture

Bir iyileştirme iddiasını destekleyen şey, aynı koşullarda yapılan önce-sonra ölçümüdür. LCP için iki tür veri var. Lab verisi kontrollü bir ortamda tek bir çalıştırmadır; saha verisi gerçek ziyaretçilerden gelir ve 75. yüzdelikle özetlenir. Google'ın Core Web Vitals belgesi Search Console'daki Core Web Vitals raporuna işaret ediyor; web.dev ise lab ile saha arasında fark çıkabileceğini belirtiyor.

Tek bir fixture, yani tek sayfa, tek cihaz ve tek ağ koşulu, yalnızca o koşulun sonucudur. "Bu sayfada AVIF LCP'yi düşürdü" cümlesi yalnızca ölçtüğünüz koşulda doğrudur; tüm kullanıcılar için doğru olduğunu söylemek için saha verisi gerekir. Bu yazının hiçbir yerinde gerçek bir ölçüm sonucu yok.

Sıralama konusunda da dikkatli olun. Core Web Vitals, Google'ın belgesine göre başka sayfa deneyimi unsurlarıyla birlikte çekirdek sıralama sistemlerinin ödüllendirmeye çalıştığıyla uyumlu; bu, bir LCP iyileştirmesinin sıralamayı yükselteceği anlamına gelmez.

Sınırlamalar ve uygulama kontrol listesi

Bu yazının sınırları açık. Gerçek bir tarayıcı ölçümü yapmadım; waterfall rakamları sentetik tasarım örneğidir. Kaynaklar web.dev, MDN ve Google Arama belgeleri; eşikler ve biçim bilgileri 25 Ekim 2026'daki hâlleriyle yazıldı. CDN, sunucu, INP, decoding ve duyarlı preload gibi konuları doğrulamadığım için anlatmadım. Hiçbir madde bir hız, LCP ya da sıralama garantisi değil. Astro gibi bir araçla site kuruyorsanız uygulamalı rehber ayrı bir konu; bu kontrol listesi üretilen HTML'e bakar.

• LCP öğesini ölçümden tanıdınız; HTML'deki ilk görseli LCP öğesi diye varsaymadınız.
• LCP görseli ilk HTML yanıtında img ya da source olarak görünüyor; data-src, JavaScript ile ekleme ya da CSS arka planı değil.
• LCP görselinde loading="lazy" yok.
• fetchpriority="high" en çok bir ya da iki görselde var.
• Preload yalnızca kaynak harici CSS ya da JavaScript'ten başvuruluyorsa kullanılıyor; aynı görselin birden çok türü için preload yok.
• srcset içindeki w değerleri dosya genişliğiyle eşleşiyor; sizes görselin gerçek slot genişliğini söylüyor.
• width ve height (ya da aspect-ratio) var; oran görsel inmeden belli.
• Biçim bağlama göre seçildi, yedek picture ile sağlandı; kayıplı WebP'den PNG üretmenin hız ya da ayrıntı kazandıracağı varsayılmıyor.
• Lab ve saha sonuçları ayrı raporlanıyor; tek fixture sonucu genel kullanıcı sonucu gibi sunulmuyor.