SEO İçin DNS Çözümleme Hızını Optimize Etmek

Sitenize yapılan her ziyaret tek bir soruyla başlar: Bu ana makine adına hangi IP adresi ait? Bu soru yanıtlanmadan tarayıcı bağlantı açamaz, TLS anlaşmasını başlatamaz ve tek bir bayt HTML bile isteyemez. Bu nedenle DNS çözümlemesi sayfa yüklemenin ilk adımıdır ve performans denetimlerinde “SEO için DNS hızı” konusunun bu kadar sık gündeme gelmesinin sebebi de budur.

Yine de dürüst yanıt, pek çok rehberin ima ettiğinden daha nüanslıdır. DNS sorgusu normalde toplam yükleme süresinin küçük bir bölümüdür, yoğun biçimde önbelleğe alınır ve arama motorları siteleri doğrudan DNS süresine göre sıralamaz. DNS’in yapabileceği şey, ilk ziyaretlere, yavaş ağlardaki kullanıcılara ve kaynaklarını çok sayıda farklı ana makineden çeken sayfalara sessizce gecikme eklemektir. Bu rehberde bu gecikmenin nereden geldiğini, nasıl ölçüleceğini ve hangi düzeltmelerin zamanınıza değdiğini anlatıyoruz.

DNS, Sayfa Yükleme Zaman Çizelgesinin Neresinde?

Tarayıcı yakın zamanda görmediği bir ana makine adından sayfa yüklerken süreç kabaca şöyle işler:

1. DNS sorgusu – ana makine adı bir IP adresine çözümlenir.
2. TCP bağlantısı – bu adrese bir bağlantı açılır (HTTP/3 için QUIC el sıkışması yapılır).
3. TLS anlaşması – sertifikalar değiş tokuş edilir ve şifreleme kurulur.
4. İstek ve sunucu işlemesi – sunucu yanıtı hazırlar ve göndermeye başlar.

İlk Bayta Kadar Geçen Süre (TTFB) bu adımların tamamını kapsar. İyi yönetilen bir sitede çoğunlukla sunucu işleme süresi ve ağdaki gidiş-dönüşler baskındır; yanıt önbellekteyse DNS payı genellikle birkaç milisaniye, değilse onlarca milisaniye düzeyindedir. DNS ancak bir şeyler ters gittiğinde önem kazanır: uzak ya da aşırı yüklü bir yetkili sunucu, uzun bir takma ad zinciri ya da önbelleği işe yaramaz hâle getiren çok kısa TTL değerleri.

Çözümlemenin mekaniğine yabancıysanız, DNS’in nasıl çalıştığını anlatan başlangıç rehberimiz kök, TLD ve yetkili sunucuları adım adım açıklıyor.

Çözümleyici Gecikmesi ve Yetkili Sunucu Gecikmesi

Bir DNS sorgusunda iki farklı türde sunucu yer alır ve bunların sahipleri de farklıdır.

Özyinelemeli çözümleyici

Ziyaretçinin cihazının soru sorduğu sunucudur: genellikle ISS’in çözümleyicisi, bir şirket çözümleyicisi ya da genel bir DNS hizmeti. Mümkün olduğunda yanıtı önbelleğinden verir. Bu sunucuyu siz yönetmezsiniz ve bir ziyaretçinin çözümleyicisini hızlandıramazsınız.

Yetkili ad sunucusu

Çözümleyicinin önbellekte yanıtı yoksa hiyerarşide ilerler ve sonunda alan adınızın NS kayıtlarında listelenen yetkili ad sunucularınıza ulaşır. Bu sunucuların hızı, konumu ve güvenilirliği sizin sorumluluğunuzdadır; DNS sağlayıcısı seçiminin önemli olmasının nedeni de budur.

DNS Çözümleme Süresi Nasıl Ölçülür?

Herhangi bir değişiklik yapmadan önce ölçün. Tahmine dayalı müdahaleler çoğu zaman gözle görülür bir fark yaratmayan değişikliklerle sonuçlanır.

Komut satırında dig kullanmak

dig aracı her istek için bir “Query time” değeri bildirir. Genel bir çözümleyiciyi sorgulamak, tipik bir ziyaretçinin ne yaşayabileceğini gösterir; yetkili sunucunuzu doğrudan sorgulamak ise sağlayıcınızın performansını yalıtır.

# Through a resolver (may be cached)
dig www.example.com A

# Directly against your authoritative nameserver
dig @ns1.example-dns.net www.example.com A +norecurse

# Follow the full delegation path from the root
dig www.example.com A +trace

Her sorguyu birkaç kez çalıştırın. Önbellek nedeniyle çözümleyiciye yapılan ilk sorgu yavaş, sonrakiler hızlı olabilir; bu fark, bir önbellek ıskalamasının size neye mal olduğunu zaten anlatır. Mümkünse yetkili sunucu sorgusunu birden fazla konumdan tekrarlayın; Avrupa’dan hızlı yanıt veren bir sunucu Asya’dan yavaş olabilir.

