Optimierung der DNS-Auflösungsgeschwindigkeit für SEO

Jeder Besuch auf Ihrer Website beginnt mit einer Frage: Welche IP-Adresse gehört zu diesem Hostnamen? Solange diese Frage nicht beantwortet ist, kann der Browser keine Verbindung aufbauen, kein TLS aushandeln und kein einziges Byte HTML anfordern. Die DNS-Auflösung ist damit der allererste Schritt beim Laden einer Seite – und genau deshalb taucht „DNS-Geschwindigkeit und SEO“ in Performance-Audits so häufig auf.

Die ehrliche Antwort ist allerdings differenzierter, als viele Ratgeber vermuten lassen. Der DNS-Lookup ist normalerweise nur ein kleiner Teil der gesamten Ladezeit, er wird intensiv zwischengespeichert, und Suchmaschinen bewerten Websites nicht direkt nach DNS-Zeiten. Was DNS aber kann: Erstbesuche, Nutzer in langsamen Netzen und Seiten, die Ressourcen von vielen unterschiedlichen Hostnamen laden, unbemerkt ausbremsen. Dieser Leitfaden zeigt, woher diese Verzögerung kommt, wie Sie sie messen und welche Maßnahmen sich wirklich lohnen.

Wo DNS im Ablauf des Seitenaufbaus steht

Lädt ein Browser eine Seite von einem Hostnamen, den er in letzter Zeit nicht aufgerufen hat, läuft das ungefähr so ab:

1. DNS-Lookup – der Hostname wird in eine IP-Adresse aufgelöst.
2. TCP-Verbindung – zu dieser Adresse wird eine Verbindung geöffnet (bei HTTP/3 ein QUIC-Handshake).
3. TLS-Aushandlung – Zertifikate werden ausgetauscht und die Verschlüsselung eingerichtet.
4. Anfrage und Serververarbeitung – der Server erzeugt die Antwort und beginnt mit dem Senden.

Die Time to First Byte (TTFB) umfasst alle diese Schritte. Auf einer gut betriebenen Website dominieren in der Regel Serververarbeitung und Netzwerk-Roundtrips; der DNS-Anteil liegt bei gecachten Antworten oft bei wenigen Millisekunden, ohne Cache bei einigen Dutzend. Relevant wird er erst, wenn etwas nicht stimmt: ein weit entfernter oder überlasteter autoritativer Server, eine lange Kette von Aliasen oder sehr kurze TTLs, die das Caching aushebeln.

Wenn Ihnen die Grundlagen der Auflösung noch neu sind, erklärt unser Einsteigerleitfaden zur Funktionsweise von DNS Root-, TLD- und autoritative Server Schritt für Schritt.

Resolver-Latenz vs. autoritative Latenz

An einem DNS-Lookup sind zwei unterschiedliche Arten von Servern beteiligt – und sie gehören unterschiedlichen Betreibern.

Der rekursive Resolver

Das ist der Server, den das Gerät des Besuchers fragt: meist der Resolver des Internetanbieters, ein Firmen-Resolver oder ein öffentlicher Dienst. Er antwortet aus seinem Cache, sofern möglich. Sie haben keinen Einfluss darauf und können den Resolver eines Besuchers nicht schneller machen.

Der autoritative Nameserver

Hat der Resolver keine Antwort im Cache, arbeitet er sich durch die Hierarchie und fragt schließlich Ihre autoritativen Nameserver – also jene, die in den NS-Records Ihrer Domain eingetragen sind. Deren Geschwindigkeit, Standort und Zuverlässigkeit liegen in Ihrer Verantwortung. Deshalb ist die Wahl des DNS-Anbieters so wichtig.

So messen Sie die DNS-Auflösungszeit

Messen Sie, bevor Sie etwas ändern. Wer rät, nimmt oft Änderungen vor, die keinen sichtbaren Unterschied bringen.

Mit dig auf der Kommandozeile

Das Werkzeug dig gibt für jede Anfrage eine „Query time“ aus. Eine Abfrage über einen öffentlichen Resolver zeigt, was ein typischer Besucher erlebt; eine direkte Abfrage beim autoritativen Server isoliert dagegen die Leistung Ihres Anbieters.

# 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

