Minimera DNS-delen av Time to First Byte

Minimera DNS-delen av Time to First Byte

Den här artikeln är en del av vår guide om Time to First Byte (TTFB). DNS-delen är den tredje underdelen av TTFB och representerar den tid webbläsaren spenderar på att lösa upp ditt domännamn till en IP-adress. För förstagångsbesökare som inte har en cachad DNS-post kan DNS-uppslagningen lägga till 20 till 200 millisekunder till TTFB beroende på DNS-leverantören, användarens geografiska plats och TTL-inställningarna för dina DNS-poster.

Time to First Byte (TTFB) kan brytas ner i följande underdelar:

• Väntan + Omdirigering (eller väntetid)
• Worker + Cache (eller cachetid)
• DNS (eller DNS-tid)
• Anslutning (eller anslutningstid)
• Begäran (eller begäranstid)

Vill du optimera Time to First Byte? Den här artikeln ger en djupgående analys av DNS-delen av Time to First Byte. Om du vill förstå eller åtgärda Time to First Byte och inte vet vad DNS-delen innebär, läs vad är Time to First Byte och identifiera och åtgärda Time to First Byte-problem innan du börjar med den här artikeln.

DNS snabbfix: om du upplever DNS-latens i Time to First Byte, byt till en premium DNS-leverantör och uppdatera dina TTL-inställningar!

DNS-delen av Time to First Byte består av den tid då webbläsaren slår upp internetadressen (IP-adressen) för din webbplats. Vi behöver DNS-uppslagningar eftersom vi människor tycker att det är lättare att komma ihåg domännamn som "www.example.com" medan datorer behöver numeriska IP-adresser för att kommunicera med varandra.

Hur fungerar DNS?

DNS-förfrågningar ingår i TTFB-mätningen. Det innebär att den tid det tar för DNS-förfrågan att slutföras räknas in i det totala TTFB-resultatet.

När en sida begärs tar din webbläsare dessa steg för att omvandla domännamnet till en IP-adress:

• Webbläsarens DNS-cache kontrolleras: Innan webbläsaren gör en DNS-förfrågan kontrollerar den först sin egen DNS-cache för att se om den redan har IP-adressen för den begärda domänen. Moderna webbläsare cachar DNS-poster under en viss period för att förbättra prestandan genom att minska behovet av upprepade DNS-uppslagningar. Om posten hittas i webbläsarens cache kan webbläsaren använda den direkt utan ytterligare förfrågningar.
• Operativsystemets cache kontrolleras: Om webbläsarens cache inte innehåller den nödvändiga DNS-posten skickas förfrågan vidare till operativsystemets DNS-resolver, ofta kallad en "stub resolver". Operativsystemet har också en DNS-cache och kontrollerar den innan det skickar några nätverksförfrågningar.
• DNS-förfrågan: Om DNS-posten inte hittas i vare sig webbläsarens eller operativsystemets cache skickas en rekursiv DNS-förfrågan till en DNS-resolver, vanligtvis tillhandahållen av användarens internetleverantör (ISP). Denna resolver fungerar som en mellanhand och hanterar processen att fråga andra DNS-servrar för att hitta IP-adressen.
  • Rotnamnservrar: Resolvern kontaktar först en rotnamnserver som dirigerar den till lämplig toppdomänserver (TLD) baserat på domänändelsen (t.ex. ".com", ".org").
  • TLD-namnservrar: TLD-servern dirigerar sedan resolvern till den auktoritativa namnservern för den specifika domänen.
  • Auktoritativ namnserver: Denna server innehåller DNS-posterna för domänen och förser resolvern med IP-adressen.
• Returnera IP-adressen: När DNS-resolvern har fått IP-adressen från den auktoritativa servern returnerar den denna information till webbläsaren. Webbläsaren kan sedan upprätta en anslutning till servern med hjälp av IP-adressen för att ladda den begärda webbsidan.

Hur påverkar DNS Time to First Byte?

För återkommande besökare är DNS-uppslagningen vanligtvis cachad i webbläsaren eller operativsystemet, vilket minskar DNS-tiden till nära noll. För förstagångsbesökare måste dock den fullständiga rekursiva DNS-uppslagningen slutföras innan webbläsaren kan gå vidare till TCP-anslutningssteget. Det är därför TTFB ofta är mätbart sämre för nya besökare jämfört med återkommande.

Använd dns-prefetch och preconnect för tredjepartsdomäner

Om din sida laddar resurser från tredjepartsdomäner (som analys, typsnitt eller CDN-subdomäner) måste webbläsaren lösa upp DNS för varje domän separat. Du kan instruera webbläsaren att påbörja DNS-upplösningen tidigt genom att använda resurstipset dns-prefetch:

<!-- 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">

För kritiska tredjepartskällor där du vet att du också behöver upprätta en TCP- och TLS-anslutning, använd preconnect istället, som inkluderar DNS-upplösning plus anslutningshandskakningen:

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

Använd dns-prefetch som en fallback för webbläsare som inte stöder preconnect:

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

Placera dessa tips i <head> av din HTML så tidigt som möjligt. Lägg bara till tips för domäner som din sida faktiskt använder; att lägga till tips för oanvända domäner slösar webbläsarresurser. För fler optimeringstekniker relaterade till resursladdning, se vår guide om 103 Early Hints.

Hur man minimerar DNS-påverkan på TTFB

Använd en snabb DNS-leverantör

Vissa DNS-leverantörer är snabbare än andra. Att välja en snabb och pålitlig DNS-leverantör är ett av de enklaste sätten att minska DNS-latensen. Premium DNS-leverantörer som Cloudflare, Amazon Route 53 och Google Cloud DNS har omfattande global infrastruktur. Dessa infrastrukturer minskar det fysiska avståndet mellan användare och DNS-servrar, vilket eliminerar en viktig del av latensen i DNS-förfrågningar.

