Resource hint'lerin ortak amacı tarayıcıya ileride ihtiyaç duyacağı kaynaklar hakkında önceden bilgi vermektir. Ancak "önceden bilgi verme" ifadesi dört türü tek bir sepete koymamak için yeterli bir neden sunar. Her türün tetiklediği tarayıcı işlemi, tamamladığı hazırlık adımı ve uygulandığı kaynak türü birbirinden belirgin biçimde ayrılır. Bu ayrımı kavramak, hangi hint'in nereye gireceğine karar vermenin tek güvenilir yoludur.

Dört türü soldan sağa bir bağlantı kurulum şeması üzerinde konumlandırmak işe yarar. En solda DNS çözümlemesi gelir; ardından TCP bağlantısı ve TLS el sıkışması, ardından kaynağın indirilmesi, en sağda ise düşük öncelikli ön belleğe alma. dns-prefetch yalnızca birinci adımı tamamlar. preconnect ilk üç adımı birden bitirir. preload kaynağı tamamen indirir ve yüksek öncelikle işler. prefetch ise arka planda, düşük öncelikle bir sonraki sayfanın ihtiyaçlarını hazırlar.

dns-prefetch: yalnızca alan adını çözer, bağlantı kurmaz

Tarayıcı bir kaynağa ulaşmadan önce alan adını IP adresine çevirmek zorundadır. Bu işlem DNS çözümlemesidir ve ağ koşullarına bağlı olarak 20–120 ms arasında sürebilir. Bir sayfa üçüncü parti kaynaklara —analitik, font servisi, reklam ağı— başvuruyorsa her birinin DNS'i ayrı ayrı çözülür. dns-prefetch, bu çözümlemeyi sayfa yüklenmeden önce arka planda başlatır.

<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.googletagmanager.com">

Bu hint yalnızca DNS'i çözer; TCP bağlantısı ve TLS el sıkışması yapılmaz. Maliyeti düşüktür, tarayıcıya yükü azdır. Sayfada fiilen kullanılan ama nispeten geç ihtiyaç duyulan üçüncü parti alan adları için uygun bir başlangıç noktasıdır. Bir adım ötesi gerekiyorsa —gerçek bağlantı kurulumu— dns-prefetch yetersiz kalır ve preconnect devreye girer. Aynı alan adı için her iki hint'i birlikte kullanmak anlamsızdır; preconnect DNS çözümlemesini zaten kapsar.

dns-prefetch'i aşırı kullanmanın ciddi bir maliyeti yoktur; ancak sayfada hiç ziyaret edilmeyecek alan adları için eklenmesi boşa harcanan küçük bir işlemdir. Analitik ve reklam scriptleri gibi yükleme sırasında geç gelen kaynaklar için faydalıdır. Kritik render yolundaki kaynaklar için ise preconnect çok daha güçlü bir seçimdir.

preconnect: bağlantıyı tam olarak kurar, maliyet de tam olarak gelir

preconnect, DNS çözümlemesinin ötesine geçer. TCP bağlantısını açar ve TLS el sıkışmasını tamamlar. Kaynak henüz istenmemiştir; ancak bağlantı hazır ve sıcaktır. Gerçek istek geldiğinde bu üç adım atlanır, doğrudan veri transferi başlar. HTTPS bağlantılarında TLS el sıkışması tek başına 50–200 ms kurtarabilir; gecikmenin yüksek olduğu ağlarda bu kazanım daha da belirginleşir.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Buradaki crossorigin niteliği dikkat gerektirir. Fontlar ve diğer CORS kaynaklarına yapılan istekler farklı bir bağlantı üzerinden gider. crossorigin olmadan eklenen preconnect, font isteği geldiğinde kullanılamaz; tarayıcı yeni bir bağlantı açmak zorunda kalır. Bu durumda preconnect hem gereksiz bir bağlantı açmış hem de beklenen faydayı üretememiş olur. Font yükleme optimizasyonunda bu hata sık karşılaşılan ve ölçüm araçlarında fark edilmesi güç bir tuzaktır.

preconnect'in en önemli kısıtı, kullanılmayan bağlantılar için gereksiz kaynak tüketmesidir. Tarayıcı bağlantıyı açar, belirli bir süre —çoğunlukla 10 saniye— bekler, kullanılmazsa kapatır. Bu süre içinde CPU ve ağ kaynakları meşgul tutulmuştur. Sayfada kesinlikle kullanılacak ve kritik render yolunda yer alan alan adları için preconnect uygundur. "Belki lazım olur" düşüncesiyle eklenen preconnect ise net bir zarar üretir. Pratikte bir sayfada 2–3 preconnect yeterlidir; daha fazlası çoğunlukla dikkatli seçim yapılmadığının işaretidir.

preload: mevcut sayfa için kritik kaynağı öne çeker

preload, mevcut sayfanın yüklenmesi için gerekli ama tarayıcının erken keşfedemeyeceği kritik kaynakları öne çekmek için kullanılır. Tarayıcı HTML'i parse ederken tüm kaynakları eşit öncelikle görmez; CSS içinde tanımlanan fontlar, JavaScript tarafından yüklenen görseller ya da geç bulunan kritik scriptler tarayıcının öncelik sıralamasında geride kalabilir. preload bu kaynakları listenin başına taşır.

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/css/critical.css" as="style">
<link rel="preload" href="/img/hero.webp" as="image">