Tarayıcı geliştirici araçlarını kullanmak

Chrome ya da Edge’de DevTools’u açın, Network paneline gidin, bir istek seçin ve Timing sekmesini açın. “DNS Lookup” satırı o bağlantı için çözümlemenin ne kadar sürdüğünü gösterir. Firefox da benzer bir “DNS Resolution” aşaması gösterir. Soğuk bir sorguyu görmek için önbelleği devre dışı bırakıp gizli pencere kullanın; ancak işletim sisteminin yanıtları yine de önbellekte tutabileceğini unutmayın. WebPageTest gibi laboratuvar araçları da her ana makine için DNS süresini şelale grafiklerinde gösterir.

Saha verisini kullanmak

Navigation Timing API, domainLookupStart ve domainLookupEnd değerlerini sunar; böylece gerçek kullanıcı izleme (RUM) araçları DNS süresini gerçek ziyaretçilerden raporlayabilir. Saha verisi en dürüst görünümdür, çünkü gerçek ağları, cihazları ve önbellek durumlarını yansıtır.

TTL: Hız ile Esneklik Arasında Denge

Her DNS kaydı bir Time To Live (TTL), yani çözümleyicilerin kaydı kaç saniye önbellekte tutabileceğini belirten bir değer taşır. Uzun TTL daha fazla önbellek isabeti ve yetkili sunucularınıza daha az gidiş anlamına gelir; kısa TTL ise değişikliklerin daha hızlı yayılmasını sağlar ama daha fazla ziyaretçi yeni bir sorgunun bedelini öder.

• Kararlı kayıtlar, örneğin NS ve MX kayıtları ya da nadiren taşınan sunuculara ait A kayıtları, birkaç saatlik ya da bir günlük TTL’leri rahatlıkla kullanabilir.
• Hızla değiştirmeniz gerekebilecek kayıtlar, bir taşıma ya da yük devretme öncesinde geçici olarak düşürülebilir; örneğin değişiklikten bir-iki gün önce 300 saniyeye.
• Her yerde çok düşük TTL kullanmak, sağlayıcınız bunu trafik yönlendirme için bilinçli olarak yapmıyorsa genellikle bir hatadır.

Bazı çözümleyicilerin kendi minimum ya da maksimum önbellek sürelerini uyguladığını unutmayın; TTL mutlak bir garanti değil, güçlü bir ipucudur.

CNAME Zincirlerini Kısaltın

CNAME bir adı başka bir ada yönlendirir. Hedef önbellekte değilse zincirdeki her halka ek bir sorgu gerektirebilir ve hedefler çoğu zaman farklı sağlayıcıların sunduğu farklı bölgelerde bulunur. www adının bir CDN ana makinesine, onun da bölgesel bir ana makineye işaret ettiği ve en sonunda bir A kaydına çözümlendiği bir yapı, soğuk önbellekte birkaç ayrı çözümleme gerektirebilir.

Pratik adımlar:

• Önemli ana makine adlarınızı dig ile denetleyin ve CNAME halkalarını sayın.
• Kendi oluşturduğunuz gereksiz ara takma adları kaldırın.
• Standart CNAME’e izin verilmeyen bölge kökünde (apex), sağlayıcınızın doğrudan adres döndüren ALIAS, ANAME ya da CNAME düzleştirme özelliğini kullanın.
• Üçüncü taraf ana makine sayısını en aza indirin; her farklı alan adı kendi sorgusunu gerektirir.

Kaynak İpuçları: dns-prefetch ve preconnect

Tarayıcılar, bir sayfanın ihtiyaç duyacağını bildiğiniz ana makineler için DNS işlemini erkenden başlatmanıza izin verir.

<link rel="dns-prefetch" href="https://cdn.example.net">
<link rel="preconnect" href="https://fonts.example.org" crossorigin>

• dns-prefetch yalnızca adı çözümler. Ucuzdur ve geniş çapta desteklenir; bu yüzden ihtiyaç duyulabilecek ana makineler için uygundur.
• preconnect adı çözümlemenin yanı sıra TCP ve TLS bağlantısını da açar. Daha fazla zaman kazandırır ama kaynak tüketir; bu nedenle yüklemenin başında gereken birkaç kritik kaynakla sınırlayın.

Çok sayıda kaynağa preconnect uygulamak, daha önemli isteklerle rekabet ederek ters etki yapabilir. İpuçlarını kritik oluşturma yolunuzda yer alan üçüncü taraf kaynaklar için kullanın, örneğin bir yazı tipi sunucusu ya da görsel CDN’i; tarayıcının zaten çözümlediği kendi ana alan adınız için kullanmayın.

DNS ve Core Web Vitals

