Görsel Optimizasyonu: WebP AVIF Boyut ve Alt Metin

Bir sayfayı yavaşlatan şey çoğunlukla yazdığınız metin değil, metnin arasına koyduğunuz görsellerdir. HTTP Archive'ın web genelindeki ölçümlerinde görseller yıllardır sayfa ağırlığının en büyük tek kalemi olarak çıkıyor. Medyan bir mobil sayfanın yaklaşık 2 MB'lık toplam ağırlığının 881 KB'ı yalnızca görsellerden geliyordu; aynı ölçümde HTML, CSS, JavaScript ve yazı tiplerinin toplamı bu rakamın altında kalıyordu.

Ağırlık hikayenin yarısı. Diğer yarısı şu: mobil sayfaların yaklaşık %68'inde Largest Contentful Paint'i belirleyen eleman bir görsel. Yani kullanıcının "sayfa geldi" dediği an, çoğu zaman tek bir görselin inmesini beklediği andır. Görsel optimizasyonu bu yüzden kozmetik bir iş değil, sayfanın algılanan hızını doğrudan belirleyen bir iştir.

Konu tek bir ayar da değil. Birbirinden bağımsız çalışan dört kaldıraç var: hangi formatta sunduğunuz, hangi boyutta sunduğunuz, tarayıcıya önceden yer ayırtıp ayırtmadığınız ve görselin ne anlattığını metinle söyleyip söylemediğiniz. İlk üçü performansa, sonuncusu erişilebilirlik ve görsel aramaya çalışır. Pratikte bu dördü aynı torbaya konuyor ve en zayıf halka olan dosya adı gereğinden fazla, en güçlü halka olan format ile boyut seçimi gereğinden az konuşuluyor.

Hangi Görsel İçin Hangi Format

Format seçimi tek bir kazananı olan bir yarış değil. Görselin içeriği hangi sıkıştırma yönteminin işe yarayacağını belirler. Fotoğrafta insan gözünün fark etmediği detayı atmak serbesttir, keskin metin içeren bir ekran görüntüsünde aynı davranış okunabilirliği bozar.

Google Arama, img etiketinin src özelliğinde referans verilen görseller için BMP, GIF, JPEG, PNG, WebP, SVG ve AVIF biçimlerini destekliyor. Dosya adı uzantısının gerçek dosya türüyle eşleşmesi de öneriliyor; .jpg uzantılı bir WebP dosyası gereksiz bir belirsizlik kaynağıdır.

Görseli Base64 ile HTML içine gömmek ayrı bir seçenek. HTTP isteği sayısını düşürür, ancak Google'ın kendi uyarısı net: bu yöntem sayfa boyutunu önemli ölçüde büyütebilir. Gömülü görsel ayrıca ayrı önbelleğe alınamaz ve responsive olarak sunulamaz, bu yüzden yalnızca çok küçük ve her sayfada tekrarlanan varlıklar için düşünülmelidir.

WebP ile AVIF Arasındaki Gerçek Fark

WebP, VP8 video codec'inden türeyen tahmine dayalı kodlamayla kayıplı sıkıştırma yapar ve tekrar eden verinin yerine kısayol koyarak kayıpsız sıkıştırma da sunar. MDN'in verdiği ortalama değerler şöyle: görsel olarak benzer sıkıştırma seviyesinde kayıplı WebP dosyaları JPEG'den ortalama %25 ile %35 arasında küçük, kayıpsız WebP dosyaları ise aynı görselin PNG halinden tipik olarak %26 küçük. WebP şeffaflığı ve animasyonu da destekler.

AVIF, AV1 video codec'ine dayanan ve telif ücreti gerektirmeyen bir formattır. PNG ile JPEG'den belirgin biçimde iyi sıkıştırma sağlar, daha yüksek renk derinliğini, animasyonlu kareleri ve şeffaflığı destekler.

Buradan sonrası genelde atlanıyor. AVIF, WebP'ye kıyasla bir miktar daha iyi sıkıştırma verir, ancak iki gerçek dezavantajı vardır: tarayıcı desteği WebP kadar derin değildir ve aşamalı render (progressive rendering) desteklemez. Aşamalı render, JPEG'in yavaş bağlantıda önce kaba bir sürüm boyayıp sonra netleştirmesidir. AVIF'te bu yok, yani görsel ya gelir ya gelmez. Yavaş bağlantının yaygın olduğu bir kitlede bu, algılanan hız açısından ölçülmesi gereken bir takastır.

Sahadaki dosya boyutları da bu sırayı destekliyor. HTTP Archive'ın format bazında ölçtüğü değerlerde 90. yüzdelik dilimdeki görsel boyutları şöyle:

Bu tabloyu okurken bir şeyi karıştırmamak gerekiyor: bunlar aynı görselin dört formattaki hali değil. Sahada farklı sitelerin farklı görselleri ölçülüyor. AVIF sunma zahmetine giren ekipler genelde boyutlandırmayı ve kalite ayarını da düzeltmiş oluyor, dolayısıyla aradaki farkın tamamı codec'ten gelmiyor. Tablo yönü doğru gösterir, kesin bir dönüşüm oranı vermez. Kendi görselinizdeki gerçek kazancı öğrenmenin tek yolu aynı kaynak dosyayı kendi ayarlarınızla iki formatta üretip karşılaştırmaktır.

picture Elementi ile Kademeli Format Sunumu

Modern format kullanmanın tek güvenli yolu, desteklemeyen istemciye eski dosyayı verebilmektir. <picture> elementi tam olarak bunun için var. Tarayıcı listedeki desteklediği ilk <source> elemanını seçer ve geri kalanına hiç bakmaz:

<picture>
  <source type="image/avif" srcset="/gorsel/kanepe.avif">
  <source type="image/webp" srcset="/gorsel/kanepe.webp">
  <img src="/gorsel/kanepe.jpg"
       alt="Açık gri üç kişilik kanepe pencere önünde duruyor"
       width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Bu yapıda dikkat edilecek üç nokta var.

Sıra anlamlıdır. Tarayıcı yukarıdan aşağı ilk desteklediğinde durur, en iyi olanı aramaz. En verimli format en üstte olmalıdır. AVIF satırını WebP'nin altına koyarsanız AVIF destekleyen tarayıcı bile WebP indirir.

type özelliği zorunludur. Tarayıcı formatı MIME tipinden anlar (image/avif, image/webp) ve desteklemediği kaynağı indirmeden atlar. type yazılmazsa bu eleme yapılamaz ve kademe amacına ulaşmaz.

<img> isteğe bağlı değildir. Hem son yedektir hem de alt, width, height ve loading niteliklerinin taşıyıcısıdır. Google da her durumda src ile bir yedek adres belirtilmesini öneriyor, çünkü bazı istemciler bu yapıları anlamayabiliyor. <picture> elementinin kendisi tarayıcılarda 2016 Mart'ından beri geniş biçimde kullanılabilir durumda, dolayısıyla yedek ihtiyacı elementin desteğinden değil, formatın desteğinden doğar.

srcset ve sizes ile Gerçek Görüntülenen Boyutta Sunma

Format kazancını tek başına anlamsızlaştıran bir hata var: 2000 piksel genişliğindeki bir dosyayı ekranda 400 piksel yer kaplayan bir kutuya koymak. Tarayıcı görseli küçültüp gösterir, ama tam dosyayı indirir. AVIF'e geçerek kazandığınız yüzdeyi bu tek hata fazlasıyla geri alır.

srcset, tarayıcıya seçebileceği bir kaynak menüsü sunar. İki tür tanımlayıcı kullanılabilir ve bunlar aynı srcset içinde karıştırılmaz:

• x tanımlayıcısı ekran piksel yoğunluğunu belirtir (2x gibi). Yazılmadığında tarayıcı 1x varsayar.
• w tanımlayıcısı kaynağın piksel cinsinden genişliğini belirtir (800w gibi) ve sizes ile birlikte kullanıldığında hem değişken düzen genişliğini hem de ekran yoğunluğunu aynı anda çözer.

Aynı tanımlayıcı değerinin iki kez yazılması da geçersizdir. Sahada w tanımlayıcısı mobilde srcset'lerin %62'sinde, x ise %15'inde kullanılıyor; daha güçlü olanın yaygınlaşması iyi bir işaret.

<img src="/gorsel/kanepe-800.jpg"
     srcset="/gorsel/kanepe-400.jpg 400w,
             /gorsel/kanepe-800.jpg 800w,
             /gorsel/kanepe-1600.jpg 1600w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 50vw,
            600px"
     alt="Açık gri üç kişilik kanepe pencere önünde duruyor"
     width="1600" height="1067">

