Sayfa hızı optimizasyonunda en çok karıştırılan üç etiket preload, prefetch ve preconnect'tir. İsimleri birbirine benzediği için çoğu kişi rastgele birini seçer, sonuç alamaz ve "resource hints işe yaramıyor" der. Oysa üçü tamamen farklı işler yapar: biri bağlantıyı önceden kurar, biri kaynağı şimdi indirir, biri de sonraki gezinme için indirir. Yanlış olanı seçtiğinde en iyi ihtimalle hiçbir şey kazanmaz, en kötü ihtimalle asıl önemli kaynakların bant genişliğini çalarsın.
Bu yazıda üçünün de tarayıcı tarafında ne yaptığını, hangi senaryoda hangisinin doğru olduğunu, as niteliğinin neden zorunlu olduğunu ve fontlarda crossorigin unutulduğunda kaynağın neden iki kez indirildiğini anlatacağım. Sonunda gerçek bir sayfanın head bölümünde bu ipuçlarının nasıl sıralanması gerektiğine dair uygulanabilir bir şablon bulacaksın.
Bir Kaynağın Yolculuğu ve Üç Müdahale Noktası#
Tarayıcının bir dosyayı ekrana getirmesi tek adım değildir. Önce alan adını IP'ye çevirir (DNS), sonra TCP bağlantısı kurar, HTTPS ise TLS el sıkışması yapar, ardından isteği gönderir, yanıtı indirir ve en sonunda kaynağı kullanır. Bu zincirin farklı noktalarına farklı ipuçlarıyla müdahale edebilirsin:
| İpucu | Neyi hızlandırır | Kaynağı indirir mi | Ne zaman kullanılır |
|---|---|---|---|
dns-prefetch | Yalnızca DNS çözümlemesi | Hayır | Muhtemel ama kesin olmayan alan adları |
preconnect | DNS + TCP + TLS | Hayır | Kesin kullanılacak üçüncü parti alan adı |
preload | Bu sayfada gereken kaynağın indirilmesi | Evet, yüksek öncelikle | Geç keşfedilen kritik kaynaklar |
prefetch | Sonraki gezinmede gereken kaynak | Evet, en düşük öncelikle | Kullanıcının gideceği tahmin edilen sayfa |
modulepreload | ES modülü ve bağımlılık grafiği | Evet | Modül tabanlı uygulamalar |
Bu tablodaki en kritik ayrım son sütundur. preload "bu sayfa için lazım, hemen al" demektir; prefetch ise "belki sonra lazım olur, boş vaktinde al" demektir. İkisini karıştırmak, en sık yapılan hatadır ve sonuçları taban tabana zıttır.
preconnect: Bağlantıyı Önceden Kurmak#
Üçüncü parti bir alan adından kaynak çekiyorsan — yazı tipi, ödeme formu, harita, analitik — tarayıcı o alan adıyla ilk kez karşılaştığı anda sıfırdan bir bağlantı kurmak zorundadır. Bu, DNS + TCP + TLS demektir ve mobil bağlantılarda 200-400 ms'yi rahatlıkla bulur. preconnect, bu üç adımı sayfanın en başında, kaynak henüz istenmeden başlatır.
<head>
<!-- Yazı tipi sunucusuna bağlantıyı şimdiden kur -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Kendi statik alt alan adın için -->
<link rel="preconnect" href="https://statik.firmaniz.com">
</head>
Buradaki crossorigin niteliği isteğe bağlı değildir: font dosyaları CORS modunda çekilir, dolayısıyla crossorigin olmadan kurulan bağlantı font isteği için yeniden kullanılamaz ve tarayıcı ikinci bir bağlantı açar. Yani ipucu koymuş ama hiçbir şey kazanmamış olursun. Aynı alan adına hem CORS'lu hem CORS'suz kaynak çekiyorsan iki ayrı preconnect satırı yazman gerekir.
preconnect maliyetsiz değildir: her açık bağlantı istemcide ve sunucuda kaynak tutar, ayrıca kullanılmayan bir bağlantı 10 saniye içinde kapanır ve boşa harcanmış olur. Bu yüzden pratik sınır dört-altı alan adıdır. Tarayıcının kesinlikle kullanacağı alan adlarına preconnect, ihtimal dahilindekilere daha ucuz olan dns-prefetch vermek doğru dengedir; bu ayrımı dns-prefetch ve resource hints yazısında ayrıntılandırdım.
preload: Kaynağı Şimdi İndirmek#
preload, tarayıcıya "bu kaynağı bu sayfa için kesinlikle kullanacağım, yüksek öncelikle hemen indir" der. Kaynağı indirir ama uygulamaz; yani bir CSS dosyasını preload etmek onu devreye sokmaz, sadece önbelleğe alır.
Peki tarayıcı zaten HTML'i okuyup kaynakları bulmuyor mu? Buluyor, ama bazı kaynaklar geç keşfedilir. Bir CSS dosyasının içinde @font-face ile tanımlı font, ancak CSS indirilip ayrıştırıldıktan sonra keşfedilir. Bir arka plan görseli aynı şekilde. Bir JavaScript dosyasının dinamik olarak yüklediği modül de öyle. preload tam olarak bu geç keşfedilen kaynaklar için vardır.
<!-- İlk ekranda kullanılan yazı tipi: CSS'in içinde gizli, erken bul -->
<link rel="preload" href="/fontlar/inter-latin.woff2" as="font" type="font/woff2" crossorigin>
<!-- LCP öğesi olan hero görseli -->
<link rel="preload" href="/gorseller/hero-1200.webp" as="image" fetchpriority="high">
<!-- Ertelenmiş CSS'i erken indir, sonra uygula -->
<link rel="preload" href="/assets/style.css" as="style" onload="this.rel='stylesheet'">
as niteliği zorunludur ve üç işi birden yapar: tarayıcının doğru önceliği vermesini, doğru Accept başlığını göndermesini ve indirdiği kaynağı sonradan doğru istekle eşleştirmesini sağlar. as yazmazsan tarayıcı konsola uyarı basar ve kaynağı büyük olasılıkla iki kez indirir — ipucu, tam tersi bir sonuç verir.
Fontlarda crossorigin de aynı sebeple zorunludur. Kendi alan adından servis ettiğin bir fontta bile gereklidir, çünkü font istekleri anonim CORS modunda yapılır ve mod uyuşmazsa önceden indirilen kopya kullanılamaz. Font tarafındaki bütün resmi web font yükleme optimizasyonu yazısında bulabilirsin.
prefetch: Sonraki Gezinme İçin İndirmek#
prefetch, mevcut sayfa için değil, kullanıcının muhtemelen gideceği bir sonraki sayfa için kaynak indirir. Tarayıcı bunu en düşük öncelikle, boşta kaldığı anlarda yapar; yani mevcut sayfanın yüklenmesini aksatmaz.
<!-- Kullanıcı büyük ihtimalle ürün listesine gidecek -->
<link rel="prefetch" href="/assets/urun-listesi.chunk.js" as="script">
<link rel="prefetch" href="/urunler" as="document">
Bu ipucu en çok tek sayfa uygulamalarında ve belirgin bir kullanıcı akışının olduğu sitelerde işe yarar: sepet sayfasından ödeme sayfasına, ürün listesinden ürün detayına. Kod bölmeyle üretilen parçaları önceden getirmek için de idealdir; code splitting yazısındaki hover tetikleyicisi ile prefetch aynı problemi iki farklı yoldan çözer.
Dikkat edilmesi gereken nokta, prefetch edilen kaynağın kullanılmama ihtimalidir. Kullanıcı o sayfaya gitmezse indirilen bayt boşa gitmiştir; mobil veri kullanan bir ziyaretçi için bu nezaketsizliktir. Bu yüzden prefetch'i körlemesine değil, gerçekten yüksek olasılıklı geçişler için kullan. Tahminini veriye dayandırmak istersen analitikte en sık takip edilen akışa bakman yeterlidir.
Bir de tarayıcı desteği tarafı var: prefetch, veri tasarrufu modu açık cihazlarda ve çok yavaş bağlantılarda tarayıcı tarafından tamamen yok sayılabilir. Bu bir eksiklik değil, doğru davranıştır — ipucunun tanımı gereği zorunlu değil, öneri niteliğindedir. Dolayısıyla prefetch üzerine kritik bir varsayım kurma; sayfanın onsuz da makul sürede açılması gerekir.
Gerçek Bir head Bölümünde Sıralama#
Üç ipucunu bir arada kullanırken sıra önemlidir, çünkü tarayıcı head içindekileri gördüğü sırayla değerlendirir. Aşağıdaki şablon, tipik bir pazarlama sayfası için makul bir dizilimdir:
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- 1) Kesin kullanılacak dış alan adlarına bağlantı -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- 2) İhtimal dahilindeki alan adları için ucuz ipucu -->
<link rel="dns-prefetch" href="//analitik.ornek.com">
<!-- 3) Bu sayfanın kritik, geç keşfedilen kaynakları -->
<link rel="preload" href="/fontlar/inter-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/gorseller/hero-1200.webp" as="image" fetchpriority="high">
<!-- 4) Kritik stil doğrudan belgede -->
<style>/* ilk ekran stilleri */</style>
<!-- 5) Tam CSS, render'ı engellemeden -->
<link rel="stylesheet" href="/assets/style.css" media="print" onload="this.media='all'">
<!-- 6) Sonraki gezinme tahmini, en sonda -->
<link rel="prefetch" href="/assets/urun-listesi.chunk.js" as="script">
</head>
Kritik stilin belgeye gömülmesi ve tam CSS'in ertelenmesi konusunun tamamı critical CSS yazısındadır. Buradaki mantık şudur: önce bağlantıları aç, sonra bu sayfanın kritik kaynaklarını çek, en son gelecekteki ihtimalleri düşün.
İpucunun İşe Yarayıp Yaramadığını Ölçmek#
Resource hints eklemek kolay, işe yaradığını kanıtlamak ise ihmal edilen kısımdır. Neyse ki tarayıcı sana gerekli tüm veriyi veriyor. DevTools'un Network sekmesinde sütun başlığına sağ tıklayıp Priority ve Initiator sütunlarını aç. preload ettiğin bir kaynağın önceliği "High" görünmeli ve başlatıcısı HTML belgesi olmalı; hâlâ "Low" görünüyorsa ya as niteliği eksiktir ya da tarayıcı ipucunu yok saymıştır.
İkinci kontrol noktası Timing sekmesidir. Bir isteğe tıklayıp Timing bölümüne baktığında preconnect çalışan bir alan adında DNS Lookup, Initial Connection ve SSL satırlarının sıfıra yakın olduğunu görürsün; çünkü bu adımlar isteğin öncesinde bitmiştir. Bu satırlar hâlâ dolu ise preconnect ya geç değerlendirilmiştir ya da CORS modu uyuşmadığı için bağlantı yeniden kullanılamamıştır.
Üçüncüsü konsoldur ve en açık uyarıyı orada bulursun. Kullanılmayan bir preload için tarayıcı doğrudan uyarı basar; bu satır, ipucunun boşa gittiğinin kanıtıdır ve mutlaka giderilmelidir, çünkü boşa giden bir ön yükleme yalnızca faydasız değil, aynı zamanda gerçek kaynaklardan bant genişliği çalar.
# Sayfada hangi resource hint etiketleri var, hızlıca listele
curl -s https://firmaniz.com/ | grep -oE '<link[^>]*rel="(preload|prefetch|preconnect|dns-prefetch|modulepreload)"[^>]*>'
Bu komut özellikle bir önbellek eklentisi ya da CDN katmanı ipuçlarını kendiliğinden ekliyorsa işe yarar; bazen sen bir tane eklersin, eklenti üç tane daha basar ve toplam sayı makul sınırın üstüne çıkar. Değişikliğin gerçek etkisini görmek istiyorsan aynı sayfayı ipuçlarıyla ve ipuçları kaldırılmış haliyle en az üç kez ölç ve medyan değerleri karşılaştır; tek bir ölçüm ağ dalgalanmalarına fazlasıyla açıktır. Dış bir araçla karşılaştırma yapmayı tercih edersen GTmetrix ile hız testi yazısındaki yöntem aynı işi görür.
Sık Yapılan Hatalar#
as niteliğini unutmak. En yaygın hata budur ve sonucu ipucunun tam tersine dönmesidir: tarayıcı kaynağı ne olduğunu bilmeden indirir, sonra gerçek istek geldiğinde eşleştiremez ve ikinci kez indirir. Konsolda "was preloaded using link preload but not used within a few seconds" uyarısını görürsen ilk bakacağın yer burasıdır.
Fontlarda crossorigin yazmamak. Aynı sonucu doğurur: font iki kez iner. Kendi alan adından servis ediyor olman bu kuralı değiştirmez.
Her şeyi preload etmek. preload bir öncelik ipucudur; her kaynağa verirsen hiçbiri öncelikli olmaz ve tarayıcının kendi akıllı sıralamasını bozarsın. Sayfa başına iki-dört preload makul bir üst sınırdır.
preload ile prefetch'i karıştırmak. Bu sayfada gereken bir kaynağa prefetch verirsen en düşük öncelikle indirilir ve muhtemelen geç kalır. Sonraki sayfa için gerekene preload verirsen bu sayfanın kritik kaynaklarıyla yarışır ve onları geciktirir.
Kullanılmayan alan adına preconnect koymak. Açılan ama kullanılmayan bağlantı, hem istemci hem sunucu tarafında boşa kaynak tüketir. İpucu listesini de zaman zaman gözden geçir; kaldırılan bir üçüncü parti aracın preconnect satırı sayfada aylarca kalabilir.
Kritik olmayan görselleri preload etmek. Yalnızca LCP öğesi olan görsel preload edilmelidir. Kaydırma altındaki görselleri önceden indirmek, ilk ekranın kaynaklarını yavaşlatır; onlar için loading="lazy" doğru araçtır.
Sıkça Sorulan Sorular#
preload mu prefetch mi kullanmalıyım#
Karar tek bir soruya bakar: bu kaynak şu anki sayfa için mi gerekli, yoksa kullanıcının gidebileceği bir sonraki sayfa için mi? Bu sayfa içinse preload, sonraki sayfa içinse prefetch. preload yüksek öncelikle hemen indirir ve mevcut sayfanın yüklenmesine dahil olur; prefetch ise tarayıcı boşta kaldığında en düşük öncelikle indirir ve mevcut sayfayı yavaşlatmaz.
preconnect kaç alan adı için kullanılmalı#
Pratik üst sınır dört ile altı arasıdır. Her preconnect gerçek bir bağlantı açar ve bu bağlantı kullanılmazsa hem istemci hem sunucu tarafında boşa kaynak harcanır. Kesinlikle kullanılacağını bildiğin alan adlarına preconnect, yalnızca ihtimal dahilindekilere çok daha ucuz olan dns-prefetch vermek en dengeli yaklaşımdır.
preload kullanınca kaynak neden iki kez iniyor#
Neredeyse her zaman iki sebepten biridir: as niteliği eksiktir ya da CORS modu uyuşmuyordur. as olmadan tarayıcı kaynağı sınıflandıramaz ve gerçek istek geldiğinde önceden indirileni eşleştiremez. Fontlarda ise crossorigin yazılmadığında ön yükleme farklı bir modda yapılır ve yine eşleşmez. Konsoldaki "preloaded but not used" uyarısı bu iki durumun da göstergesidir.
fetchpriority ile preload arasındaki fark ne#
preload bir kaynağı erken keşfettirir; fetchpriority ise zaten keşfedilmiş bir kaynağın önceliğini ayarlar. İkisi birlikte kullanılabilir, örneğin hero görselini hem preload edip hem fetchpriority="high" vermek gibi. Görsel zaten HTML içinde erken görünüyorsa preload gereksizdir ve tek başına fetchpriority="high" yeterli olur.
Resource hints SEO'ya etki eder mi#
Doğrudan bir sıralama sinyali değildir, ama dolaylı etkisi vardır. Bu ipuçları görsel yüklenme ve etkileşim metriklerini iyileştirdiğinde sayfa deneyimi sinyalleri olumlu etkilenir. Aşırıya kaçıp gereksiz indirmeler yaptırırsan tam tersi olur; bu yüzden ipucu eklemek her zaman ölçümle doğrulanmalıdır.
WordPress'te preload nasıl eklerim#
Temanın functions.php dosyasında wp_head kancasına bağlanarak istediğin link etiketini basabilirsin; ya da önbellek eklentilerinin "Preload" bölümünden font ve kritik görsel yollarını girebilirsin. Hangi yolu seçersen seç, ekledikten sonra sayfa kaynağını açıp etiketin doğru as ve gerekiyorsa crossorigin nitelikleriyle çıktığını doğrula; eklentiler bazen bu nitelikleri eksik basar.
Kapanış#
Üç ipucunu tek cümlede ayırmak gerekirse: preconnect bağlantıyı kurar, preload bu sayfanın geç keşfedilen kritik kaynağını hemen indirir, prefetch ise sonraki sayfanın kaynağını boş vakitte indirir. Akılda tutulacak dört alışkanlık — preload kullanırken as niteliğini asla atlama, fontlarda crossorigin ekle, sayfa başına iki-dört preload sınırını aşma ve eklediğin her ipucunu ölçümle doğrula. Konsoldaki "preloaded but not used" uyarısı, bu kurallardan birini çiğnediğinin en hızlı göstergesidir.
Bu ipuçları ağdaki gecikmeyi kısaltır ama sunucunun yanıt süresini değiştirmez; ikisi birlikte çalıştığında sonuç hissedilir olur. HTTP/2 ve modern TLS desteğiyle gelen web hosting ve WordPress hosting paketlerimiz bu tabanı sağlar; kendi Nginx veya LiteSpeed yapılandırmanı yazmak istersen VDS sunucularımıza bakabilir, yapılandırmayı bize bırakmak istersen sunucu yönetimi hizmetimizden yararlanabilirsin.