Den Unterbereich DNS-Dauer des Time to First Byte minimieren

Die DNS-Dauer misst die DNS-Lookups des Browsers. Erfahren Sie, wie Sie einen schnellen DNS-Anbieter wählen, TTL-Einstellungen optimieren, dns-prefetch verwenden und DNS über HTTPS verstehen, um den TTFB zu reduzieren.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05
[include]breadcrumbs.html[\/include]

Den Unterbereich DNS-Dauer des Time to First Byte minimieren

Dieser Artikel ist Teil unseres Leitfadens zum [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte (TTFB)[\/url]. Die DNS-Dauer ist der dritte Unterbereich des TTFB und stellt die Zeit dar, die der Browser benötigt, um Ihren Domainnamen in eine IP-Adresse aufzulösen. Für Erstbesucher, die keinen DNS-Eintrag im Cache haben, kann der DNS-Lookup dem TTFB 20 bis 200 Millisekunden hinzufügen, abhängig vom DNS-Anbieter, dem geografischen Standort des Benutzers und den TTL-Einstellungen Ihrer DNS-Einträge.

Der Time to First Byte (TTFB) kann in die folgenden Unterbereiche unterteilt werden:

  • [url=\/core-web-vitals\/time-to-first-byte\/waitingduration]Waiting + Redirect (oder Waiting Duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Worker + Cache (oder Cache Duration)
  • DNS (oder DNS-Dauer)
  • [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection (oder Connection Duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request (oder Request Duration)

    Möchten Sie den Time to First Byte optimieren? Dieser Artikel behandelt den Teil "DNS-Dauer" des Time to First Byte. Wenn Sie den Time to First Byte verstehen oder beheben möchten und nicht wissen, was DNS-Dauer bedeutet, lesen Sie bitte [url=\/core-web-vitals\/time-to-first-byte]Was ist der Time to First Byte?[\/url] und [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]Time to First Byte Probleme identifizieren und beheben[\/url], bevor Sie mit diesem Artikel beginnen.

    DNS-Schnelllösung: Wenn Sie DNS-Latenz beim Time to First Byte feststellen, wechseln Sie zu einem Premium-DNS-Anbieter und aktualisieren Sie Ihre TTL-Einstellungen!

    Der Teil DNS-Dauer des Time to First Byte besteht aus der Zeit, in der der Browser die Internetadresse (IP) für Ihre Website nachschlägt. Wir benötigen DNS-Abfragen, da es für uns Menschen einfacher ist, uns Domainnamen wie "www.example.com" zu merken, während Computer numerische IP-Adressen benötigen, um sich miteinander zu verbinden.

    [include]toc.html[\/include]

    Wie funktioniert DNS?

    DNS-Anfragen sind in der TTFB-Messung enthalten. Dies bedeutet, dass die Zeit, die für den Abschluss der DNS-Anfrage benötigt wird, in den gesamten TTFB-Score einfließt.

    Wenn eine Seite angefordert wird, führt Ihr Browser diese Schritte aus, um den Domainnamen in eine IP-Adresse umzuwandeln:

    • Der DNS-Cache des Browsers wird geprüft: Bevor der Browser eine DNS-Anfrage stellt, prüft er zunächst seinen eigenen DNS-Cache, um zu sehen, ob er bereits die IP-Adresse für die angeforderte Domain hat. Moderne Browser speichern DNS-Einträge für einen bestimmten Zeitraum, um die Leistung zu verbessern, indem sie die Notwendigkeit wiederholter DNS-Abfragen verringern. Wenn der Eintrag im Cache des Browsers gefunden wird, kann der Browser ihn sofort ohne weitere Anfragen verwenden.
    • Der Cache des Betriebssystems (OS) wird geprüft: Wenn der Cache des Browsers den benötigten DNS-Eintrag nicht enthält, wird die Anfrage an den DNS-Resolver des Betriebssystems weitergeleitet, der oft als "Stub-Resolver" bezeichnet wird. Das Betriebssystem unterhält ebenfalls einen DNS-Cache und prüft diesen, bevor es Netzwerkanfragen sendet.
    • DNS-Abfrage: Wenn der DNS-Eintrag weder im Browser- noch im OS-Cache gefunden wird, wird eine rekursive DNS-Abfrage an einen DNS-Resolver gesendet, der in der Regel von dem Internetdienstanbieter (ISP) des Benutzers bereitgestellt wird. Dieser Resolver fungiert als Vermittler und übernimmt den Prozess der Abfrage anderer DNS-Server, um die IP-Adresse zu finden.
      • Root-Nameserver: Der Resolver kontaktiert zuerst einen Root-Nameserver, der ihn basierend auf der Domain-Endung (z. B. ".com", ".org") an den entsprechenden Top-Level-Domain-Server (TLD) weiterleitet.
      • TLD-Nameserver: Der TLD-Server leitet den Resolver dann an den autoritativen Nameserver für die spezifische Domain weiter.
      • Autoritativer Nameserver: Dieser Server hält die DNS-Einträge für die Domain bereit und liefert dem Resolver die IP-Adresse.
      • Rückgabe der IP-Adresse: Sobald der DNS-Resolver die IP-Adresse vom autoritativen Server erhalten hat, gibt er diese Information an den Browser zurück. Der Browser kann dann unter Verwendung der IP-Adresse eine Verbindung zum Server initiieren, um die angeforderte Webseite zu laden.

        Wie beeinflusst DNS den Time to First Byte?
        Der DNS-Lookup kann den Time to First Byte entweder aufgrund der Netzwerklatenz (die Zeit, die benötigt wird, um in diesem Fall eine Verbindung zum Nameserver aufzubauen), der Qualität und Geschwindigkeit des autoritativen Nameservers oder der DNS-Cache-Zeit (da zwischengespeicherte DNS-Abfragen viel schneller sind als nicht zwischengespeicherte) verlangsamen.

        Bei wiederkehrenden Besuchern wird der DNS-Lookup in der Regel im Browser oder im Betriebssystem zwischengespeichert, wodurch sich die DNS-Dauer auf nahezu Null reduziert. Bei Erstbesuchern muss jedoch der vollständige rekursive DNS-Lookup abgeschlossen sein, bevor der Browser mit dem Schritt der TCP-Verbindung fortfahren kann. Aus diesem Grund ist der TTFB bei neuen Besuchern oft messbar schlechter als bei wiederkehrenden Besuchern.

        dns-prefetch und preconnect für Drittanbieter-Domains verwenden

        Wenn Ihre Seite Ressourcen von Drittanbieter-Domains lädt (z. B. Analytics, Schriftarten oder CDN-Subdomains), muss der Browser das DNS für jede Domain separat auflösen. Sie können den Browser anweisen, die DNS-Auflösung frühzeitig zu starten, indem Sie den Ressourcenhinweis dns-prefetch verwenden:

        <!-- DNS-Prefetch für Drittanbieter-Domains -->
        <link rel="dns-prefetch" href="https:\/\/fonts.googleapis.com">
        <link rel="dns-prefetch" href="https:\/\/cdn.example.com">
        <link rel="dns-prefetch" href="https:\/\/analytics.example.com">
                        

        Für kritische Drittanbieter-Ursprünge, bei denen Sie wissen, dass Sie auch eine TCP- und TLS-Verbindung aufbauen müssen, verwenden Sie stattdessen preconnect, was die DNS-Auflösung plus den Verbindungs-Handshake beinhaltet:

        <link rel="preconnect" href="https:\/\/fonts.googleapis.com">
        <link rel="preconnect" href="https:\/\/fonts.gstatic.com" crossorigin>
                        

        Verwenden Sie dns-prefetch als Fallback für Browser, die preconnect nicht unterstützen:

        <link rel="preconnect" href="https:\/\/fonts.googleapis.com">
        <link rel="dns-prefetch" href="https:\/\/fonts.googleapis.com">
                        

        Platzieren Sie diese Hinweise so früh wie möglich im <head> Ihres HTML. Fügen Sie nur Hinweise für Domains hinzu, die Ihre Seite tatsächlich verwendet; das Hinzufügen von Hinweisen für ungenutzte Domains verschwendet Browser-Ressourcen. Weitere Optimierungstechniken im Zusammenhang mit dem Laden von Ressourcen finden Sie in unserem Leitfaden zu [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url].

        So minimieren Sie die DNS-Auswirkung auf den TTFB

        Einen schnellen DNS-Anbieter verwenden

        Einige DNS-Anbieter sind schneller als andere. Die Wahl eines schnellen und zuverlässigen DNS-Anbieters ist einer der einfachsten Wege, um DNS-Latenz zu reduzieren. Premium-DNS-Anbieter wie Cloudflare, Amazon Route 53 und Google Cloud DNS betreiben Server an Hunderten von Standorten weltweit. Je näher der DNS-Server an Ihrem Benutzer liegt, desto schneller ist das Nachschlagen.

        Hier ist ein Vergleich beliebter DNS-Anbieter und ihrer typischen Antwortzeiten:

        DNS-Anbieter Typische Antwortzeit Globale PoPs Wichtige Funktionen
        Cloudflare DNS ~11ms 300+ Kostenlose Stufe verfügbar, DNSSEC, CNAME-Flattening
        Amazon Route 53 ~20ms 100+ Health Checks, latenzbasiertes Routing, Geolocation
        Google Cloud DNS ~15ms Anycast global 100% Uptime SLA, DNSSEC
        NS1 ~15ms 25+ Filterketten, intelligentes DNS-Routing
        Typischer ISP\/Registrar DNS ~50 bis 100ms Begrenzt Nur Grundfunktionen

        Der Unterschied zwischen einem Premium-DNS-Anbieter und einem einfachen Registrar-DNS kann 40 bis 90 Millisekunden pro Abfrage betragen (Quelle: [url=https:\/\/www.dnsperf.com\/]DNSPerf[\/url] Benchmarks). Für Erstbesucher bedeutet dies direkt einen schnelleren TTFB. Um zu erfahren, wie Sie Cloudflare als Ihren DNS- und CDN-Anbieter einrichten, lesen Sie unseren [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Leitfaden zur Konfiguration von Cloudflare[\/url].

        Die DNS-Cache-Gültigkeitsdauer (TTL) optimieren

        DNS-Caching speichert DNS-Abfrageergebnisse lokal und reduziert so die Notwendigkeit wiederholter Abfragen. Durch Einstellen "optimaler" TTL-Werte (Time-To-Live) für DNS-Einträge können Sie steuern, wie lange diese Einträge zwischengespeichert werden.

        Niedrigere TTL-Werte bedeuten, dass Einträge früher ablaufen, was zu häufigeren DNS-Abfragen führt. Höhere TTL-Werte bedeuten, dass Einträge länger zwischengespeichert werden, was DNS-Abfragen reduziert, aber DNS-Änderungen langsamer verbreitet. Die richtige TTL hängt davon ab, wie häufig Sie Ihre DNS-Einträge ändern und wie sehr Sie DNS-Abfragegeschwindigkeit gegenüber Flexibilität schätzen.

        Was sind optimale DNS-TTL-Einstellungen?
        A- und AAAA-Einträge (IP-Adressdatensätze): Für die meisten Websites: 5 Minuten bis 1 Stunde. Für statische Websites, die sich nicht häufig ändern: 1 bis 24 Stunden.
        CNAME-Einträge: Normalerweise 24 Stunden.
        TXT- und MX-Einträge: Etwa 12 Stunden.
        NS-Einträge: Längere TTLs, wie z. B. 1 bis 2 Tage, da diese kritisch und im Allgemeinen statisch sind.
        SOA- und andere statische Einträge: Längere TTLs, bis zu einigen Tagen.

        Wenn Sie eine DNS-Migration oder einen Serverwechsel planen, senken Sie Ihre TTL mindestens 24 Stunden vor der Änderung vorübergehend auf 5 Minuten (300 Sekunden). Dies stellt sicher, dass Benutzer nach der Änderung schnell die neue IP-Adresse erhalten. Sobald die Migration abgeschlossen und verifiziert ist, erhöhen Sie die TTL wieder auf einen höheren Wert, um die Häufigkeit der DNS-Abfragen zu reduzieren.

        TIPP: Wenn Sie CNAME-Einträge verwenden, sollten Sie die Implementierung von CNAME-Flattening in Betracht ziehen. CNAME-Flattening ist eine Technik, die es Ihnen ermöglicht, einen CNAME-Eintrag auf der Root-(Apex-)Domain-Ebene zu verwenden und ihn effektiv in eine IP-Adresse aufzulösen, ohne gegen DNS-Standards zu verstoßen. Dies eliminiert eine zusätzliche DNS-Abfrage, die andernfalls erforderlich wäre, um den CNAME zu seinem Ziel und dann das Ziel zu seiner IP-Adresse aufzulösen.

        DNS over HTTPS (DoH) und DNS over TLS (DoT)

        Traditionelle DNS-Abfragen werden im Klartext über UDP gesendet, was bedeutet, dass sie von Vermittlern (wie ISPs oder Netzwerkbetreibern) abgefangen, geändert oder blockiert werden können. DNS over HTTPS (DoH) und DNS over TLS (DoT) verschlüsseln DNS-Abfragen und verbessern so sowohl den Datenschutz als auch die Sicherheit.

        Während DoH und DoT primär Sicherheits- und Datenschutzbedenken adressieren, können sie auch die Leistung der DNS-Auflösung beeinflussen:

        • Latenzauswirkung: Der Verschlüsselungs-Overhead fügt der initialen DNS-Verbindung (TLS-Handshake) eine geringe Latenz hinzu. Da DoH\/DoT-Verbindungen jedoch dauerhaft sind und wiederverwendet werden, sind nachfolgende Abfragen über dieselbe Verbindung oft schneller als bei herkömmlichem DNS.
        • ISP-Eingriffe: Einige ISPs schleusen ihre eigenen DNS-Antworten ein oder verlangsamen DNS-Abfragen für Nicht-Kunden. DoH umgeht diese Eingriffe vollständig, was die DNS-Auflösungszeit für betroffene Benutzer tatsächlich verbessern kann.
        • Browser-Unterstützung: Moderne Browser (Chrome, Firefox, Edge, Safari) unterstützen alle DoH. In den meisten Fällen verwendet der Standard-DNS-Anbieter des Browsers bereits DoH, sofern verfügbar.

          Als Website-Besitzer können Sie nicht kontrollieren, ob Ihre Besucher DoH oder DoT verwenden (dies ist eine Einstellung auf Browser- und OS-Ebene). Sie können jedoch sicherstellen, dass Ihr autoritativer DNS-Anbieter DNSSEC unterstützt, was eine ergänzende Verifizierungsebene für DNS-Antworten unabhängig von der Transportverschlüsselung bietet.

          DNS-Dauer mit JavaScript messen

          Sie können den Unterbereich DNS-Dauer des TTFB direkt im Browser mithilfe der Navigation Timing API messen:

          new PerformanceObserver((entryList) => {
            const [nav] = entryList.getEntriesByType('navigation');
            const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
          
            console.log('DNS-Dauer:', dnsDuration.toFixed(0), 'ms');
          
            if (dnsDuration > 50) {
              console.warn('Hohe DNS-Dauer erkannt. Erwägen Sie:');
              console.warn('1. Wechsel zu einem Premium-DNS-Anbieter');
              console.warn('2. Erhöhung der DNS-TTL-Werte');
              console.warn('3. Verwendung von dns-prefetch für Drittanbieter-Domains');
            }
          }).observe({
            type: 'navigation',
            buffered: true
          });
                          

          Eine DNS-Dauer von 0 ms in Ihren RUM-Daten weist in der Regel darauf hin, dass der DNS-Lookup aus dem Browser- oder Betriebssystem-Cache bedient wurde (Szenario für wiederkehrende Besucher). Werte über 50 ms deuten darauf hin, dass der Benutzer einen vollständigen rekursiven DNS-Lookup durchführen musste, was bei Erstbesuchern üblich ist.

          Messen von TTFB-Problemen durch langsame DNS-Abfragen

          Um die Auswirkungen zu ermitteln, die echte Benutzer durch DNS-Latenz erfahren, müssen Sie ein RUM-Tool wie CoreDash verwenden. Mit Real User Monitoring können Sie die Core Web Vitals detaillierter und ohne die 28-tägige Google-Verzögerung verfolgen.

          Klicken Sie in CoreDash auf "Time to First Byte breakdown", um den DNS-Teil des Time to First Byte zu visualisieren.

          Weiterführende Literatur: Optimierungsleitfäden

          Verwandte Leitfäden: