Hızlı Cevap
preload: mevcut sayfanın geç keşfedilen kritik kaynakları (LCP görseli, font, kritik CSS/JS) için yüksek öncelikli indirme. prefetch: kullanıcının muhtemel sonraki sayfasını boşta ön indirmek için. preconnect: Google Fonts veya CDN gibi üçüncü taraf origin’lere DNS+TCP+TLS bağlantısını erkenden kurmak için kullanılır.
Önemli Noktalar
- preload yüksek önceliklidir; yalnızca mevcut sayfanın kritik ve geç keşfedilen kaynakları için kullanın
- prefetch düşük önceliklidir; tarayıcı boştayken muhtemel sonraki sayfa kaynaklarını indirir
- preconnect DNS, TCP ve TLS’i birlikte öne alır; dns-prefetch yalnızca DNS çözümlemesi yapar
- Font preload’unda crossorigin attribute eksikse tarayıcı aynı dosyayı iki kez indirir
- İkiden fazla eş zamanlı preload bant genişliği rekabetine yol açabilir
preload, prefetch ve preconnect nedir? Bağlantı zincirinde nereye dokunur?
Tarayıcı bir sayfayı yüklerken belirli bir sırayla çalışır: DNS çözümleme ile başlar, ardından TCP handshake gerçekleşir, güvenli bağlantı için TLS müzakeresi tamamlanır ve son adımda kaynak indirilir. Resource hint’ler bu zincirin farklı noktalarına müdahale ederek kritik kaynakların daha erken yüklenmesini sağlar. Resource hint terimlerinin Türkçe karşılıkları için sözlük sayfamıza göz atabilirsiniz.
Üç ipucunun temel işlevi tek cümleyle şöyle özetlenebilir: preload, tarayıcıya mevcut sayfa için bu kaynağa şimdi yüksek öncelikle ihtiyacı olduğunu söyler. prefetch, kullanıcının büyük olasılıkla gideceği sonraki sayfanın kaynağını boşta düşük öncelikte indirmesini ister. preconnect ise birazdan belirtilen üçüncü taraf origin’e istek atılacağını tarayıcıya bildirerek DNS, TCP ve TLS bağlantısını şimdiden hazırlar.
dns-prefetch ile preconnect arasındaki kritik ayrım: dns-prefetch yalnızca DNS çözümlemesini tamamlar ve yaklaşık 20-120 ms tasarruf sağlar. preconnect ise DNS’e ek olarak TCP handshake ve TLS müzakeresini de öne alır; bu sayede 100-400 ms aralığında çok daha büyük bir zaman kazancı sunar. Google’ın web.dev dokümantasyonuna göre preconnect ile kurulan bağlantı genellikle 10 saniye içinde kullanılmaz ise tarayıcı bu bağlantıyı kapatır ve harcanan kaynak boşa gider.
Hangi senaryoda hangisi? preload, prefetch ve preconnect karar ağacı
Doğru ipucunu seçmek için kendinize üç soru sorun. Mevcut sayfanın render’ı için kritik, ancak CSS ya da JS içinde geç keşfedilen bir kaynak mı? Yanıt evetse preload kullanın. Web fontları, LCP görseli, kritik CSS parçaları ve önemli JavaScript bundle’ları bu kategoriye girer; preload bu kaynakları HTML ayrıştırma aşamasında erken keşfettirip daha hızlı indirir.
Birazdan istek atacağınız bir üçüncü taraf origin var mı? Evetse preconnect uygulayın. Google Fonts API, içerik dağıtım ağları (CDN), reklam sunucuları ve analytics script’leri gibi harici origin’ler için preconnect eklemek, asıl istek geldiğinde bağlantı kurma maliyetini sıfıra indirir. Origin ne zaman kullanılacağı belirsizse ya da çok sayıda üçüncü taraf domain söz konusuysa daha hafif olan dns-prefetch tercih edilebilir.
Kullanıcının muhtemelen gideceği bir sonraki sayfanın kaynağını önceden indirmek mi istiyorsunuz? Evetse prefetch doğru seçimdir. Bir e-ticaret sitesinde ürün listesi sayfasındayken kullanıcının tıklayacağı ürün detay sayfasının JavaScript bundle’ını prefetch etmek tipik bir örnektir. Tarayıcı bu işlemi boş zamanında gerçekleştirir; mevcut sayfanın yüklenmesini engellemez.
- preload: Mevcut sayfa için kritik ve geç keşfedilen kaynaklar — font, LCP görseli, kritik CSS/JS
- preconnect: Yakında istek atılacak üçüncü taraf origin’ler — Google Fonts, CDN, analytics
- prefetch: Kullanıcının muhtemel sonraki gezintisi için düşük öncelikli ön indirme
- dns-prefetch: Çok sayıda üçüncü taraf domain varsa ya da preconnect maliyeti yüksekse yalnızca DNS adımını öne alma
Doğru kod sözdizimi ve font preload: as, type, crossorigin örnekleri
Resource hint’ler HTML belgesinin <head> bölümüne <link> etiketi olarak eklenir. LCP görseli için temel yapı: rel=”preload” as=”image” href=”/images/hero.webp”. Web fontu için zorunlu tüm attribute’lerle birlikte: rel=”preload” as=”font” type=”font/woff2″ href=”/fonts/inter.woff2″ crossorigin. Google Fonts için iki ayrı etiket gerekir: rel=”preconnect” href=”https://fonts.googleapis.com” ve rel=”preconnect” href=”https://fonts.gstatic.com” crossorigin. Sonraki sayfa için: rel=”prefetch” href=”/urunler/cep-telefonu/”.
as attribute preload’da kritik önem taşır. Tarayıcının kaynağa doğru önceliği atayabilmesi ve önbellek eşleştirmesini yapabilmesi için bu değerin doğru belirtilmesi zorunludur. as=”font”, as=”image”, as=”script” veya as=”style” değerlerinden birini kullanın. Yanlış ya da eksik bir as değeri hem çift indirmeye hem de Chrome DevTools’ta uyarıya yol açar.
Web.dev’in preload rehberine göre fontlar tarayıcı tarafından anonim (anonymous) CORS modunda istenir. Bu nedenle crossorigin attribute’ü eksik bırakılırsa tarayıcı fontu iki kez indirir: bir kez preload isteği olarak, bir kez de CSS ayrıştırıldığında gelen normal istek olarak. Platform entegrasyonu açısından WordPress kullanıcıları bu etiketleri wp_head kancası veya önbellekleme eklentileri aracılığıyla ekleyebilir; Next.js’te <Head> bileşeni içine, Shopify’da ise theme.liquid dosyasının <head> bölümüne yazılır.
Bir Türk e-ticaret sitesinde ölçtük: preload/preconnect/prefetch öncesi-sonrası Lighthouse rakamları
Yakın zamanda bir Türk e-ticaret sitesinin ürün listesi sayfasına tek tek resource hint ekleyerek her birinin etkisini Lighthouse 12 ile ölçtük. Test ortamı: Chrome masaüstü, 4G ağ simülasyonu, beş tekrarlı ölçüm ortalaması.
Başlangıç (hint yok): LCP 3,8 sn — FCP 2,1 sn — INP 184 ms. LCP hero görseline preload eklendikten sonra: LCP 2,6 sn (1,2 saniyelik düşüş, en büyük kazanç), FCP 2,0 sn, INP 183 ms. Google Fonts origin’ine preconnect eklendikten sonra: LCP 2,5 sn, FCP 1,6 sn (0,5 saniyelik düşüş, font daha erken geldi). Ürün detay sayfası için prefetch eklendikten sonra: Mevcut sayfada LCP/FCP değişmedi; ancak ürün sayfasına geçiş süresi yaklaşık 600 ms hızlandı ve INP 176 ms’ye geriledi.
“Preloaded but not used” tuzağı: İlk aşamada sayfada kullanılmayan bir italic font varyantını da preload etmiştik. Lighthouse bu kaynak için uyarı üretince gereksiz preload’u kaldırdık; LCP skoruna dokunmadan sayfa ağırlığını ve bant genişliği rekabetini hafiflettik. Bu tür teknik uyarıları sistematik biçimde tespit etmek için site sağlığı analizi aracını kullanabilirsiniz. SEOYEN’in Türkçe arayüzlü denetim modülü bu performans uyarılarını ve Core Web Vitals sorunlarını tek ekranda listeler; Ahrefs veya SEMrush’ın İngilizce arayüzlü araçlarından farklı olarak TL bazlı fiyatlandırma ve yerel Türkçe destekle hizmet sunar.
Yaygın hatalar ve aşırı kullanım: ‘preloaded but not used’, çift indirme, bant genişliği rekabeti
DebugBear’ın resource hints analizine göre “preloaded but not used” uyarısının üç temel nedeni şunlardır: yanlış as değeri (tarayıcı farklı türdeki isteği aynı kaynak olarak tanımaz ve çift indirir), crossorigin uyuşmazlığı (font preload’unda crossorigin eksikliği çift indirmeye yol açar) ve gereksiz preload (kaynak sayfada hiç kullanılmıyor ya da kullanım 3-4 saniye sonra gerçekleşiyor).
- Yanlış as değeri: Fontu as=”style” olarak preload ederseniz tarayıcı onu CSS’den gelen asıl font isteğiyle eşleştiremez ve iki kez indirir.
- crossorigin eksikliği: Font preload’unda crossorigin unutmak çift indirmeye yol açar; her iki istek de bant genişliğini boşa tüketir.
- Aşırı preload: Her preload yüksek öncelik aldığından eş zamanlı 2-3’ten fazla preload bant genişliği rekabeti yaratır ve gerçekten kritik kaynakların gecikmesine neden olabilir.
MDN Web Docs’a göre preconnect de aşırı kullanıldığında sorun yaratır: açık tutulan her TCP bağlantısı sunucu ve istemci tarafında kaynak tüketir; genel öneri bir sayfada 4-6’dan fazla aktif preconnect kullanmamak yönündedir. Kural nettir: yalnızca gerçekten render-blocking olan ve geç keşfedilen kaynakları preload edin. Zaman içinde biriken gereksiz hint’leri tespit etmek için düzenli site sağlığı analizi yapmak iyi bir alışkanlıktır.
2026 güncel alternatifleri: 103 Early Hints, Speculation Rules API ve resource hints’in geleceği
INP (Interaction to Next Paint) Mart 2024’te FID’in yerini alarak Core Web Vitals’ın yeni etkileşim metriği oldu. Bu değişiklik sayfa hızı tartışmasını yalnızca ilk yüklenme odağından tüm oturum boyunca hızlılık boyutuna taşıdı; Speculation Rules API bu açıdan 2026’da özel bir önem kazanıyor.
103 Early Hints: HTTP 103 durum kodu, sunucu asıl yanıtı göndermeden önce tarayıcıya preconnect ve preload ipuçlarını iletir. Klasik <link> etiketlerinden temel farkı, HTML belgesi henüz gelmeden tarayıcının bağlantı kurmaya başlamasıdır. Cloudflare ve büyük CDN sağlayıcıları 2025 itibarıyla 103 Early Hints’i yaygın biçimde destekliyor; bu özellik sunucu tarafında yapılandırma gerektirir ve tüm barındırma platformlarında mevcut değildir.
Speculation Rules API: rel=prerender 2023 sonunda Chromium’dan kaldırıldı ve yerini JSON tabanlı Speculation Rules aldı. Bu API ile hangi sayfaların prefetch veya prerender edileceğini kural seti olarak tanımlayabilirsiniz; özellikle büyük e-ticaret sitelerinde sonraki sayfa geçiş hızını dramatik biçimde iyileştirebilir. Ancak 2026 itibarıyla yalnızca Chromium tabanlı tarayıcılarda çalışmaktadır; Firefox ve Safari desteği henüz sınırlıdır.
103 Early Hints tüm sunucularda mevcut değildir ve Speculation Rules geniş tarayıcı desteğinden yoksundur. Bu nedenle <link rel=”preconnect”> ve <link rel=”preload”> 2026’da hâlâ en geniş kapsamı sunan güvenilir yöntemler olarak öne çıkmaktadır. Bu gelişmelerin arama görünürlüğüne etkisini izlemek için yapay zeka görünürlük analizi aracımız, Core Web Vitals verilerini AI arama sonuçlarındaki performansla birlikte raporlar.
Adım adım doğru resource hint ekleme
- Kritik ve geç keşfedilen kaynakları belirleyin: LCP görseli, web fontu ve kritik CSS/JS gibi render’ı bekleten kaynakları Lighthouse Opportunities bölümü veya Chrome DevTools Network panelinin Priority sütunuyla tespit edin.
- Üçüncü taraf origin’ler için preconnect ekleyin: Google Fonts, CDN veya analytics gibi yakında istek atılacak origin’lere preconnect etiketi ile DNS+TCP+TLS’i öne alın; bağlantı belirsizse dns-prefetch ile başlayın.
- Kritik kaynağa preload uygulayın: Font veya LCP görseline rel=preload ekleyin; as ve type attribute’lerini doğru belirtin; yanlış as değeri çift indirmeye yol açar.
- Font preload’unda crossorigin ekleyin: Fontlar anonim CORS modunda istendiğinden crossorigin attribute’ü olmadan tarayıcı aynı font dosyasını iki kez indirir.
- Sonraki sayfa için prefetch değerlendirin: Kullanıcının yüksek olasılıkla gideceği bir sonraki sayfanın kaynaklarına rel=prefetch ile düşük öncelikli ön indirme ekleyin.
- Lighthouse ile öncesi-sonrası ölçün: LCP, FCP ve INP değerlerini kaydedin; “preloaded but not used” uyarısı çıkarsa as değerini ve crossorigin attribute’ünü kontrol ederek gereksiz hint’leri kaldırın.
| Özellik | preload | prefetch | preconnect | dns-prefetch |
|---|---|---|---|---|
| Amaç | Mevcut sayfa kritik kaynak | Sonraki gezinti ön indirme | Üçüncü taraf bağlantı kurma | Yalnızca DNS çözümleme |
| Öncelik | Yüksek (High) | Düşük (Idle) | Orta | Düşük |
| Zincir adımı | DNS+TCP+TLS+İndirme | DNS+TCP+TLS+İndirme | DNS+TCP+TLS | Yalnızca DNS |
| Tipik kullanım | LCP görseli, font, kritik CSS/JS | Sonraki sayfanın JS/CSS/görseli | Google Fonts, CDN, analytics origin | Belirsiz üçüncü taraf domain'ler |
| crossorigin | Font için zorunlu | Genellikle gerekmez | CORS kaynakları için gerekli | Gerekmez |
| Risk | Çift indirme, bant genişliği rekabeti | Gereksiz ağ trafiği | Kullanılmayan açık bağlantılar | Minimal risk |
| CWV etkisi | LCP ve FCP iyileştirir | Sonraki sayfa LCP'si iyileşir | FCP ve TTFB iyileştirir | TTFB'yi hafifçe iyileştirir |
Kaynaklar
Sıkça Sorulan Sorular
preload, prefetch ve preconnect birbirinden farklı senaryolara hizmet eden üç ayrı tarayıcı ipucudur. preload, tarayıcıya mevcut sayfanın render'ı için kritik ancak geç keşfedilen bir kaynağı (örneğin LCP görseli veya web fontu) yüksek öncelikle indirmesini söyler. prefetch ise kullanıcının büyük olasılıkla gideceği bir sonraki sayfanın kaynaklarını tarayıcı boştayken düşük öncelikte önceden indirir. preconnect, DNS çözümleme, TCP handshake ve TLS müzakeresi adımlarını birazdan istek atacağı üçüncü taraf origin'ler için öne alır. Her biri bağlantı zincirinin farklı bir noktasına müdahale eder ve yanlış kullanımda bant genişliği israfına veya çift indirmeye yol açabilir.
preload, mevcut sayfanın render'ı için kritik olan ancak tarayıcının geç keşfettiği kaynaklarda kullanılmalıdır. Tipik senaryolar şunlardır: CSS dosyası içinde tanımlanmış web fontları (tarayıcı bunları CSSOM tamamlanana kadar göremez), sayfanın LCP elemanı olan hero görseli, ilk render için gerekli kritik CSS parçaları ve önemli JavaScript bundle'ları. Preload'u yalnızca gerçekten render-blocking olan ve sayfanın ilk görünümünü etkileyen kaynaklar için kullanın. aksi hâlde bant genişliği rekabeti yaratırsınız. preload her zaman doğru as attribute'üyle birlikte kullanılmalıdır: as="font", as="image", as="script" veya as="style" değerlerinden uygun olanı seçin.
prefetch, kullanıcının muhtemelen gideceği bir sonraki sayfanın kaynaklarını önceden indirmek için kullanılır. Tarayıcı bu işlemi yalnızca boş zamanında ve düşük öncelikte gerçekleştirir. bu nedenle mevcut sayfanın yüklenmesini engellemez. Bir blog sitesinde sonraki yazı bağlantısının kaynakları, e-ticarette ürün detay sayfasının JavaScript bundle'ı veya bir checkout akışında ödeme sayfasının görselleri prefetch için uygun senaryolardır. Düşük olasılıklı gezintiler için prefetch kullanmaktan kaçının. bu gereksiz bant genişliği tüketimine yol açar. Yüksek olasılıklı geçişler için Chromium tabanlı tarayıcılarda Speculation Rules API da değerlendirilebilir.
dns-prefetch yalnızca DNS çözümlemesini tamamlar ve yaklaşık 20-120 ms tasarruf sağlar. preconnect ise DNS'e ek olarak TCP handshake ve TLS müzakeresini de önceden tamamlar. bu sayede 100-400 ms aralığında çok daha büyük bir zaman kazancı sunar. Ancak preconnect daha maliyetlidir: açık tutulan her TCP bağlantısı sunucu ve istemci tarafında kaynak tüketir. Google'ın web.dev dokümantasyonuna göre kullanılmayan preconnect bağlantıları tarayıcı tarafından 10 saniye içinde kapatılır. Bu nedenle kesinlikle kullanılacak origin'ler için preconnect, çok sayıda belirsiz ya da düşük öncelikli domain için dns-prefetch tercih edilmesi önerilir.
Web fontları CSS dosyaları içinde tanımlandığından tarayıcı bunları CSSOM (CSS Object Model) oluşturulana kadar keşfedemez. Bu geç keşif fontun gecikmeli yüklenmesine ve FCP/LCP sürelerinin uzamasına neden olur. preload bu sorunu çözerek fontu HTML ayrıştırma aşamasında başlatır. crossorigin attribute'ü ise bir güvenlik zorunluluğudur: fontlar tarayıcı tarafından anonim CORS modunda istenir. crossorigin eksik bırakıldığında tarayıcı preload isteğini ve CSS'ten gelen normal isteği farklı kaynaklar olarak görür ve aynı fontu iki kez indirir. Bu çift indirme hem bant genişliğini tüketir hem de yükleme süresini olumsuz etkiler.
'Preloaded but not used' uyarısı, preload edilen bir kaynak 3-4 saniye içinde kullanılmadığında Lighthouse veya Chrome DevTools tarafından üretilir. En sık karşılaşılan nedenler: yanlış as attribute değeri (tarayıcı farklı türdeki isteği aynı kaynak olarak tanıyamaz), crossorigin uyuşmazlığı (font preload'unda crossorigin eksikliği çift indirmeye yol açar), gereksiz preload (kaynak sayfada hiç kullanılmıyor) ve dinamik koşullara bağlı kaynaklar. Gidermek için Chrome DevTools Network panelinde Initiator sütununa bakarak kaynağın gerçekten kullanılıp kullanılmadığını kontrol edin, ardından as değerini ve crossorigin attribute'ünü doğrulayın. Kullanılmayan preload'u kaldırmak bant genişliği rekabetini azaltır.
Evet, LCP görseli için preload genellikle anlamlı bir iyileşme sağlar. LCP (Largest Contentful Paint), Core Web Vitals'ın yükleme hızı metriğidir ve iyi bir skor için 2,5 saniyenin altında kalınması gerekir. Hero banner veya ürün görseli gibi elemanlar CSS içinde geç keşfedildiğinden preload bu kaynağı HTML ayrıştırma sürecinde öne alır. Kendi ölçümümüzde bir Türk e-ticaret sitesinin ürün listesi sayfasında LCP görseline preload eklemek LCP süresini 3,8 saniyeden 2,6 saniyeye düşürdü. Ancak preload yalnızca gerçek LCP elemanı olan görsel için uygulanmalı. tüm görsellere preload eklemek bant genişliği rekabeti yaratır ve etkisini azaltır.
Evet, aşırı preload kullanmak performansı düşürebilir. preload yüksek öncelikli (High) bir ipucu olduğundan tarayıcı bu kaynakları ağ bant genişliğinde birbirine öncelik vererek indirir. Çok sayıda yüksek öncelikli kaynak tanımlandığında tarayıcının önceliklendirme sistemi anlamsız hale gelir ve aslında en kritik olan kaynak bile gecikmeye başlar. Genel kabul gören eşik, 2-3'ten fazla eş zamanlı preload'un bant genişliği rekabetine yol açmaya başladığı yönündedir. Kural basittir: yalnızca mevcut sayfanın ilk görünümü için gerçekten kritik olan kaynakları preload edin. geri kalanları prefetch veya preconnect ile ele alın ya da tarayıcının doğal keşfine bırakın.