Minimaliseer het DNS-duuronderdeel van de Time to First Byte

Minimaliseer het DNS-duuronderdeel van de Time to First Byte

Dit artikel maakt deel uit van onze Time to First Byte (TTFB)-handleiding. De DNS-duur is het derde onderdeel van de TTFB en vertegenwoordigt de tijd die de browser besteedt aan het omzetten van je domeinnaam naar een IP-adres. Voor nieuwe bezoekers die geen gecacht DNS-record hebben, kan de DNS-lookup 20 tot 200 milliseconden toevoegen aan de TTFB, afhankelijk van de DNS-provider, de geografische locatie van de gebruiker en de TTL-instellingen van je DNS-records.

De Time to First Byte (TTFB) kan worden opgesplitst in de volgende onderdelen:

• Wachten + Doorverwijzing (of wachtduur)
• Worker + Cache (of cacheduur)
• DNS (of DNS-duur)
• Verbinding (of verbindingsduur)
• Verzoek (of verzoekduur)

Wilt u de Time to First Byte optimaliseren? Dit artikel behandelt het DNS-duuronderdeel van de Time to First Byte. Als u de Time to First Byte wilt begrijpen of verbeteren en niet weet wat de DNS-duur betekent, lees dan eerst wat is de Time to First Byte en Time to First Byte-problemen identificeren en oplossen voordat u met dit artikel begint.

DNS-snelle oplossing: als u DNS-latentie ervaart in de Time to First Byte, stap dan over naar een premium DNS-provider en pas uw TTL-instellingen aan!

Het DNS-duuronderdeel van de Time to First Byte bestaat uit de tijd waarin de browser het internetadres (IP-adres) van uw site opzoekt. We hebben DNS-lookups nodig omdat wij mensen het makkelijker vinden om domeinnamen zoals "www.example.com" te onthouden, terwijl computers numerieke IP-adressen nodig hebben om met elkaar te communiceren.

Hoe werkt DNS?

DNS-verzoeken worden meegenomen in de TTFB-meting. Dit betekent dat de tijd die het DNS-verzoek nodig heeft om af te ronden, wordt meegerekend in de totale TTFB-score.

Wanneer een pagina wordt opgevraagd, doorloopt uw browser de volgende stappen om de domeinnaam om te zetten naar een IP-adres:

• De DNS-cache van de browser wordt gecontroleerd: Voordat een DNS-query wordt uitgevoerd, controleert de browser eerst zijn eigen DNS-cache om te zien of het IP-adres voor het opgevraagde domein al beschikbaar is. Moderne browsers cachen DNS-records voor een bepaalde periode om de prestaties te verbeteren door het aantal herhaalde DNS-lookups te verminderen. Als het record in de browsercache wordt gevonden, kan de browser het direct gebruiken zonder verdere query's.
• De OS-systeemcache wordt gecontroleerd: Als de browsercache het benodigde DNS-record niet bevat, wordt het verzoek doorgegeven aan de DNS-resolver van het besturingssysteem, vaak een "stub resolver" genoemd. Het besturingssysteem heeft ook een DNS-cache en controleert deze voordat er netwerkverzoeken worden verzonden.
• DNS-query: Als het DNS-record niet wordt gevonden in de browser- of OS-cache, wordt een recursieve DNS-query verzonden naar een DNS-resolver, meestal aangeboden door de internetprovider (ISP) van de gebruiker. Deze resolver fungeert als tussenpersoon en handelt het proces af van het bevragen van andere DNS-servers om het IP-adres te vinden.
  • Root Name Servers: De resolver neemt eerst contact op met een root name server, die deze doorverwijst naar de juiste top-level domain (TLD) server op basis van de domeinextensie (bijv. ".com", ".org").
  • TLD Name Servers: De TLD-server verwijst de resolver vervolgens door naar de authoritative name server voor het specifieke domein.
  • Authoritative Name Server: Deze server bevat de DNS-records voor het domein en levert het IP-adres aan de resolver.
• Het IP-adres retourneren: Zodra de DNS-resolver het IP-adres van de authoritative server heeft verkregen, stuurt deze deze informatie terug naar de browser. De browser kan vervolgens een verbinding tot stand brengen met de server via het IP-adres om de opgevraagde webpagina te laden.