sizes en sık yanlış yazılan kısımdır. Tarayıcı görseli CSS'i tam olarak uygulamadan önce seçmek zorundadır, bu yüzden görselin düzende kaç piksel yer kaplayacağını ona siz söylersiniz. Kenar çubuğunda 300 piksel genişliğinde duran bir görsele sizes="100vw" yazmak, tarayıcıya "ekran kadar geniş olacağım" demektir ve en büyük dosyanın indirilmesine yol açar. sizes yanlışsa srcset zarar verir.

Çözünürlük değiştirme mi sanat yönetimi mi

İki farklı problem, iki farklı araç:

• Aynı görselin farklı boyutları gerekiyorsa <img> üzerinde srcset ve sizes yeterlidir.
• Farklı ekranda farklı kadraj gerekiyorsa (masaüstünde geniş manzara, mobilde kişiye yakınlaşan dikey kırpma) <picture> içinde media koşullu <source> elemanları kullanılır.

Bu ikisini karıştırmak yaygın bir tasarım hatasıdır. Mobilde küçülen geniş bir fotoğrafta özne tanınmaz hale geliyorsa çözüm daha küçük dosya değil, farklı kadrajdır.

width ve height Nitelikleri Layout Kaymasını Nasıl Önler

Düzendeki yeri kendi doğal boyutuna bağlı olan her <img>, sayfanın iki kez yerleşmesi riskini taşır: bir kez DOM ile CSS işlendiğinde, bir kez de görsel indiğinde ve gerçek boyutu öğrenildiğinde. Kullanıcının gözünde metnin aşağı zıplaması olarak görünen şey bu ikinci yerleşimdir ve Cumulative Layout Shift skorunu bozan en yaygın nedenlerden biridir.

Çözüm basit: width ve height niteliklerini yazın, ya da CSS aspect-ratio ile alanı önceden ayırın. Tarayıcı böylece görsel inmeden önce doğru miktarda yer ayırabilir.

Burada en sık görülen yanlış anlama şudur: width="1600" yazmak görselin ekranda 1600 piksel görüneceği anlamına gelmez. Bu nitelikler görselin doğal boyutunu bildirir, görüntüleme boyutunu değil. Modern tarayıcılar bu iki sayıdan en boy oranını hesaplar, dolayısıyla CSS'te aşağıdaki kuralı yazmaya devam edebilirsiniz:

img {
  max-width: 100%;
  height: auto;
}

Bu ikisi birlikte çalışır. Nitelikler oranı bildirir, CSS responsive davranışı yönetir. Yalnızca CSS aspect-ratio kullanmak da alan ayırır, ancak stil dosyası geç gelirse kısa süreli bir kayma riski kalır; nitelikler HTML ile birlikte geldiği için daha erken devreye girer.

Bu kadar ucuz bir çözüm olmasına rağmen saha verisi ilginç: mobilde <img> elemanlarının yalnızca %32'sinde hem width hem height tanımlı. İki yılda dört puanlık bir iyileşme var ama üçte iki oranındaki eksiklik, CLS sorunlarının neden bu kadar yaygın olduğunu tek başına açıklıyor. Görsellerin sayfa hızındaki toplam rolünü ve LCP tarafındaki karşılığını LCP süresini 2,5 saniyenin altına çekme rehberinde ayrıntılı ele aldık.

Alt Metnini Kim Okur ve Nasıl Yazılır

Alt metninin üç ayrı okuyucusu var ve üçü de aynı şeyi ister: görselin ne olduğunu değil, ne anlattığını.

Ekran okuyucu kullanan kişi. Görseli göremeyen kullanıcı için alt metni görselin yerine geçen içeriktir. Bilgi taşıyan bir görselin alt metni yoksa o bilgi o kullanıcı için sayfada hiç yoktur.

Google. Google'ın kendi dokümantasyonunda alt metni, bir görsel hakkında ek meta veri sağlamanın en önemli yolu olarak tanımlanıyor. Google görselin konusunu anlamak için alt metnini, bilgisayarlı görü algoritmalarını ve sayfanın içeriğini birlikte kullanıyor. Görsel bir bağlantı olarak kullanıldığında alt metni bağlantı metni işlevi de görebiliyor.

