Sayfanızdaki kaynakların hepsi kendi sunucunuzdan gelmiyorsa — ki neredeyse hiçbir sitede gelmiyor — her yeni alan adı, tarayıcı için sıfırdan başlayan bir yolculuk demektir. Yazı tipi bir sunucudan, ödeme formu bir başkasından, harita üçüncüsünden gelir ve bunların her biri için önce DNS çözümlemesi yapılması gerekir. dns-prefetch, bu ilk adımı sayfanın en başında, kaynak henüz istenmeden başlatan en hafif kaynak ipucudur (resource hint).
Bu yazıda bir bağlantının gizli maliyetini adım adım göstereceğim, dns-prefetch'in tam olarak neyi çözdüğünü ve neyi çözmediğini anlatacağım, preconnect ile arasındaki farkı netleştireceğim ve resource hints ailesinin tamamını tek bir karar tablosunda toplayacağım. Sonunda gerçek bir sayfada bu etiketlerin hangi sırayla ve kaç tane kullanılması gerektiğine dair uygulanabilir bir şablon bulacaksın.
Bir Bağlantının Gizli Maliyeti#
Tarayıcı https://harita.ornek.com/kutuphane.js adresinden bir dosya isteyeceği zaman, dosya inmeye başlamadan önce üç ayrı tur atar. Önce harita.ornek.com adını IP adresine çevirir; bu, işletim sistemi önbelleğinde yoksa bir DNS sunucusuna gidip gelmek demektir. Sonra o IP ile TCP bağlantısı kurar (üç yollu el sıkışma). Ardından HTTPS için TLS el sıkışması yapar. Ancak bundan sonra ilk bayt istenebilir.
| Adım | Tipik masaüstü | Tipik mobil (4G) | Ne ile kısaltılır |
|---|---|---|---|
| DNS çözümlemesi | 20-80 ms | 50-200 ms | dns-prefetch, preconnect |
| TCP el sıkışması | 20-60 ms | 50-150 ms | preconnect |
| TLS el sıkışması | 30-90 ms | 80-250 ms | preconnect |
| İlk bayt (TTFB) | Sunucuya bağlı | Sunucuya bağlı | Sunucu tarafı optimizasyon |
Tablodaki ilk üç satırın toplamı, mobil bir bağlantıda kolayca 200-500 ms eder ve bu süre boyunca hiçbir bayt inmemiştir. Üstelik bu maliyet her yeni alan adı için ayrı ayrı ödenir. Beş farklı üçüncü parti kullanan bir sayfada gizli maliyet birkaç saniyeye ulaşabilir. Buradaki gecikmenin DNS kısmının nasıl oluştuğunu ve önbelleğin nasıl çalıştığını DNS önbellek temizleme yazısında ayrıntılı ele aldım.
dns-prefetch Ne Yapar#
dns-prefetch, tarayıcıya "bu alan adını muhtemelen kullanacağım, adını şimdiden çözmeye başla" der. Yalnızca DNS adımını halleder; bağlantı kurmaz, TLS yapmaz, hiçbir bayt indirmez.
<head>
<link rel="dns-prefetch" href="//analitik.ornek.com">
<link rel="dns-prefetch" href="//harita.ornek.com">
<link rel="dns-prefetch" href="//odeme.ornek.com">
</head>
Protokolsüz (//) yazım tarihsel bir alışkanlıktır ve hâlâ yaygın kullanılır; tam URL yazmak da çalışır çünkü tarayıcı yalnızca ana makine adına bakar. Yol kısmını yazmanın hiçbir anlamı yoktur, sadece ana makine adı okunur.
Bu ipucunun en büyük avantajı çok ucuz olmasıdır. Bir DNS sorgusu birkaç yüz bayt trafik ve tek bir UDP turu demektir; kullanılmayan bir dns-prefetch neredeyse hiçbir şeye mal olmaz. Bu yüzden preconnect'te geçerli olan "dört-altı alan adı" sınırı burada çok daha esnektir; on alan adı için dns-prefetch yazmak makul, on alan adı için preconnect yazmak ise zararlıdır.
Gerçekçi beklenti şu olmalı: dns-prefetch size en fazla DNS adımının süresini kazandırır. Kullanıcının çözümleyicisi o alan adını zaten önbelleğinde tutuyorsa kazanç sıfırdır. Yani bu, sayfanızı dönüştüren bir optimizasyon değil, birkaç on milisaniyelik ucuz bir kazançtır — ama maliyeti de o kadar düşüktür.
dns-prefetch mi preconnect mi#
İkisi aynı problemin farklı derinliklerdeki çözümüdür ve seçim, alan adını kullanma kesinliğine bağlıdır.
| Ölçüt | dns-prefetch | preconnect |
|---|---|---|
| Hallettiği adımlar | Yalnızca DNS | DNS + TCP + TLS |
| Kazanç | Düşük (20-200 ms) | Yüksek (100-500 ms) |
| Maliyet | Neredeyse sıfır | Açık bağlantı, kaynak tutar |
| Makul üst sınır | 8-10 alan adı | 4-6 alan adı |
| Ne zaman | Kullanılma ihtimali var | Kesinlikle kullanılacak |
Pratik kural şudur: kaynağın kesin olarak isteneceğini biliyorsan preconnect, sadece ihtimal varsa dns-prefetch. Örneğin ilk ekranda kullanılan bir yazı tipi sunucusu preconnect hak eder; kullanıcı canlı destek balonuna tıklarsa yüklenecek bir sohbet servisi ise dns-prefetch için doğru adaydır.
<!-- Kesin kullanılacak: tam bağlantı kur -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Belki kullanılacak: sadece adını çöz -->
<link rel="dns-prefetch" href="//destek.ornek.com">
Eskiden preconnect desteklemeyen tarayıcılar için ikisini birlikte yazmak (preconnect + aynı adrese dns-prefetch) yaygın bir yedekleme kalıbıydı. Bugünkü tarayıcı dağılımında bu artık gerekli değil; ikisini birlikte yazmak zarar vermez ama fazladan bir fayda da sağlamaz. preconnect ve preload arasındaki ayrımı ayrıntılı görmek istersen preload, prefetch ve preconnect farkı yazısı bu konunun devamıdır.
Resource Hints Ailesinin Tamamı#
dns-prefetch bir ailenin en hafif üyesidir. Ailenin tamamını bir arada görmek, hangi problemde hangisini kullanacağını netleştirir:
| İpucu | Ne yapar | Öncelik | Tipik kullanım |
|---|---|---|---|
dns-prefetch | Alan adını çözer | Çok düşük | Muhtemel üçüncü parti alan adları |
preconnect | DNS + TCP + TLS | Düşük | Kesin kullanılacak alan adı |
preload | Bu sayfanın kaynağını indirir | Yüksek | Geç keşfedilen font, hero görseli |
modulepreload | ES modülünü ve bağımlılıklarını indirir | Yüksek | Modül tabanlı uygulamalar |
prefetch | Sonraki sayfanın kaynağını indirir | En düşük | Tahmin edilen gezinme |
prerender | Sayfanın tamamını arka planda hazırlar | Değişken | Çok yüksek olasılıklı tek geçiş |
modulepreload özellikle modern JavaScript uygulamalarında değerlidir. Normal bir preload yalnızca belirttiğin dosyayı indirir; modulepreload ise o modülün import ettiği bağımlılıkları da çözer ve indirir. Kod bölmeyle üretilen parça zincirlerinde bu, şelale etkisini ortadan kaldırır:
<link rel="modulepreload" href="/assets/app.js">
<link rel="modulepreload" href="/assets/vendor.js">
prerender ise en agresif olanıdır ve modern tarayıcılarda Speculation Rules adı verilen daha kontrollü bir mekanizmaya evrilmiştir. Sayfanın tamamını arka planda hazırladığı için kaynak tüketimi yüksektir; yalnızca kullanıcının neredeyse kesin gideceği tek bir hedef için düşünülmelidir. Kod parçalarını önceden getirmenin daha ölçülü yollarını code splitting yazısında ele aldım.
Gerçek Bir Sayfada Uygulama#
Aşağıdaki şablon, üçüncü parti kaynak kullanan tipik bir kurumsal sitenin head bölümü için makul bir dizilimdir. Sıra önemlidir: tarayıcı head içindekileri gördüğü sırayla değerlendirir, dolayısıyla en kritik ipuçları en üstte olmalıdır.
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Kesin kullanılacak: yazı tipi sunucusu -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- İhtimal dahilinde: ölçüm, sohbet, harita -->
<link rel="dns-prefetch" href="//analitik.ornek.com">
<link rel="dns-prefetch" href="//destek.ornek.com">
<link rel="dns-prefetch" href="//harita.ornek.com">
<!-- Bu sayfanın kritik kaynağı -->
<link rel="preload" href="/fontlar/inter-latin.woff2" as="font" type="font/woff2" crossorigin>
<title>Firmanız</title>
</head>
WordPress kullanıyorsan bu etiketleri tema dosyasına elle yazmak yerine wp_resource_hints kancasına bağlanmak daha temizdir; böylece çekirdek zaten eklediği ipuçlarıyla çakışma olmaz:
add_filter('wp_resource_hints', function ($ipuclari, $iliski) {
if ($iliski === 'dns-prefetch') {
$ipuclari[] = '//analitik.ornek.com';
$ipuclari[] = '//destek.ornek.com';
}
if ($iliski === 'preconnect') {
$ipuclari[] = ['href' => 'https://fonts.gstatic.com', 'crossorigin' => ''];
}
return $ipuclari;
}, 10, 2);
Sunucu tarafından da ipucu gönderebileceğini bilmekte fayda var: aynı bilgiyi HTTP yanıt başlığındaki Link alanıyla iletirsin ve tarayıcı bunu HTML ayrıştırmasından bile önce görür. Nginx tarafında tek satırdır ve özellikle HTML belgesi büyükse ipuçları birkaç on milisaniye daha erken devreye girer.
# Yanıt başlığıyla ipucu gönder — HTML ayrıştırılmadan görülür
add_header Link "<https://fonts.gstatic.com>; rel=preconnect; crossorigin" always;
add_header Link "<//analitik.ornek.com>; rel=dns-prefetch" always;
Bu yöntemin bir uyarısı var: Nginx'te add_header yönergeleri miras alınmaz, yani alt bir location bloğu kendi add_header satırını tanımlıyorsa üst seviyedeki başlıkların hiçbirini almaz. Başlığı ekledikten sonra curl -sI çıktısında gerçekten göründüğünü doğrulamak, bu sessiz kaybı yakalamanın tek yoludur.
Ölçme ve Doğrulama#
İpucu eklemek kolaydır, işe yaradığını doğrulamak asıl iştir. DevTools'un Network sekmesinde bir isteğe tıklayıp Timing bölümüne bak. dns-prefetch çalışmışsa DNS Lookup satırı sıfıra yakın olur; preconnect çalışmışsa Initial Connection ve SSL satırları da sıfırlanır. Bu satırlar hâlâ doluysa ipucu ya geç değerlendirilmiştir ya da alan adı yanlış yazılmıştır.
Komut satırından da hızlı bir kontrol yapabilirsin:
# Sayfada hangi ipuçları var?
curl -s https://firmaniz.com/ | grep -oE 'rel="(dns-prefetch|preconnect|preload|modulepreload|prefetch)"[^>]*'
# Bir alan adının DNS çözümlemesi ne kadar sürüyor?
dig +stats analitik.ornek.com | grep "Query time"
Son komut, bir alan adı için ipucu eklemenin ne kadar değeceğini tahmin etmenin en doğrudan yoludur: sorgu süresi 10 ms ise kazanç ihmal edilebilir, 150 ms ise kayda değerdir. Çözümleyici seçiminin bu süreye etkisini merak ediyorsan Cloudflare 1.1.1.1 DNS yazısında karşılaştırma yöntemini bulabilirsin.
Sık Yapılan Hatalar ve Sınırlar#
Kendi alan adına ipucu koymak. Sayfanın kendi kaynaklarını sunduğu alan adı için dns-prefetch ya da preconnect yazmak anlamsızdır; belge zaten o bağlantı üzerinden gelmiştir, DNS çoktan çözülmüş ve bağlantı açılmıştır.
Alan adını yanlış yazmak. //statik.firmaniz.com yazıp kaynakları //cdn.firmaniz.com üzerinden çekiyorsan ipucu hiçbir işe yaramaz ama sessizce çalışıyormuş gibi görünür. İpucundaki ana makine adı ile gerçek istekteki ana makine adı birebir aynı olmalıdır.
Ölü ipuçlarını temizlememek. Kaldırılmış bir üçüncü parti aracın dns-prefetch satırı sayfada yıllarca kalabilir. Zararı büyük değildir ama preconnect söz konusuysa gerçekten boşa açılmış bir bağlantı demektir.
dns-prefetch'ten büyük kazanç beklemek. Bu ipucu yalnızca DNS turunu kısaltır. Sayfan yavaşsa ve sebebi sunucu yanıt süresi, büyük görseller veya ağır JavaScript ise, buraya on satır ipucu eklemek hiçbir şeyi değiştirmez. Öncelik sırasını doğru kur.
Aşırıya kaçmak. Otuz alan adına ipucu vermek, tarayıcının kendi önceliklendirmesini bozar ve özellikle preconnect durumunda gerçek kaynak tüketir. Listeyi kısa ve gerekçeli tut; her satırın karşılığında sayfada gerçekten o alan adından bir istek olmalı.
Asıl çözümü ertelemek. Üçüncü parti alan adı sayısını azaltmak, ipucu eklemekten her zaman daha etkilidir. Bir aracı kendi alan adından servis edebiliyorsan ya da hiç kullanmadan yapabiliyorsan, kazanç tüm ipuçlarının toplamından büyüktür.
Sıkça Sorulan Sorular#
dns-prefetch ne kadar hız kazandırır#
Kazanç, o alan adının DNS çözümlemesinin ne kadar sürdüğüne eşittir; tipik olarak masaüstünde 20-80 ms, mobil bağlantılarda 50-200 ms arasındadır. Kullanıcının çözümleyicisi alan adını zaten önbelleğinde tutuyorsa kazanç sıfır olur. Yani bu, sayfa hızını dönüştüren bir teknik değil, maliyeti neredeyse sıfır olduğu için yine de yapmaya değen küçük bir kazançtır.
dns-prefetch kaç alan adı için kullanılabilir#
preconnect'e göre çok daha esnektir çünkü açık bağlantı tutmaz; sekiz-on alan adına kadar rahatlıkla kullanabilirsin. Yine de listeyi gerekçeli tut: her satırın karşılığında sayfada gerçekten o alan adına giden bir istek olmalı. Kaldırılmış araçların ipuçlarını temizlemek de listeyi anlamlı tutmanın bir parçasıdır.
preconnect varken dns-prefetch yazmaya gerek var mı#
Aynı alan adı için ikisini birlikte yazmaya bugün gerek yoktur; preconnect zaten DNS adımını da içerir. Bu kalıp, preconnect desteklemeyen eski tarayıcılar için bir yedekleme yöntemiydi ve güncel tarayıcı dağılımında karşılığı kalmamıştır. İkisini birlikte yazmak zarar vermez ama fazladan kazanç da sağlamaz.
Resource hints tüm tarayıcılarda çalışır mı#
dns-prefetch, preconnect ve preload günümüz tarayıcılarında geniş destek görür. prefetch desteklenir ancak tarayıcı veri tasarrufu modunda ya da çok yavaş bağlantılarda onu yok sayabilir; prerender ise en değişken destek gören üyedir. Bunlar birer öneridir, zorunlu direktif değildir — bu yüzden hiçbir ipucunun uygulanacağını varsayarak kritik bir davranış kurma.
Çok fazla resource hint zararlı mı#
Evet, özellikle preconnect ve preload için. preconnect gerçek bağlantı açar ve kullanılmayan her bağlantı hem istemcide hem sunucuda kaynak tüketir; preload ise öncelik verdiği için aşırı kullanıldığında tarayıcının kendi akıllı sıralamasını bozar ve asıl kritik kaynakları geciktirir. dns-prefetch bu açıdan en zararsız olanıdır ama o da sonsuz sayıda yazılmamalıdır.
Üçüncü parti alan adı sayısını nasıl azaltırım#
Önce gerçekten gerekli olup olmadıklarını sorgula; birçok sitede yıllar önce eklenmiş ve artık kimsenin bakmadığı ölçüm araçları bulunur. Kalanlar için mümkün olanları kendi alan adından servis et — örneğin yazı tiplerini kendi sunucundan sunmak, hem bir alan adını hem de bağlantı maliyetini tamamen ortadan kaldırır. Geriye kalan zorunlu servisler için ise ipuçlarını doğru kullanmak sıradaki adımdır.
Kapanış#
dns-prefetch ve kardeş ipuçları, sayfa hızının küçük ama ucuz kazançlar sunan katmanıdır. Aklında tutman gereken dört alışkanlık şudur: kesin kullanılacak alan adına preconnect, ihtimal dahilindekine dns-prefetch ver; ipucundaki ana makine adının gerçek istekle birebir aynı olduğunu doğrula; listeyi kısa ve gerekçeli tut, ölü satırları temizle; ve en önemlisi, asıl çözümün üçüncü parti alan adı sayısını azaltmak olduğunu unutma.
Bu ipuçlarının kazandırdığı milisaniyeler, sunucunun ilk yanıt süresi makul olduğunda gerçekten hissedilir hale gelir. Hızlı ve doğru yapılandırılmış web hosting ile WordPress hosting paketlerimiz bu tabanı sağlar; kendi web sunucusu yapılandırmanı yazmak istersen VDS sunucularımıza bakabilir, ölçüm ve optimizasyonu bize bırakmak istersen sunucu yönetimi hizmetimizden yararlanabilirsin.