Core Web Vitals; Largest Contentful Paint (LCP), Interaction to Next Paint (INP) ve Cumulative Layout Shift (CLS) metriklerini ölçer. DNS bunlardan biri değildir ve doğrudan bir sıralama sinyali de değildir. Etkisi dolaylıdır: daha yavaş çözümleme TTFB’yi artırır, TTFB de LCP’nin bir parçasıdır. Başka bir alan adında barındırılan ana görsel için yapılan sorgular da LCP’yi geciktirebilir.

DNS’in INP ya da CLS üzerinde pratikte hiçbir etkisi yoktur. Saha verileriniz zayıf bir LCP gösteriyorsa şelale grafiğinde DNS süresine bakın, ancak asıl kazancın sunucu yanıt sürelerinden, görsel optimizasyonundan ve oluşturmayı engelleyen kaynaklardan gelmesini bekleyin. DNS’i güvenilir barındırma ve geçerli sertifikalar gibi iyi teknik hijyenin bir parçası olarak ele alın.

DNS Sağlayıcısı Seçimi ve İzleme

Yetkili taraf için birçok bölgede sunucusu olan (genellikle anycast kullanan), sağlam bir çalışma süresi geçmişine sahip, DNSSEC ve apex takma adı gibi modern özellikleri destekleyen ve açık belgeler sunan bir sağlayıcı arayın. Kayıt firmanızın ücretsiz DNS hizmeti küçük siteler için gayet yeterli olabilir; büyük ya da küresel kitleler ise uzmanlaşmış bir sağlayıcıdan fayda görebilir.

Hız, temel unsurların sağlıklı kalmasına da bağlıdır. Süresi dolmuş bir alan adı ya da sona ermiş bir DNS barındırma planı çözümlemeyi yavaşlatmaz, tamamen başarısız kılar. Bir alan adının hangi ad sunucularını kullandığını, kayıt ve barındırma ayrıntılarıyla birlikte TLDix WHOIS ve hosting sorgulama aracıyla kontrol edebilir; alan adı, SSL sertifikası ve hosting yenileme tarihlerini tek bir yerde tutarak hiçbir şeyin fark edilmeden sona ermesine izin vermeyebilirsiniz.

Pratik Örnek: Bir Sitenin DNS Denetimini Yarım Saatte Yapmak

Teoriyi uygulamaya dökmek için küçük bir e-ticaret sitesini düşünelim. Ana sayfa kendi alan adından, görseller bir CDN’den, yazı tipleri harici bir hizmetten, analiz betikleri ise iki ayrı üçüncü taraftan yükleniyor. Denetime şelale grafiğiyle başlayın ve sayfanın kaç farklı ana makineye bağlandığını sayın. Beşten fazla farklı alan adı görüyorsanız, her biri soğuk önbellekte ayrı bir DNS sorgusu demektir.

Ardından her önemli ana makine için dig +trace çalıştırın ve CNAME halkalarını not edin. Sık rastlanan bir tablo şudur: www bir CDN adına, o ad bölgesel bir ada, o da sonunda bir IP adresine çözümlenir. Ara halkalardan biri sizin oluşturduğunuz eski bir takma adsa kaldırın. Sonra yetkili sunucularınızı farklı bölgelerden sorgulayın; çevrim içi çoklu konum test araçları bu konuda işinizi kolaylaştırır. Bir bölgede sürekli belirgin biçimde yüksek süreler görüyorsanız, sağlayıcınızın o bölgede sunucusu olmayabilir.

Son olarak TTL değerlerine bakın. Aylardır değişmemiş bir A kaydı hâlâ 60 saniyelik TTL taşıyorsa, muhtemelen eski bir taşıma işleminden kalmıştır ve yükseltilmesi gerekir. Bu üç kontrolün sonuçlarını basit bir tabloya yazın; bir sonraki denetimde karşılaştırma yapabileceğiniz bir referans noktanız olur.

Kısa Optimizasyon Kontrol Listesi

1. DNS süresini dig, DevTools ve mümkünse gerçek kullanıcı verisiyle ölçün.
2. Yetkili ad sunucularınızın, kitlenizin bulunduğu bölgelerden hızlı yanıt verdiğini doğrulayın.
3. TTL değerlerini kayıtların gerçekte ne sıklıkla değiştiğine göre belirleyin.
4. Gereksiz CNAME halkalarını kaldırın ve gereken yerde apex düzleştirme kullanın.
5. Farklı üçüncü taraf ana makine sayısını azaltın.
6. dns-prefetch ya da preconnect’i yalnızca kritik harici kaynaklar için ekleyin.
7. Çözümlemenin hiç bozulmaması için ad sunucusu yapılandırmasını ve yenileme tarihlerini izleyin.

Bu adımların hiçbiri tek başına sıralamalarınızı dönüştürmez. Ancak birlikte, her ziyaretin en başındaki önlenebilir bir gecikme kaynağını ortadan kaldırırlar; insan odaklı performans çalışmasının amacı da tam olarak budur.