Sayfayı metin olarak okuyan yapay zeka sistemleri. Bu üçüncü okuyucu görece yeni ve en çok ihmal edileni. Bir üretken yapay zeka sistemi sayfanızı işlerken görselin kendisini değil, çevresindeki metni ve alt niteliğini görür. Argümanınızı bir grafik taşıyorsa ve alt metni "grafik" ise, o argüman metin katmanında hiç var olmamış demektir.

İyi ve kötü alt metni

Kural tek cümleyle özetlenebilir: spesifiklik anahtar kelime varlığını yener. Google alt niteliklerini anahtar kelimeyle doldurmaya karşı açıkça uyarıyor, bunun kötü kullanıcı deneyimi ürettiğini ve siteyi spam gibi gösterebileceğini söylüyor.

Son satır özellikle önemli. Dekoratif bir görselin alt niteliği boş bırakılır ama silinmez. Boş alt="" ekran okuyucuya "burayı atla" der ve kullanıcının akışını bozmaz. Nitelik hiç yoksa bazı ekran okuyucular çaresizlikten dosya adını okur, yani IMG-20240412-093311.jpg gibi bir dizeyi kullanıcının kulağına boşaltır.

Uzunluk için sabit bir sınır yok; görselin işlevini tarif edecek kadar yazılır. "Resmi", "görseli", "fotoğrafı" gibi başlangıçlar gereksizdir, çünkü ekran okuyucu elemanın zaten bir görsel olduğunu ayrıca duyurur. Satır içi <svg> öğelerinde alt niteliği yoktur; bunun yerine aria-labelledby ile bağlanan bir <title> elemanı kullanılır.

Sahadaki durum burada da iç açıcı değil. <img> elemanlarının %55'inde boş olmayan bir alt niteliği var, yani %45'inde hiç yok. Dahası, alt niteliği bulunanların önemli bir kısmı yalnızca dosya adı ya da anlamsız kısa dizeler taşıyor. İki yılda kaydedilen iyileşme bir puan.

Dosya Adının Gerçek Katkısı

Bu başlık genelde olduğundan büyük anlatılıyor, o yüzden Google'ın kendi ifadesiyle başlayalım: dosya adı, Google'a görselin konusuyla ilgili çok ufak ipuçları verebilir. İddianın tamamı bu. Gerçek bir katkı, ama küçük bir katkı ve sihir değil.

Doğru uygulama zaten ucuz olduğu için yapılmaya değer:

• Kısa ama betimleyici adlar kullanın. IMG00023.JPG yerine gri-keten-kanepe.jpg.
• image1.jpg, pic.gif, 1.jpg gibi genel adlardan kaçının.
• Kelimeleri tire ile ayırın ve küçük harf kullanın.
• Türkçe karakterlerden kaçının. ş, ğ, ı, ö, ü, ç içeren adlar URL'de yüzde işaretli kodlamaya dönüşür ve okunaksızlaşır. Latin alfabesi dışındaki karakterleri kullanmak zorundaysanız URL kodlama yönergelerine uyun.
• Binlerce görseli olan sitelerde adlandırmayı otomatikleştirmeyi değerlendirin.

Asıl önemli olan ise ne yapılmayacağı. Mevcut görsellerin dosya adını toplu değiştirmek bir URL değişikliğidir. Görsel arama sıralaması olan ya da dışarıdan bağlantı alan bir görselde bu, çok küçük bir kazanç için gerçek bir risk almaktır. Makul sıra şudur: yeni yüklenen görseller doğru adla girsin, mevcut görsellerde ise dosya adına dokunmak yerine alt metnini düzeltin. Alt metninin katkısı zaten kıyaslanamayacak kadar büyük.

Sıkıştırma Ayarını Pratikte Belirleme

Kalite ayarı için herkese uyan tek bir sayı yok, çünkü bozulmanın nerede görüneceğini görselin içeriği belirler. Gürültülü ve detaylı fotoğraflar agresif sıkıştırmayı gizler; düz gradyanlar, geniş tek renk alanlar ve keskin metin kenarları ilk bozulan yerlerdir.

İşe yarayan yöntem şudur: aynı kaynak dosyayı birkaç kalite seviyesinde üretin ve karşılaştırmayı görselin sayfada gerçekten görüneceği boyutta yapın. Yüksek çözünürlüklü bir ekranda dosyayı %100 yakınlaştırıp inceleyip sonra o görseli sayfada 400 piksel genişliğinde göstermek, gereksiz yere bayt harcamanın en kolay yoludur. Farkı o boyutta göremediğiniz en düşük ayar doğru ayardır.