Hoe beïnvloedt DNS de Time to First Byte?

Voor terugkerende bezoekers is de DNS-lookup doorgaans gecacht in de browser of het besturingssysteem, waardoor de DNS-duur vrijwel nul wordt. Voor nieuwe bezoekers moet echter de volledige recursieve DNS-lookup worden afgerond voordat de browser kan doorgaan naar de TCP-verbindingsstap. Daarom is de TTFB vaak meetbaar slechter voor nieuwe bezoekers in vergelijking met terugkerende bezoekers.

Gebruik dns-prefetch en preconnect voor domeinen van derden

Als uw pagina resources laadt van domeinen van derden (zoals analytics, lettertypen of CDN-subdomeinen), moet de browser voor elk domein apart DNS opzoeken. U kunt de browser instrueren om DNS-resolutie vroegtijdig te starten door de dns-prefetch resource hint te gebruiken:

<!-- DNS prefetch for third-party 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">

Voor kritieke origins van derden waarvan u weet dat u ook een TCP- en TLS-verbinding moet opzetten, gebruik dan in plaats daarvan preconnect, dat DNS-resolutie plus de verbindingshandshake omvat:

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

Gebruik dns-prefetch als fallback voor browsers die preconnect niet ondersteunen:

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

Plaats deze hints zo vroeg mogelijk in de <head> van uw HTML. Voeg alleen hints toe voor domeinen die uw pagina daadwerkelijk gebruikt; het toevoegen van hints voor ongebruikte domeinen verspilt browserbronnen. Zie voor meer optimalisatietechnieken gerelateerd aan resource-loading onze handleiding over 103 Early Hints.

Hoe de DNS-impact op de TTFB minimaliseren

Gebruik een snelle DNS-provider

Sommige DNS-providers zijn sneller dan andere. Het kiezen van een snelle en betrouwbare DNS-provider is een van de eenvoudigste manieren om DNS-latentie te verminderen. Premium DNS-providers zoals Cloudflare, Amazon Route 53 en Google Cloud DNS draaien servers op honderden locaties wereldwijd. Hoe dichter de DNS-server bij uw gebruiker staat, hoe sneller de lookup.

Hier is een vergelijking van populaire DNS-providers en hun typische responstijden:

Het verschil tussen een premium DNS-provider en een basis registrar DNS kan 40 tot 90 milliseconden per lookup zijn (bron: DNSPerf-benchmarks). Voor nieuwe bezoekers vertaalt dit zich direct in een snellere TTFB. Lees onze handleiding voor het configureren van Cloudflare om te leren hoe u Cloudflare instelt als uw DNS- en CDN-provider.

Optimaliseer de DNS Cache Time to Live

DNS-caching slaat DNS-queryresultaten lokaal op, waardoor herhaalde lookups worden verminderd. Door "optimale" Time-To-Live (TTL)-waarden in te stellen voor DNS-records, kunt u bepalen hoe lang deze records worden gecacht.

Lagere TTL-waarden betekenen dat records sneller verlopen, wat leidt tot frequentere DNS-lookups. Hogere TTL-waarden betekenen dat records langer worden gecacht, wat DNS-lookups vermindert maar DNS-wijzigingen langzamer laat doorwerken. De juiste TTL hangt af van hoe vaak u uw DNS-records wijzigt en hoeveel waarde u hecht aan DNS-lookupsnelheid versus flexibiliteit.

Wat zijn optimale DNS TTL-instellingen?

Wanneer u een DNS-migratie of serverwijziging plant, verlaag uw TTL dan tijdelijk naar 5 minuten (300 seconden) minstens 24 uur voordat u de wijziging doorvoert. Dit zorgt ervoor dat gebruikers na de wijziging het nieuwe IP-adres snel oppikken. Zodra de migratie is voltooid en geverifieerd, verhoog de TTL dan weer naar een hogere waarde om de DNS-lookupfrequentie te verminderen.