Führen Sie jede Abfrage mehrmals aus. Die erste Resolver-Anfrage kann langsam sein, spätere sind dank Cache schnell – genau dieser Unterschied zeigt Ihnen, was ein Cache-Miss kostet. Wiederholen Sie die autoritative Abfrage nach Möglichkeit von mehreren Standorten aus, denn ein Server, der aus Europa schnell antwortet, kann aus Asien langsam sein.

Mit den Entwicklertools des Browsers

Öffnen Sie in Chrome oder Edge die DevTools, wechseln Sie zum Network-Panel, wählen Sie eine Anfrage aus und öffnen Sie den Tab „Timing“. Die Zeile „DNS Lookup“ zeigt, wie lange die Auflösung für diese Verbindung gedauert hat. Firefox zeigt eine vergleichbare Phase „DNS-Auflösung“. Deaktivieren Sie den Cache und nutzen Sie ein privates Fenster, um einen kalten Lookup zu sehen – bedenken Sie aber, dass auch das Betriebssystem Antworten zwischenspeichern kann. Labortools wie WebPageTest zeigen die DNS-Zeit ebenfalls im Wasserfalldiagramm für jeden Hostnamen.

Mit Felddaten

Die Navigation Timing API stellt domainLookupStart und domainLookupEnd bereit, sodass Real-User-Monitoring-Tools die DNS-Zeit echter Besucher erfassen können. Felddaten liefern das ehrlichste Bild, weil sie reale Netze, Geräte und Cache-Zustände widerspiegeln.

TTL: Balance zwischen Tempo und Flexibilität

Jeder DNS-Record trägt eine Time To Live – die Anzahl Sekunden, die Resolver ihn zwischenspeichern dürfen. Längere TTLs bedeuten mehr Cache-Treffer und weniger Anfragen an Ihre autoritativen Server; kürzere TTLs sorgen dafür, dass sich Änderungen schneller verbreiten, aber mehr Besucher die Kosten eines frischen Lookups tragen.

• Stabile Records wie NS- und MX-Records oder A-Records für Server, die selten umziehen, vertragen problemlos TTLs von mehreren Stunden oder einem Tag.
• Records, die Sie kurzfristig ändern müssen, etwa bei einer Migration oder einem Failover, können Sie ein bis zwei Tage vorher vorübergehend senken, zum Beispiel auf 300 Sekunden.
• Durchgehend sehr niedrige TTLs sind meist ein Fehler – es sei denn, Ihr Anbieter setzt sie bewusst für Traffic-Steuerung ein.

Beachten Sie, dass manche Resolver eigene Mindest- oder Höchstwerte für die Cache-Dauer durchsetzen. Die TTL ist also ein starker Hinweis, keine absolute Garantie.

CNAME-Ketten kürzen

Ein CNAME verweist einen Namen auf einen anderen. Jeder Schritt in der Kette kann einen weiteren Lookup erfordern, wenn das Ziel nicht im Cache liegt – und die Ziele liegen oft in anderen Zonen bei anderen Anbietern. Zeigt www auf einen CDN-Hostnamen, dieser auf einen regionalen Hostnamen und dieser schließlich auf einen A-Record, können bei kaltem Cache mehrere getrennte Auflösungen nötig sein.

Praktische Schritte:

• Prüfen Sie Ihre wichtigen Hostnamen mit dig und zählen Sie die CNAME-Sprünge.
• Entfernen Sie überflüssige Zwischen-Aliase, die Sie selbst angelegt haben.
• Nutzen Sie am Zonen-Apex, wo ein normaler CNAME nicht erlaubt ist, die ALIAS-, ANAME- oder CNAME-Flattening-Funktion Ihres Anbieters, die direkt eine Adresse zurückgibt.
• Halten Sie die Zahl externer Hostnamen klein, denn jede eigene Domain braucht einen eigenen Lookup.

Resource Hints: dns-prefetch und preconnect

Browser erlauben es, die DNS-Arbeit für Hostnamen, die eine Seite sicher brauchen wird, frühzeitig anzustoßen.

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

• dns-prefetch löst nur den Namen auf. Das ist günstig und breit unterstützt und eignet sich für Hostnamen, die möglicherweise benötigt werden.
• preconnect löst den Namen auf und öffnet zusätzlich die TCP- und TLS-Verbindung. Das spart mehr Zeit, kostet aber Ressourcen – beschränken Sie es auf wenige kritische Origins, die früh im Ladevorgang gebraucht werden.