Birkaç pratik kural daha:

• Kayıpsız sıkıştırmayı yalnızca birebir yeniden üretim gerektiğinde kullanın: metin içeren ekran görüntüleri, çizgi çalışmaları ve sonradan tekrar düzenlenecek dosyalar.
• Zaten kayıplı sıkıştırılmış bir dosyayı tekrar tekrar kodlamayın. Her tur kalite kaybını biriktirir. Tüm türevleri orijinal ana dosyadan üretin.
• İhtiyaç duymadığınız gömülü meta veriyi temizleyin. Renk profilleri şaşırtıcı biçimde yer kaplayabilir; modern formatlar aynı renk uzayı bilgisini dört baytlık bir sinyalle taşıyabiliyor.
• Sıkıştırmanın bir tavanı olduğu kadar bir tabanı da var. Google, yüksek kaliteli fotoğrafların kullanıcılara bulanık görsellerden daha çekici geldiğini ve net görsellerin sonuç küçük resminde daha cazip görünerek trafik alma olasılığını artırabileceğini belirtiyor. Bayt kovalarken görseli tanınmaz hale getirmek net bir kayıptır.

Google Görseller'de Görünürlük İçin Sayfa Tarafı Koşullar

Görsel arama görünürlüğü yalnızca görsel dosyasının özelliklerinden ibaret değil. Google, görselin konusuyla ilgili bilgiyi altyazılar ve görsel başlıkları dahil olmak üzere sayfanın içeriğinden çıkarıyor. Bunun pratik karşılığı şu: görseli konuyla ilgili metnin yakınına koyun ve görselin konusuyla alakalı bir sayfada yayınlayın. Doğru alt metnine sahip bir görsel, konuyla ilgisiz bir sayfada beklenen performansı vermez.

Diğer sayfa tarafı koşullar:

• Altyazı ve çevre metin. Görselin hemen altındaki açıklama satırı hem kullanıcı hem de sınıflandırma açısından alt metnini tamamlar.
• Yapılandırılmış veri. Ürün, tarif ve video gibi türlerde image alanı, Google Görseller'deki rozet ve zengin sonuçlara uygun olmak için zorunludur. Yapılandırılmış veri klasik arama özellikleri için işe yarar; yapay zeka cevaplarında alıntılanma garantisi olarak sunulamaz.
• CDN sahipliği. Görselleri bir CDN üzerinden sunuyorsanız CDN alan adının sahipliğini Search Console'da doğrulayın; aksi halde o alan adında bulunan tarama hataları size bildirilmez.
• Tekrar eden görseller. Aynı görsele büyük bir sitenin çok sayıda sayfasından referans veriliyorsa, Google'ın aynı dosyayı defalarca istemesine gerek kalmaması için önbellekleme yapılandırmasını gözden geçirin.

Ürün görselleri bu tablonun en yoğun kesişim noktası. Aynı görsel hem dönüşüme hem görsel aramaya hem de yapılandırılmış veriye çalışır; kategori ve ürün sayfalarındaki görsel disiplininin ticari karşılığını e-ticaret SEO rehberinde ayrıca ele aldık.

Yükleme Sırası ve LCP İlişkisi

Bir görseli optimize etmenin son adımı, tarayıcıya onu ne zaman indireceğini söylemektir. loading="lazy" ekranın altında kalan görseller için doğru araçtır: ilk yüklemede indirilmezler ve LCP için yarışan kaynak sayısını azaltırlar.

Tek bir istisna var ve bu istisna kritik: LCP görselini asla lazy yüklemeyin. Sayfanın en büyük görünen elemanını geciktirmek, tanım gereği LCP'yi geciktirir. Saha verisi bu hatanın ne kadar yaygın olduğunu gösteriyor: mobilde LCP'den sorumlu <img> elemanlarının %9,5'i yerel lazy yükleme kullanıyor. HTTP Archive bunu doğrudan sayfaları çok daha yavaşlatan bir anti-desen olarak niteliyor.

Doğru kurulum şöyle ayrışır:

• LCP görseli: loading="lazy" yok, fetchpriority="high" var, gerekirse <link rel="preload"> ile erken keşif sağlanır.
• Ekranın altındaki görseller: loading="lazy" ve decoding="async".
• Tek kaynak kuralı: preload yalnızca en kritik tek görsel için kullanılır. Birden fazla kaynağı öne almak onları birbiriyle yarıştırır ve LCP'yi geciktirebilir.

