Fetchpriority Nedir, LCP’de Ne Zaman Kullanılır?

LCP zayıfsa, sorun her zaman görsel boyutu değildir. Bazen asıl problem, tarayıcının doğru kaynağı geç istemesi ya da daha düşük sıraya koymasıdır.

Bu noktada fetchpriority işe yarar. Doğru tek kaynağa verildiğinde LCP’yi öne çekebilir. Fakat her yere eklenirse tarayıcının işini zorlaştırır. Önce bu özelliğin ne yaptığını netleştirelim.

Fetchpriority nedir ve tarayıcı ne yapar?

fetchpriority, tarayıcıya bir kaynağın göreli önemini anlatan bir HTML ipucudur. En yaygın kullanım alanı görsellerdir. Değer olarak genelde high, low ve varsayılan davranışı bırakan auto kullanılır.

Buradaki kritik nokta şu, bu bir komut değil, ipucudur. Tarayıcı yine son kararı kendi planlayıcısıyla verir. Çünkü aynı anda CSS, font, script, görsel ve üçüncü taraf istekleri yarışır. Tarayıcı da bunları render sırası, görünür alan, kaynak türü ve mevcut ağ koşullarına göre dengeler.

Tarayıcı önceliği nasıl belirler?

HTML ayrıştırılırken bazı kaynaklar hemen görünür. CSS dosyaları çoğu zaman erken ve yüksek öncelikle alınır, çünkü render’ı bekletirler. Ancak bir görselin LCP adayı olduğunu tarayıcı her zaman ilk anda anlamaz. Görsel DOM’da aşağıdaysa, picture içinde geliyorsa, srcset seçimi bekleniyorsa ya da CSS arka planı olarak kullanılıyorsa istek gecikebilir.

İşte fetchpriority="high" burada devreye girer. Tarayıcıya, “bu kaynağı daha erken sıraya al” demiş olursunuz. Bu nedenle, LCP öğesi bir hero image ise küçük ama etkili bir fark yaratabilir.

Yine de her sayfada sonuç aynı olmaz. Modern tarayıcıların çoğu bu ipucunu tanır, ama davranış ayrıntıları motorlara göre değişebilir. Bu yüzden kararları sadece teoriyle değil, testle vermek gerekir. Network panelinde istek önceliğini ve LCP zamanını birlikte kontrol edin.

LCP görselinde ne zaman gerçekten işe yarar?

LCP, kullanıcıya görünen en büyük içerik öğesinin ne kadar hızlı çizildiğini ölçer. İyi eşik genelde 2,5 saniye ve altıdır. Pek çok sayfada bu öğe hero görseli, ürün ana görseli ya da haber manşet görseli olur.

fetchpriority="high" şu durumlarda iyi adaydır:

• Sayfanın üst kısmında büyük bir görsel varsa
• Bu görsel gerçek LCP öğesiyse
• Görsel ilk HTML içinde yer alıyorsa
• Sorun dosya boyutundan çok, geç istek başlamasından kaynaklanıyorsa

Hero image için doğru HTML örneği

Temel kullanım sade görünür: <img src="/images/hero.webp" alt="Yeni ürün tanıtımı" width="1280" height="720" fetchpriority="high">

Burada iki ayrıntı daha var. İlk olarak, LCP görseline loading="lazy" vermeyin. İkinci olarak, width ve height tanımlayın. Böylece CLS tarafında da sorun çıkarmazsınız. decoding="async" eklemek bazı durumlarda yardımcı olabilir, ama ana farkı çoğu zaman istek zamanlaması yaratır.

Duyarlı görsellerde de mantık aynı kalır. Örnek olarak şu yapı kullanılabilir: <img src="/hero-1280.webp" srcset="/hero-640.webp 640w, /hero-1280.webp 1280w, /hero-1920.webp 1920w" sizes="100vw" alt="Kampanya görseli" width="1280" height="720" fetchpriority="high">

Eğer görsel ilk ekranda değilse, kazanç beklemeyin. Benzer şekilde LCP öğesi bir görsel değil, büyük bir metin bloğuysa bu öznitelik çözüm olmaz. Uygulama örnekleri için fetchpriority ve LCP hero image notu faydalı bir referans sunuyor.

Bir başka sınır da şudur, görsel JavaScript ile geç ekleniyorsa önce mimariyi düzeltmek gerekir. Geç hydrate edilen bir bileşende high kullanmak, geç keşif sorununu tek başına çözmez.

Preload ile farkı nedir?

preload ve fetchpriority sık karıştırılır, ama aynı işi yapmazlar. preload, tarayıcıya bir kaynağı daha erken keşfettirir. fetchpriority ise keşfedilmiş bir kaynağın sıradaki yerini etkiler.

Kısa tablo farkı netleştirir:

Durum	Daha uygun araç	Neden
HTML içindeki hero görseli	fetchpriority="high"	Kaynak zaten bulunur, önceliği artar
CSS arka planındaki hero görseli	preload	Tarayıcı görseli CSS çözülene kadar göremez
Geç keşfedilen ve çok önemli görsel	preload + fetchpriority="high"	Hem erken keşif hem daha yüksek sıra sağlanır
Sayfa altı dekoratif görseller	Hiçbiri	Erken bant genişliği boşa gider