Preconnect zu vielen Origins kann nach hinten losgehen, weil es mit wichtigeren Anfragen konkurriert. Setzen Sie Hints für Drittanbieter-Origins im kritischen Rendering-Pfad ein, etwa einen Font-Host oder ein Bild-CDN – nicht für Ihren eigenen Haupt-Hostnamen, den der Browser ohnehin bereits auflöst.

DNS und Core Web Vitals

Die Core Web Vitals messen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). DNS gehört nicht dazu und ist auch kein direktes Ranking-Signal. Der Einfluss ist indirekt: Eine langsamere Auflösung erhöht die TTFB, und die TTFB ist Teil des LCP. Auch Lookups für ein Hero-Bild auf einer anderen Domain können den LCP verzögern.

Auf INP und CLS hat DNS praktisch keinen Einfluss. Zeigen Ihre Felddaten also einen schlechten LCP, prüfen Sie die DNS-Zeit im Wasserfall – größere Gewinne sind aber meist bei Server-Antwortzeiten, Bildoptimierung und render-blockierenden Ressourcen zu holen. Betrachten Sie DNS als Teil guter technischer Hygiene, neben zuverlässigem Hosting und gültigen Zertifikaten.

DNS-Anbieter auswählen und überwachen

Achten Sie auf autoritativer Seite auf einen Anbieter mit Servern in vielen Regionen (meist per Anycast), einer soliden Verfügbarkeitshistorie, Unterstützung moderner Funktionen wie DNSSEC und Apex-Aliasing sowie einer klaren Dokumentation. Das kostenlose DNS Ihres Registrars kann für kleine Websites völlig ausreichen; große oder internationale Zielgruppen profitieren eher von einem spezialisierten Anbieter.

Geschwindigkeit setzt außerdem voraus, dass die Grundlagen stimmen. Eine abgelaufene Domain oder ein ausgelaufener DNS-Hosting-Tarif macht die Auflösung nicht langsam, sondern lässt sie komplett scheitern. Mit dem WHOIS- und Hosting-Lookup von TLDix sehen Sie, welche Nameserver eine Domain nutzt, samt Registrierungs- und Hosting-Details – und Sie behalten Verlängerungstermine für Domains, SSL-Zertifikate und Hosting an einem Ort im Blick, damit nichts unbemerkt ausläuft.

Typische Fehler aus der Praxis

In Audits begegnen uns immer wieder dieselben Muster, die sich mit wenig Aufwand beheben lassen:

• Vergessene TTL nach einer Migration: Die TTL wurde vor dem Umzug auf 60 Sekunden gesenkt und danach nie wieder angehoben. Ergebnis: dauerhaft mehr Cache-Misses ohne jeden Nutzen.
• Nameserver nur in einer Region: Alle NS-Einträge zeigen auf Server im selben Rechenzentrum. Fällt dieses aus, ist die Domain nicht erreichbar, und Besucher auf anderen Kontinenten warten bei jedem Cache-Miss länger.
• Zu viele Tracking- und Widget-Domains: Jedes zusätzliche Skript eines Drittanbieters bringt oft einen eigenen Hostnamen mit. Ein kritischer Blick auf eingebundene Dienste spart Lookups und meist auch Datenschutzaufwand.

Prüfen Sie diese Punkte am besten einmal pro Quartal oder nach jeder größeren Infrastrukturänderung.

Kurze Optimierungs-Checkliste

1. DNS-Zeit mit dig, DevTools und idealerweise echten Nutzerdaten messen.
2. Sicherstellen, dass Ihre autoritativen Nameserver aus den Regionen Ihrer Zielgruppe schnell antworten.
3. TTLs so setzen, dass sie zur tatsächlichen Änderungshäufigkeit der Records passen.
4. Überflüssige CNAME-Sprünge entfernen und bei Bedarf Apex-Flattening nutzen.
5. Die Zahl unterschiedlicher Drittanbieter-Hostnamen reduzieren.
6. dns-prefetch oder preconnect nur für kritische externe Origins einsetzen.
7. Nameserver-Konfiguration und Verlängerungstermine überwachen, damit die Auflösung nie ausfällt.

Keiner dieser Schritte wird Ihre Rankings allein umkrempeln. Gemeinsam beseitigen sie aber eine vermeidbare Verzögerung ganz am Anfang jedes Besuchs – und genau darum geht es bei nutzerorientierter Performance-Arbeit.