Görsellerin yükleme sırası, sayfanın genel render zincirinden bağımsız düşünülemez. Render'ı engelleyen kaynakların yönetimi ve geciktirilmiş yükleme stratejisinin bütününü kritik CSS'i satır içi yükleme rehberinde anlattık.

Hangi Adımı Önce Yapmalı

Yukarıdaki başlıkların hepsi doğru, ama hepsi aynı ağırlıkta değil. Etki büyüklüğünü sahadaki uygulanma oranıyla birleştirdiğimizde makul bir sıra çıkıyor. Aşağıdaki öncelik bir algoritma kuralı değil, etki ile eksiklik oranının kesiştiği yerden çıkan bir yargı:

İlk iki adım kod tarafında birer satırlık işlerdir ve ölçülebilir metrikleri doğrudan etkiler. Üçüncü ve dördüncü adım bir üretim hattı kurmayı gerektirir, çünkü elle üç format ve üç boyut üretmek sürdürülebilir değildir; bu iş görsel işleme katmanına ya da CDN'e devredilmelidir. Beşinci adım tek seferlik bir teknik iş değil, içerik üretim alışkanlığıdır. Altıncı adım ise yalnızca yeni dosyalar için geçerlidir ve mevcut dosyalarda peşine düşmeye değmez.

Sık Sorulan Sorular

AVIF sunmaya başlayınca JPEG dosyalarını silebilir miyim?

Hayır. <picture> kademesinin en alt basamağı olan <img src> dosyası, modern formatı desteklemeyen istemcilerin ve bazı üçüncü taraf araçların gördüğü tek adrestir. Yedeği silmek, kademenin varlık sebebini ortadan kaldırır.

WebP'ye geçmek mevcut görsel URL'lerimi bozar mı?

Bu tamamen yönteme bağlı. Eski dosyayı silip yerine yeni uzantılı dosya koyarsanız evet, URL değişir ve o görselin biriken değeri risk altına girer. <picture> yaklaşımında ise mevcut src adresine dokunulmaz, üstüne yeni <source> satırları eklenir. Bu ikincisi düşük riskli yoldur ve mevcut görsel arama konumunu korur.

CMS'im görselleri otomatik WebP'ye çeviriyor. Başka bir şey yapmam gerekiyor mu?

Evet. Otomatik dönüştürme yalnızca format kaldıracını çalıştırır. Görselin gerçek görüntüleme boyutunda sunulması, width ve height niteliklerinin doğru yazılması, sizes değerinin düzenle uyumlu olması ve alt metninin anlamlı olması hala sizin sorumluluğunuzdadır. Format tek başına en görünür ama tek kaldıraç değildir.

Alt metni ile title niteliği aynı şey mi?

Değil. title niteliği fareyle üzerine gelindiğinde çıkan bir ipucu metnidir, dokunmatik cihazlarda güvenilir biçimde görünmez ve alt metninin yerini tutmaz. Erişilebilirlik ve görsel arama açısından anlamlı olan nitelik alt niteliğidir. title yazmak alt eksikliğini telafi etmez.

Görselleri Base64 ile HTML'e gömmek performansı artırır mı?

Bazen, ama dar bir alanda. HTTP isteği sayısını azaltır; buna karşılık Google'ın da belirttiği gibi sayfa boyutunu önemli ölçüde büyütebilir. Gömülü görsel ayrıca tarayıcı önbelleğinde bağımsız olarak tutulamaz, srcset ile boyutlandırılamaz ve HTML'i her istekte şişirir. Yalnızca birkaç yüz baytlık, her sayfada tekrarlanan ikonlar için düşünmeye değer.

Görsel dosya boyutu için üst sınır ne olmalı?

Tek bir doğru sayı vermek yanıltıcı olur, çünkü sınırı görselin işlevi belirler. Anlamlı olan referans, sahada gözlenen dağılımdır: format bazında 90. yüzdelik dilimde JPEG dosyaları 270 KB civarındayken AVIF dosyaları 45 KB civarında kalıyor. Ekranın üstünde duran ve LCP'yi belirleyen görselinizin bu dağılımın üst ucunda olması, ölçülebilir bir hız maliyeti demektir. Hedefinizi mutlak bir sayıya değil, o görselin sayfada oynadığı role göre belirleyin.