DNS Prefetching: Kullanmalı mısınız? Performans ve Gizlilik Dengesi
HTML <head> bölümüne eklenen tek bir <link> etiketi, tarayıcıya henüz ihtiyaç duymadığı ama yakında duyacağı alan adlarının IP adreslerini önceden sorgulatır. Buna DNS prefetching denir. Sözdizimi son derece basittir, uygulaması saniyeler alır; ne zaman performans kazancı sağladığını ve ne zaman gizlilik riski yarattığını anlamak ise biraz daha dikkat ister.
Bir sayfa yüklenirken tarayıcı yalnızca tek bir sunucuyla konuşmaz. Farklı alan adlarından gelen yazı tipleri, CDN üzerindeki betikler, analitik pikseller, ödeme altyapısı; bunların her biri ayrı bir DNS çözümleme sürecini tetikler. Bu çözümlemeler milisaniye cinsinden küçük görünür, ama ağ gecikmesi yüksekse veya tarayıcının DNS önbelleği boşsa, art arda gelen sorgular sayfa yükleme süresini fark edilir biçimde uzatır. Bu gecikme DNS RTT zincirinin tarayıcı ucudur.
DNS prefetching bu gecikmeyi sayfanın kritik yolundan öncesine almayı hedefler. Tarayıcı, gerçek bağlantı kurmadan veya tek bayt veri indirmeden yalnızca o alan adının IP'sini öğrenir. En hafif ön yükleme yöntemi olması onu cazip kılar; şifreli resolver kullanılıyorsa prefetch hâlâ DoH uç noktasına gider ve bu hafiflik aynı zamanda kullanım sınırlarını da belirler.
DNS Prefetching Nedir ve Nasıl Çalışır?
<link rel="dns-prefetch" href="//cdn.example.com"> etiketi tarayıcıya şunu söyler: bu sayfada bu alan adına ihtiyaç duyacaksın, şimdiden DNS sorgusunu gönder. Tarayıcı, sayfanın geri kalanını işlerken arka planda bu sorguyu başlatır; kaynak gerçekten yüklenmeye başladığında DNS yanıtı önbellekte hazır olur.
Süreç üç adımda ilerler: direktif ayrıştırılır, yalnızca DNS katmanında sorgu gönderilir, yanıt tarayıcının yerel DNS önbelleğine yazılır. İşletim sistemi katmanı ayrıdır; flush stub resolver'ı boşaltır, tarayıcıyı değil. Bu önbelleğin ömrü genellikle 1-5 dakika arasındadır; söz konusu süre, alan adının TTL değeriyle doğrudan ilişkili değildir. Tarayıcı kendi politikasına göre önbelleği yönetir.
Sözdiziminde protokol belirtmek zorunlu değildir:
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<!-- ya da -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">Her iki yazım da çalışır. href değerinin yalnızca alan adını içermesi yeterlidir; yol bileşeni veya sorgu parametreleri eklemenin herhangi bir etkisi yoktur, tarayıcı bunları yok sayar.
Önemli bir ince nokta: çoğu modern tarayıcı, HTML ayrıştırıcısı düzeyinde bazı DNS çözümlerini zaten otomatik başlatır. <script src="...">, <img src="..."> gibi etiketlerde gördüğü alan adları için tarayıcı kendiliğinden sorgu açar. JavaScript aracılığıyla dinamik olarak eklenen kaynaklar için bu otomatik davranış devreye girmez. Manuel dns-prefetch direktifi tam bu noktada anlam kazanır: henüz DOM'a eklenmemiş ama yükleneceği bilinen harici alan adlarını erken işaret etmek.
Performans Kazancı: Hangi Durumlarda Etkisi Görülür?
DNS prefetching en belirgin kazancı belirli koşullar altında sağlar. Yavaş veya değişken ağlar bunların başında gelir. DNS çözümleme süresi bant genişliğiyle değil ağ gecikmesiyle ilişkilidir; bu yüzden 3G veya dalgalı mobil bağlantılarda etki daha belirgin çıkabilir.
Sayfa üzerinde birden fazla harici alan adına bağımlılık varsa prefetch değer üretir. CDN, analitik servisi, yazı tipi sunucusu, ödeme altyapısı: bunların DNS süreleri toplanır. Direktifler bu sürelerin örtüşmesini sağlar; yani bazı sorgular paralel ilerler.
Fark görülmeyecek durumlar da vardır. Alan adı tarayıcı önbelleğinde zaten varsa (kullanıcı o servisi sık kullanıyorsa) ek sorgu anlamsızdır. Sayfada yalnızca tek bir harici alan adı varsa tek direktifin katkısı ölçüm eşiğinin altında kalır. Yavaş yanıt veren bir kaynak sunucu söz konusuysa DNS dışındaki gecikmeler çok daha baskındır; prefetch burada sorunu çözmez.
JavaScript ile geç yüklenen kaynaklar için ise prefetch değer üretir. Render-blocking olmayan asenkron bileşenler, DOM'a eklendiklerinde DNS henüz çözümlenmemiş olabilir. Direktif bu boşluğu öncesine alır, kullanıcı etkileşimi sırasındaki gecikmeyi gizler.
Yanlış anlaşılan bir nokta: dns-prefetch eklemek sayfa performansını otomatik olarak iyileştirmez. Fazla direktif, kullanıcının ağında gereksiz DNS trafiği yaratır. Küçük bir etki gibi görünse de gizlilik boyutu açısından bu durum önem taşır.
Gizlilik Riski: Hangi Sorgu Ne Zaman Gönderilir?
DNS prefetching aktif olduğunda, tarayıcı o kaynağa gerçekten ihtiyaç duyulup duyulmadığından bağımsız olarak DNS sorgusunu gönderir. Kullanıcı, prefetch edilen bileşeni hiç yüklemeyebilir; sorgulama zaten gerçekleşmiştir.
Bu durum somut bir sorun yaratır. Kullanıcının DNS sorgularını işleyen sunucu (ISS'nin resolver'ı, kurumsal ağın DNS sunucusu veya public bir resolver), ziyaret edilen sayfaların hangi harici servislere bağımlı olduğunu öğrenir. Analitik, reklam altyapısı veya izleme servislerine ait alan adları için bu, kullanıcı profillemesinde kullanılabilir bir sinyal üretir.
HTTP yanıt başlığı X-DNS-Prefetch-Control ile tüm sayfada bu davranışı kontrol edebilirsiniz:
X-DNS-Prefetch-Control: offKullanıcı panelleri, sağlık uygulamaları, finansal araçlar ve giriş sayfaları için bu başlığı kapatmak yerinde bir tercihtir. Genel içerik sayfaları için açık bırakmak performansa katkı sağlar:
X-DNS-Prefetch-Control: onHTTPS sayfalarında tarayıcı davranışı değişebilir. Firefox geçmişte HTTPS sayfalarında dns-prefetch'i varsayılan olarak devre dışı bırakırdı; Chrome ise HTTPS'de de prefetch'i etkin tutar. Siteniz tamamen HTTPS üzerindeyse bu farklılığı göz önünde bulundurmanız yerindedir. Nginx veya Apache üzerinde başlığı şu şekilde ekleyebilirsiniz:
# Nginx
add_header X-DNS-Prefetch-Control "on";
# Apache (.htaccess veya VirtualHost)
Header set X-DNS-Prefetch-Control "on"Preconnect ile Farkı: Daha Güçlü mü, Daha Maliyetli mi?
dns-prefetch yalnızca DNS katmanında çalışır. preconnect ise DNS çözümlemesi, TCP el sıkışması ve TLS müzakeresini tek seferde tamamlamaya çalışır. Kaynak gerçekten yüklendiğinde gecikme neredeyse sıfıra düşer; ama kullanılmayan bir bağlantı açmak gereksiz sistem kaynağı tüketir.
Karar noktası şudur: kaynağın yükleneceği kesinse preconnect, yalnızca olasılık söz konusuysa veya yükleme kullanıcı etkileşimine bağlıysa dns-prefetch daha uygun seçimdir.
<!-- Kesin yüklenecek font için -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Geç tetiklenecek veya koşullu kaynak için -->
<link rel="dns-prefetch" href="//analytics.example.com">Eski tarayıcılar için yedek olarak her iki direktifi birlikte vermek yaygın bir pratiktir:
<link rel="preconnect" href="https://cdn.example.com">
<link rel="dns-prefetch" href="//cdn.example.com">Preconnect'i destekleyen tarayıcılar tam bağlantı avantajından yararlanır; daha eski ortamlar yalnızca DNS çözümlemesiyle devam eder. İkinci satır birincinin yedek güvencesidir. İkisini aynı anda vermek çakışma yaratmaz; tarayıcı desteklediği direktifi seçer.
Ne Zaman Kullanmamalısınız?
Dört senaryo, dns-prefetch eklemenin anlamsız veya olumsuz sonuç verdiği durumları gösterir.
Çok sayıda alakasız alan adı için toplu direktif: Otomatik araçlarla oluşturulan sayfalarda zaman zaman 20-30 farklı alan adı için prefetch direktifi görülür. Bu, kullanıcının ağında gereksiz DNS trafiği ve belirgin bir izleme izi bırakır; somut bir performans kazancı sağlamaz.
Gizlilik öncelikli uygulamalar: VPN yönetim panelleri, şifreli mesajlaşma arayüzleri veya güvenlik araçlarının yönetim ekranları, DNS sorgularının minimum ve öngörülebilir olmasına dayanır. Bu tür sayfalarda tüm prefetch direktiflerini kaldırın, X-DNS-Prefetch-Control: off başlığını ekleyin.
Kimlik doğrulama gerektiren sayfalar: Kullanıcıya özgü pano, sepet veya profil sayfalarında çekilen kaynaklar büyük olasılıkla önbellektedir. Bu sayfalarda DNS bilgisini erken yaymak gereksiz risk ekler, belirgin bir kazanç getirmez.
Aynı altyapıya yönelen CNAME kayıtları için: Bağlantı zaten kurulmuşsa o alan adı için dns-prefetch direktifi etkisiz kalır. Vercel veya Netlify gibi platformlarda özel alan adı yapılandırması yaparken, CDN katmanının zaten önbelleğe aldığı alan adlarını ayrıca prefetch listesine eklemek anlamsızdır.
Direktif Listesini Nasıl Oluşturur ve Güncel Tutarsınız?
Hangi alan adlarının prefetch listesine gireceğini belirlemek için tarayıcı geliştirici araçlarının Ağ (Network) sekmesini kullanın. Timing görünümünde DNS Lookup sütununu inceleyin. 50ms üzerinde seyreden harici alan adları iyi adaylardır. 5-10ms arasında kalan bir alan adı zaten önbellektedir; o alan adı için direktif eklemek pratik fark yaratmaz.
Liste zamanla eskir. Yeni bir analitik entegrasyonu, CDN geçişi veya ödeme sağlayıcısı değişikliği prefetch listenizi doğrudan etkiler. Harici servislerin alan adlarını düzenli aralıklarla gözden geçirmek, gereksiz direktiflerin birikmesini önler.
Subdomain düzeyinde prefetch eklerken dikkatli olmak gerekir. Ana alan adını (example.com) prefetch etmek, onun tüm subdomain'lerini (cdn.example.com, api.example.com) kapsamaz; her biri ayrı DNS kaydıdır ve ayrı direktif ister. Bu ayrım, subdomain yönetimi sırasında fazla veya eksik direktif eklenmesine yol açabilir.
Büyük ölçekli altyapılarda DNS zone'larını ve harici bağımlılıkları merkezi bir belgeyle takip etmek bu yönetimi kolaylaştırır. Google Cloud DNS ile zone yönetimi yapıyorsanız, prefetch listenizdeki alan adlarının çözümlendiği nameserver'ları ve TTL değerlerini de izlemek tutarlı bir tablo sunar. Direktif listesini zone belgesiyle birlikte güncellemek, değişikliklerin gözden kaçmasını engeller.
Direktifleri <head> içinde render-blocking CSS ve kritik scriptlerin hemen ardına yerleştirin. Tarayıcı bu direktifleri ayrıştırdığı anda sorguyu arka planda başlatır; ne kadar erken görülürse prefetch'in tamamlanma olasılığı o kadar artar. Preconnect direktifleri varsa önce, dns-prefetch direktifleri hemen ardından sıralanmalıdır:
<head>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="//www.google-analytics.com">
<link rel="dns-prefetch" href="//js.stripe.com">
</head>DNS sağlayıcınızın genel yanıt süresi de prefetch'in etkinliğini belirler. Kullanıcıların sorgu gönderdiği resolver ne kadar hızlıysa direktif o kadar erken tamamlanır; bu, yalnızca kodla değil altyapı seçimiyle de ilgili bir değişkendir.
DNS prefetching, sayfa yapısını değiştirmeden uygulanabilen, geri alınması kolay ve düşük riskli bir yapılandırma adımıdır. Doğru alan adları için ve gerçekten ihtiyaç duyulan sayfalarda kullanıldığında, değişken ağ koşullarında gerçek kullanıcılar için tutarlı bir kazanç sağlar.
Gizlilik boyutunu tek seferlik bir değerlendirme olarak görmemek gerekir. Sitenizin aldığı harici bağımlılıklar değiştikçe, hangi alan adlarının DNS bilgisini kullanıcı adına önceden yaydığınızı da güncel tutmak istersiniz. X-DNS-Prefetch-Control başlığı ve direktiflerin dikkatli seçimi birlikte çalıştığında, ne performanstan ne gizlilikten gereksiz taviz vermek zorunda kalırsınız.
Alan adlarınızın ve harici servislerinizin genel DNS mimarisine daha kapsamlı bir bakış atmak, bu küçük direktifin nereye oturduğunu netleştirir. Domain portföyü yönetimi ve harici bağımlılıkların takibi, tek tek direktif kararlarını daha tutarlı bir çerçeveye oturtmanızı sağlar.