as niteliği zorunludur. Olmadan eklenen preload, tarayıcının kaynağın türünü anlayamamasına yol açar; doğru öncelik ataması yapılamaz, CORS başlıkları yanlış uygulanabilir ve kaynak hem preload hem de asıl istek aracılığıyla iki kez indirilebilir. Bu ikili indirme hem bant genişliği israfı hem de gereksiz ağ isteğidir. LCP optimizasyonunda hero görselini as="image" ile preload etmek yaygın ve etkili bir yaklaşımdır; ancak as eksikse bu yaklaşım zarar üretir.

preload yalnızca mevcut sayfa için anlamlıdır. Sayfa yüklendiğinde kullanılmayan preload edilmiş kaynak tarayıcı konsolunda uyarı üretir ve boşa harcanan bir ağ isteğine dönüşür. Her kaynağı preload etmek, hiçbirini preload etmemiş olmakla eşdeğerdir; öncelik sıralaması tekrar düzleşir. Gerçekten geç keşfedilen, kritik render yolunda yer alan ve mevcut sayfada kullanılacak kaynaklar preload için doğru adaylardır. Render engelleyen kaynakları tespit ettikten sonra preload stratejisi kurmak çok daha verimli sonuç verir.

prefetch: bir sonraki sayfa için arka planda hazırlık yapar

prefetch, mevcut sayfada değil gelecekteki bir sayfada ihtiyaç duyulacak kaynakları şimdiden indirerek tarayıcı önbelleğine koyar. Önceliği düşüktür; tarayıcı boşta olduğunda çalışır, aktif indirmeleri ve render süreçlerini engellemeye çalışmaz. Kullanıcı bir sonraki sayfaya geçtiğinde kaynak zaten önbellektedir, ağ isteği yapılmaz.

<link rel="prefetch" href="/urun-detay.html">
<link rel="prefetch" href="/js/odeme-modulu.js">

prefetch'in değeri, kullanıcı davranışının öngörülebildiği akışlarda ortaya çıkar. Bir ürün listeleme sayfasından kullanıcıların büyük çoğunluğunun ürün detay sayfasına geçtiği biliniyorsa, detay sayfasının JS bundle'ını prefetch etmek anlamlıdır. Tek adımlı bir form akışında bir sonraki adımın kaynaklarını prefetch etmek, geçiş anındaki yükleme süresini neredeyse sıfıra indirebilir. Dynamic import ile birlikte düşünüldüğünde, route bazlı prefetch stratejisi büyük SPA mimarilerinde navigasyon hızını belirleyen kritik bir katman oluşturur.

prefetch'in en önemli riski, yanlış kestirilen kullanıcı davranışıdır. Kullanıcının gitmeyeceği bir sayfanın kaynaklarını indirmek hem bant genişliği israfıdır hem de mobil kullanıcılar için veri tüketimi maliyeti üretir. Analitik verisiyle desteklenmeyen spekülatif prefetch, iyi niyetli ama kontrolsüz bir yük oluşturur. Prefetch edilecek kaynakların seçimi, gerçek kullanıcı akış verisiyle desteklenmelidir.

Dört hint'i doğru yerleştirmek: pratik karar çerçevesi

Dört hint türünün hedef kitlesi ve zamanlaması farklıdır. dns-prefetch, sayfada fiilen başvurulan ama geç yüklenen üçüncü parti alan adları içindir; maliyeti düşük, faydası sınırlıdır. preconnect, kritik render yolundaki alan adları için TCP ve TLS'i öne alır; güçlüdür ama sayıyla sınırlı tutulmalıdır. preload, mevcut sayfanın kritik ve geç keşfedilen kaynakları içindir; as niteliği zorunludur ve aşırı kullanım önceliği sıfırlar. prefetch, bir sonraki sayfanın yüksek olasılıklı kaynakları içindir; düşük öncelikli çalışır, veri kullanımına dikkat gerektirir.

Bu dört türün kesiştiği ama sıkça karıştırıldığı nokta preload ile prefetch arasındaki zamanlama farkıdır. preload mevcut sayfa için acildir; tarayıcı bunu yüksek öncelikli olarak hemen işler. prefetch gelecek için sabırsız bir hazırlıktır; tarayıcı uygun gördüğü anda, genellikle ana içerik yüklendikten sonra işler. Mevcut sayfanın bir kaynağını prefetch ile işaretlemek onu geciktirir; bir sonraki sayfanın kaynağını preload ile işaretlemek ise mevcut sayfanın yükünü gereksiz yere artırır. Preload ve prefetch arasındaki bu temel fark, hangi hint'in nereye gireceğini belirleyen ana eksendir.

Tüm bu kararlar Chrome DevTools'un Network sekmesinde doğrulanabilir. Priority sütunu her kaynağın tarayıcı tarafından hangi öncelikle işlendiğini gösterir. Bir preload "Highest" olarak görünmüyorsa as niteliği eksik olabilir ya da hint çok geç bulunmuş olabilir. Bir preconnect kullanılmadan kapanmışsa gerçekte o alan adından kaynak çekilmemiştir ve hint kaldırılmalıdır. Ölçüm olmadan kurulan hint stratejisi, niyetten farklı bir tablo üretebilir.

Resource hint'lerin en verimli çalıştığı nokta, tarayıcının kendi keşif mekanizmasının yetersiz kaldığı yerdir. Tarayıcı HTML'i parse ederken zaten çoğu kaynağı erken keşfeder; preload scanner bu iş için tasarlanmıştır. CSS dosyasının içindeki bir font URL'si ya da JavaScript tarafından dinamik olarak yüklenen bir görsel bu taramayı atlayabilir. İşte bu noktada hint'ler devreye girer ve boşluğu kapatır. Tarayıcının zaten keşfedebileceği kaynaklar için eklenen hint'ler ise en iyi ihtimalle gereksiz, kötü ihtimalle çakışan öncelik talepleri üreterek zararlı olur.