Här är en jämförelse av populära DNS-leverantörer och deras typiska svarstider:

Skillnaden mellan en premium DNS-leverantör och en vanlig registrar-DNS kan vara 40 till 90 millisekunder per uppslagning. För förstagångsbesökare översätts detta direkt till en snabbare TTFB. För att lära dig hur du konfigurerar Cloudflare som din DNS- och CDN-leverantör, läs vår guide till att konfigurera Cloudflare.

Optimera DNS-cachens Time to Live

DNS-caching lagrar DNS-frågeresultat lokalt, vilket minskar behovet av upprepade uppslagningar. Genom att ställa in "optimala" Time-To-Live (TTL)-värden för DNS-poster kan du styra hur länge dessa poster cachas.

Lägre TTL-värden innebär att poster löper ut snabbare, vilket orsakar fler DNS-uppslagningar. Högre TTL-värden innebär att poster cachas längre, vilket minskar DNS-uppslagningar men gör att DNS-ändringar propagerar långsammare. Rätt TTL beror på hur ofta du ändrar dina DNS-poster och hur mycket du värderar DNS-uppslagningshastighet jämfört med flexibilitet.

Vad är optimala DNS TTL-inställningar?

Vid planering av en DNS-migrering eller serverbyte, sänk tillfälligt din TTL till 5 minuter (300 sekunder) minst 24 timmar innan ändringen genomförs. Detta säkerställer att användare efter ändringen snabbt får den nya IP-adressen. När migreringen är slutförd och verifierad, höj TTL-värdet tillbaka till ett högre värde för att minska frekvensen av DNS-uppslagningar.

TIPS: om du använder CNAME-poster, överväg att implementera CNAME-utjämning. CNAME-utjämning är en teknik som låter dig använda en CNAME-post på rotdomännivå (apex), som effektivt löser upp den till en IP-adress utan att bryta mot DNS-standarder. Detta eliminerar en extra DNS-uppslagning som annars skulle behövas för att lösa upp CNAME till dess mål, och sedan målet till dess IP-adress.

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

Traditionella DNS-förfrågningar skickas i klartext över UDP, vilket innebär att de kan avlyssnas, ändras eller blockeras av mellanhänder (som internetleverantörer eller nätverksoperatörer). DNS over HTTPS (DoH) och DNS over TLS (DoT) krypterar DNS-förfrågningar, vilket förbättrar både integritet och säkerhet.

Även om DoH och DoT främst adresserar säkerhets- och integritetsfrågor kan de också påverka DNS-upplösningens prestanda:

• Latenspåverkan: krypteringsoverheaden lägger till en liten mängd latens till den initiala DNS-anslutningen (TLS-handskakning). Eftersom DoH/DoT-anslutningar dock är beständiga och återanvänds är efterföljande förfrågningar på samma anslutning ofta snabbare än traditionell DNS.
• ISP-störningar: vissa internetleverantörer injicerar sina egna DNS-svar eller saktar ner DNS-förfrågningar för icke-kunder. DoH kringgår denna störning helt, vilket faktiskt kan förbättra DNS-upplösningstiden för berörda användare.
• Webbläsarstöd: moderna webbläsare (Chrome, Firefox, Edge, Safari) stöder alla DoH. I de flesta fall använder webbläsarens standard-DNS-leverantör redan DoH när det är tillgängligt.

Som webbplatsägare kan du inte kontrollera om dina besökare använder DoH eller DoT (det är en inställning på webbläsar- och operativsystemnivå). Du kan dock se till att din auktoritativa DNS-leverantör stöder DNSSEC, som ger ett kompletterande verifieringslager för DNS-svar oavsett transportkryptering.

Mäta DNS-tid med JavaScript

Du kan mäta DNS-delen av TTFB direkt i webbläsaren med hjälp av 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
});

Ett DNS-tidsvärde på 0ms i dina RUM-data indikerar vanligtvis att DNS-uppslagningen serverades från webbläsarens eller operativsystemets cache (ett scenario med återkommande besökare). Värden över 50ms tyder på att användaren behövde utföra en fullständig rekursiv DNS-uppslagning, vilket är vanligt för förstagångsbesökare.

Hur man mäter TTFB-problem orsakade av långsamma DNS-uppslagningar

För att ta reda på vilken påverkan riktiga användare upplever på grund av DNS-latens behöver du använda ett RUM-verktyg som CoreDash. Real User Monitoring låter dig spåra Core Web Vitals i större detalj och utan Googles 28-dagars fördröjning.

I CoreDash, klicka på "Time to First Byte breakdown" för att visualisera DNS-delen av Time to First Byte.

Vidare läsning: Optimeringsguider

För relaterade optimeringstekniker som kompletterar DNS-optimering, utforska dessa guider:

• 103 Early Hints: skicka resurstips innan det fullständiga svaret är klart, så att webbläsaren kan påbörja DNS-upplösning och anslutningar för kritiska resurser ännu tidigare.
• Konfigurera Cloudflare för prestanda: använd Cloudflare som både din DNS-leverantör och CDN, och kombinera snabb DNS-upplösning med edge-caching och HTTP/3-stöd.

TTFB-underdelar: Fördjupningsartiklar

DNS-delen är en av fem underdelar av TTFB. Utforska de andra underdelarna för att förstå helheten:

• Identifiera och åtgärda TTFB-problem: den diagnostiska startpunkten för all TTFB-optimering.
• Väntetid: omdirigeringar, webbläsarköer och HSTS-optimering.
• Cachetid: service worker-prestanda, webbläsarcache-uppslagningar och bfcache.
• Anslutningstid: TCP-handskakning, TLS-optimering, HTTP/3 och preconnect.