Görsellerde preload ve fetchpriority Ne Zaman Kullanılır?
preload ve fetchpriority iki ayrı mekanizma. Kullanım amaçlarında bir örtüşme var — ikisi de görselin daha hızlı yüklenmesine katkı sağlar — ama işleyişleri, etki ettikleri tarayıcı aşamaları ve yanlış uygulandığındaki sonuçları birbirinden oldukça farklı. Pratikte bu ikisi çoğu zaman birbirinin yerine ya da düşünülmeden bir arada uygulanıyor: bazı HTML'lerde her iki attribute da aynı görselde görünüyor, bazı sayfalarda ise hiçbirinin olmadığı görseller LCP adayı olarak bırakılıyor. Her iki durumda da skor beklenenin altında kalıyor.
preload'un görevi tarayıcının bir kaynağı erken keşfetmesini sağlamak; fetchpriority'nin görevi ise tarayıcının zaten bildiği kaynaklar arasındaki indirme sırasını etkilemek. Tarayıcı görseli zaten görecek, ama ne zaman görecek — preload bu noktayı öne çekiyor. Tarayıcı aynı anda birden fazla kaynak indiriyor, ama hangisi önce tamamlanacak — fetchpriority bu sırayı etkiliyor. Bu ayrım netleştiğinde hangi durumda hangisinin eklenmesi gerektiği çok daha kolay belirleniyor.
Bu yazı özellikle iki yaygın yanlış üzerinde duruyor: preload'u her kritik görsel için eklemek ve bunun yarattığı bant genişliği kaybı; fetchpriority="high"'ı gereğinden fazla vermek ve bunun önceliklendirme mantığını nasıl bozduğu. Doğru kullanım bu iki hatadan kaçınmakla başlıyor.
preload ne yapar, ne yapmaz
<link rel="preload" as="image" href="..."> etiketi tarayıcıya şunu söyler: bu kaynağa ihtiyacın olacak, onu şimdiden iste. Preload scanner — HTML ayrıştırmasının erken aşamasında çalışan hızlı bir tarama mekanizması — bu etiketi bulur ve görsel dosyasını talep eder. Sayfa henüz tam olarak ayrıştırılmadan, CSS işlenmeden ve JavaScript çalıştırılmadan bu istek ağa gönderilir. Sonuç olarak görsel, aksi halde görülmesini geciktirecek bağımlılıklar ortadan kalkmadan önce indirilmeye başlar.
preload'un temel amacı erken keşiftir. Tarayıcı HTML içindeki <img src="..."> etiketlerini preload scanner aşamasında zaten buluyor; bu görseller için preload eklemeye gerek yoktur, zaten erken keşfediliyorlar. preload asıl değerini, tarayıcının normalde geç fark edeceği görsellerde gösterir: CSS background-image ile tanımlanan hero görselleri, JavaScript tarafından dinamik olarak eklenen görseller ve CSS'in işlenmesinden sonra ortaya çıkan kaynaklar.
preload'un yapmadığı şeyler de en az yaptıkları kadar önemli. Görsel dosyasını daha hızlı indirmez, sunucu yanıt süresini kısaltmaz ve görsel dosyasının ağ önceliğini doğrudan belirlemez. Sadece indirme başlangıcını öne çeker. Sunucu yavaşsa ya da dosya büyükse, preload bu süreleri kısaltmaz — yalnızca işi daha erken başlatır. Bu ayrımı net tutmak, preload'un neyi çözdüğünü ve hangi sorunlara çözüm olmadığını anlamak açısından kritik.
fetchpriority="high" ne zaman anlamlı
fetchpriority="high" attribute'u tarayıcıya görsel indirme kuyruğundaki sırayı söyler. Tarayıcı aynı anda birden fazla kaynağı indirir ama her kaynağa eşit bant genişliği ayırmaz; kritik kaynaklar daha önce tamamlanır. fetchpriority="high" ile bir görsele "bu yüksek öncelikli" sinyali verilir ve tarayıcı onu indirme kuyruğunda öne taşır. Buna karşın tarayıcı görseli zaten biliyor olmalıdır — fetchpriority keşif sağlamaz, sıralamayı etkiler.
HTML <img> etiketiyle sunulan ve ilk ekranda görünen, LCP adayı olan büyük görseller için fetchpriority="high" anlamlıdır. Tarayıcı bu görseli preload scanner aşamasında bulur; ama bulduğu anda indirme önceliğini her zaman otomatik olarak "high" atamayabilir — özellikle sayfada başka kritik kaynaklar da olduğunda. fetchpriority="high" bu belirsizliği ortadan kaldırır ve tarayıcının önceliklendirmesini açık biçimde yönlendirir.
CSS background-image için fetchpriority tek başına işe yaramaz. Tarayıcı CSS işlenmeden bu görselin varlığından haberdar olmadığı için, indirme kuyruğuna girecek bir kaynak yoktur. Bu senaryoda önce preload gerekir — görseli erken keşfetmek için. preload etiketine fetchpriority="high" eklenebilir: <link rel="preload" as="image" href="..." fetchpriority="high">. Bu kombinasyon hem erken keşfi hem de yüksek indirme önceliğini sağlar.
preload ile fetchpriority aynı görselde birlikte kullanılmalı mı
Duruma göre — ama çoğu durumda ikisi birden gerekmez. Görsel HTML <img> etiketiyle sunuluyorsa tarayıcı onu preload scanner aşamasında zaten buluyor. Bu durumda preload eklemeye gerek yok; yalnızca fetchpriority="high" attribute'u yeterli. İkisini birden eklemek gereksiz çaba olduğu gibi, zaman zaman aynı görselin iki ayrı mekanizma üzerinden talep edilmesine — yani duplicate indirme isteğine — yol açabilir.
Görsel CSS veya JavaScript üzerinden yükleniyorsa ise tablo değişir. Tarayıcı bu görseli geç fark edeceğinden preload erken keşfi sağlar ve fetchpriority="high" ile desteklendiğinde hem erken hem öncelikli indirme elde edilir. Lazy loading'in doğru uygulandığı durumlarda below-the-fold görseller ne preload ne de fetchpriority="high" alır; varsayılan davranış bu görseller için doğrudur.
srcset kullanan responsive görsellerde preload imagesrcset ve imagesizes attribute'larıyla çalışabilir: <link rel="preload" as="image" imagesrcset="gorsel-800.webp 800w, gorsel-1600.webp 1600w" imagesizes="100vw">. Bu kullanım tarayıcının srcset içinden doğru boyutu erken seçmesini sağlar. Ama <img srcset> kombinasyonu kullanan ve ilk ekranda görünen bir görsel için genellikle yalnızca fetchpriority="high" yeterlidir — tarayıcı onu zaten erken keşfeder.
Gereğinden fazla preload'ın bedeli
Her kritik görsel için preload eklemek mantıklı gelir ama pratikte tam tersi sonuç verir. Tarayıcı sayfa yüklenirken bant genişliğini bölmek zorundadır; preload edilmiş tüm görseller indirme kuyruğuna girer. Üç görseli aynı anda preload etmek, gerçekten LCP adayı olan tek görseli diğer ikisiyle bant genişliğini paylaşmak zorunda bırakır. Bu durumda preload hiç eklememekten bile kötü bir sonuç doğurabilir.
Benzer bir sorun fetchpriority="high" için de geçerlidir. Beş görsele birden "high" vermek, beş görselin de eşit öncelikte olduğu anlamına gelir — yani hiçbirinin gerçek anlamda yüksek önceliği kalmaz. Tarayıcı önceliklendirme sinyalini dengelediğinde fetchpriority değeri anlamsızlaşır. "High" değerinin anlamı, diğerlerinin "auto" veya "low" olduğu bağlamdan gelir; herkese "high" vermek önceliklendirmeyi fiilen iptal eder.
Pratik kural: preload ve fetchpriority="high" sayfa başında en fazla bir, istisnai durumlarda iki görsele uygulanmalı. Bu görsel sayfanın LCP adayı olmalı ve ilk ekranda görünür olmalı. Carousel'in tüm slaytları, grid'deki tüm ürün görselleri, sayfa altına doğru ilerledikçe görünen içerikler bu kapsama girmez. next/image bileşeninin priority prop'u da tam bu prensiple çalışır: yalnızca gerçek LCP görseli için kullanılması önerilir, diğer görsellere uygulanmaz.
Hangi görsele preload, hangisine fetchpriority verilmeli
Karar için ilk soru şu: görsel ilk ekranda görünüyor mu, LCP adayı mı? Hayırsa — ne preload ne fetchpriority="high". Görselin tarayıcı tarafından kendi mantığıyla önceliklendirilmesine bırakın; lazy loading bu görseller için doğru seçim. Çoğu sayfada bu duruma giren görsel sayısı oldukça fazladır ve bunların tamamını yüksek öncelikli işaretlemek yalnızca gerçek LCP adayına zarar verir.
Görsel ilk ekranda görünüyorsa ikinci soru: HTML <img> etiketiyle mi tanımlı, yoksa CSS ya da JavaScript üzerinden mi yükleniyor? <img> etiketiyle tanımlıysa — yalnızca fetchpriority="high", preload gerekmez. CSS veya JavaScript üzerinden yükleniyorsa — preload, tercihen fetchpriority="high" ile birlikte.
Düşük öncelik tarafı da göz ardı edilmemeli. fetchpriority="low" below-the-fold ve dekoratif görsellere verilebilir. Tarayıcının otomatik önceliklendirmesi çoğu durumda doğru çalışır; ama görsel yoğun sayfalarda açıkça "low" vermek LCP görseline daha fazla bant genişliği bırakır ve toplam yükleme performansını iyileştirir. Bu küçük ama etkili bir optimizasyon aracıdır — özellikle ana içerik ile dekoratif görsellerin aynı sayfada yoğun biçimde bir arada bulunduğu durumlarda.
preload ve fetchpriority ikisi de küçük değişikliklerle LCP skorunu anlamlı biçimde etkileyen araçlar. Bu etkinin olumlu yönde olması için neyi neden eklediğini bilmek gerekiyor. İki adım yeterli: sayfanın LCP görseli belirlendi, o görselin <img> mi yoksa CSS üzerinden mi sunulduğu tespit edildi. Bu iki sorunun yanıtı doğru aracı seçmek için yeterli zemin sağlıyor.
Geri kalan her şey — hangi görsel, kaç tane, hangi bağlamda — bu yanıtlardan türetilebilir. Araçların sayısını artırmak performansı artırmaz; doğru yere yerleştirmek artırır. Bir sayfada tek bir preload veya fetchpriority="high" bile, doğru görsele doğru şekilde uygulandığında PageSpeed skoruna ölçülebilir katkı sağlayabilir.