TIP: als u CNAME-records gebruikt, overweeg dan CNAME flattening te implementeren. CNAME flattening is een techniek waarmee u een CNAME-record kunt gebruiken op het root (apex) domeinniveau, waarbij het effectief wordt omgezet naar een IP-adres zonder DNS-standaarden te schenden. Dit elimineert een extra DNS-lookup die anders nodig zou zijn om de CNAME naar het doel te resolven en vervolgens het doel naar het IP-adres.

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

Traditionele DNS-query's worden in platte tekst verzonden via UDP, wat betekent dat ze kunnen worden onderschept, gewijzigd of geblokkeerd door tussenpersonen (zoals ISP's of netwerkbeheerders). DNS over HTTPS (DoH) en DNS over TLS (DoT) versleutelen DNS-query's, wat zowel de privacy als de beveiliging verbetert.

Hoewel DoH en DoT voornamelijk beveiligings- en privacykwesties aanpakken, kunnen ze ook de DNS-resolutieprestaties beïnvloeden:

• Latentie-impact: de versleutelingsoverhead voegt een kleine hoeveelheid latentie toe aan de initiële DNS-verbinding (TLS-handshake). Omdat DoH/DoT-verbindingen echter persistent zijn en hergebruikt worden, zijn opeenvolgende query's op dezelfde verbinding vaak sneller dan traditionele DNS.
• ISP-interferentie: sommige ISP's injecteren hun eigen DNS-antwoorden of vertragen DNS-query's voor niet-klanten. DoH omzeilt deze interferentie volledig, wat de DNS-resolutietijd voor getroffen gebruikers daadwerkelijk kan verbeteren.
• Browserondersteuning: moderne browsers (Chrome, Firefox, Edge, Safari) ondersteunen allemaal DoH. In de meeste gevallen gebruikt de standaard DNS-provider van de browser al DoH wanneer beschikbaar.

Als website-eigenaar kunt u niet bepalen of uw bezoekers DoH of DoT gebruiken (dat is een browser- en OS-instelling). U kunt er echter voor zorgen dat uw authoritative DNS-provider DNSSEC ondersteunt, wat een aanvullende verificatielaag biedt voor DNS-antwoorden, ongeacht transportversleuteling.

DNS-duur meten met JavaScript

U kunt het DNS-duuronderdeel van de TTFB direct in de browser meten met de Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Een DNS-duur van 0ms in uw RUM-gegevens duidt doorgaans op een DNS-lookup die is geserveerd vanuit de browser- of OS-cache (een scenario met terugkerende bezoekers). Waarden boven 50ms suggereren dat de gebruiker een volledige recursieve DNS-lookup moest uitvoeren, wat gebruikelijk is voor nieuwe bezoekers.

Hoe TTFB-problemen door trage DNS-lookups meten

Om de impact die echte gebruikers ervaren door DNS-latentie te achterhalen, heeft u een RUM-tool zoals CoreDash nodig. Real User Monitoring stelt u in staat de Core Web Vitals in meer detail te volgen en zonder de 28 dagen vertraging van Google.

Klik in CoreDash op "Time to First Byte breakdown" om het DNS-onderdeel van de Time to First Byte te visualiseren.

Verder lezen: optimalisatiehandleidingen

Gerelateerde handleidingen:

• 103 Early Hints: verstuur resource hints voordat het volledige antwoord klaar is, zodat de browser DNS-resolutie en verbindingen voor kritieke resources nog eerder kan starten.
• Cloudflare configureren voor prestaties: gebruik Cloudflare als zowel uw DNS-provider als CDN, waarbij snelle DNS-resolutie wordt gecombineerd met edge caching en HTTP/3-ondersteuning.

TTFB-onderdelen: complete handleidingen

De DNS-duur is een van de vijf onderdelen van de TTFB. Verken de andere onderdelen om het volledige beeld te begrijpen:

• TTFB-problemen identificeren en oplossen: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Wachtduur: doorverwijzingen, browser-queuing en HSTS-optimalisatie.
• Cacheduur: service worker-prestaties, browser-cache-lookups en bfcache.
• Verbindingsduur: TCP-handshake, TLS-optimalisatie, HTTP/3 en preconnect.
• Verzoekduur: serververwerkingstijd, databasequery's en backend-optimalisatie.