Örneğin LCP görseliniz CSS arka planındaysa, yalnızca fetchpriority çoğu zaman yetmez. Çünkü görsel isteği CSS indirildikten ve ayrıştırıldıktan sonra başlar. Böyle bir durumda şu yaklaşım daha mantıklıdır: <link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

Duyarlı görsellerde preload kullanıyorsanız imagesrcset ve imagesizes eşleşmesini doğru kurun. Aksi halde tarayıcı ayrı bir ön yükleme ve ayrı bir gerçek istek açabilir. Bu da yarardan çok zarar verir.

Bir başka nokta da şu, preload erken keşif sağlar ama LCP’yi tek başına garanti etmez. Sunucu yanıtı yavaşsa, ana CSS blokluyorsa ya da görsel aşırı ağırsa darboğaz başka yerdedir. WordPress tarafında da benzer mantık tartışıldı; fetchpriority ile LCP görseli önerisi bunu pratik bir çerçeveye oturtuyor.

Yanlış kullanım neden LCP’yi kötüleştirir?

En sık hata, bir sayfadaki birden fazla görsele fetchpriority="high" vermektir. Karusel görselleri, ürün listeleme küçük resimleri, logo, rozetler ve sayfa altı medya dosyaları aynı anda “yüksek” olursa, artık hiçbirinin önceliği net değildir.

Aynı sayfada üç ya da beş kaynağa birden fetchpriority="high" vermek, tarayıcıya yardım etmekten çok gürültü üretir.

Bu gürültü pahalıya mal olur. Çünkü erken ağ penceresi sınırlıdır. Mobilde bağlantı daha dar olur. İlk istekler arasında gereksiz görseller yükselirse, asıl kritik kaynaklar geriye düşebilir. Bazen ana CSS, bazen font, bazen de gerçek LCP görseli bundan etkilenir.

Yanlış kullanım örnekleri sık görülür:

• Tüm kart görsellerine bileşen düzeyinde high eklemek
• Her karusel slaydını yüksek öncelikli yüklemek
• Sayfa üstünde görünmeyen görsellere high vermek
• Üçüncü taraf iframe’leri ya da reklam yaratıcılarını erkene çekmek
• LCP olmayan bir görseli yalnızca büyük olduğu için öne almak

Aşırı kullanım INP tarafını da dolaylı etkileyebilir. Çünkü daha fazla erken istek, daha fazla parse, daha fazla rekabet demektir. Bu nedenle fetchpriority, tek başına bir hız sihri değil, hassas bir ayar düğmesidir.

Hangi kaynakların gerçekten kritik olduğunu sistemli biçimde ele almak istiyorsanız, Core Web Vitals odaklı hız optimizasyonu yaklaşımı bu kararları sayfa şablonu düzeyinde toplar. Ayrıca ağ önceliklerini doğrulamak için DevTools’ta Fetch Priority ayıklama videosu pratik bir kontrol sunar.

Kısa kontrol listesi ve karar matrisi

Uygulama öncesinde kısa bir akış izlemek hatayı azaltır. Sadece tek bir satır eklemek yerine, önce gerçek darboğazı bulun.

1. LCP öğesini PageSpeed Insights veya DevTools’ta tespit edin.
2. Öğenin gerçekten görsel olup olmadığını doğrulayın.
3. Görsel ilk ekranda mı, ilk HTML içinde mi kontrol edin.
4. LCP görselinde loading="lazy" varsa kaldırın.
5. Yalnızca gerçek LCP görseline fetchpriority="high" ekleyin.
6. Görsel CSS veya JS yüzünden geç keşfediliyorsa preload seçeneğini değerlendirin.
7. Lab testinden sonra saha verisini de izleyin.

Kısa karar matrisi de işinizi hızlandırır:

Soru	Evetse	Hayırsa
Gerçek LCP öğesi bu görsel mi?	high adaydır	Önce doğru öğeyi bulun
Görsel ilk HTML içinde mi?	fetchpriority çoğu zaman yeterlidir	Geç keşif için preload düşünün
Görsel ekranın üst kısmında mı?	Öncelik vermek mantıklıdır	Varsayılanı koruyun
Ana sorun istek sırası mı?	fetchpriority deneyin	Boyut, CSS, TTFB veya JS’yi inceleyin

Bu testleri yorumlarken saha ve lab verisini karıştırmayın. Performans teşhisini daha temiz okumak için Core Web Vitals raporu nasıl okunur rehberi iyi bir referans olur.

Sonuç

fetchpriority, doğru kullanıldığında LCP için güçlü bir ince ayardır. En iyi sonucu, gerçek hero görseli geç ya da düşük sırayla isteniyorsa verir.

Asıl kural basit, tek doğru kaynağı öne alın. Sorun keşif gecikmesiyse fetchpriority ya da preload işe yarar. Sorun sunucu, ağır CSS veya büyük görselse önce onları düzeltmek gerekir. Tarayıcıya daha net sinyal verdiğinizde, LCP de daha erken gelir.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.