Verkort het wachttijd-gedeelte van de Time to First Byte

Verlaag de wachtduur van de Time to First Byte

Dit artikel is onderdeel van onze Time to First Byte (TTFB) gids. De wachtduur is het eerste onderdeel van de TTFB. Deze bestaat voornamelijk uit redirect-tijd en de wachtrij van de browser. Een hoge wachtduur komt vrijwel altijd door onnodige redirects. Deze voegen extra round trips toe voordat de server het daadwerkelijke verzoek kan verwerken.

De Time to First Byte (TTFB) bestaat uit de volgende onderdelen:

• Waiting + Redirect (of wachtduur)
• Worker + Cache (of cacheduur)
• DNS (of DNS-duur)
• Connection (of verbindingsduur)
• Request (of request-duur)

Wil je de Time to First Byte optimaliseren? Dit artikel behandelt het wachtduur-gedeelte van de Time to First Byte. Wil je de Time to First Byte begrijpen of oplossen, maar weet je niet wat de wachtduur betekent? Lees dan eerst wat de Time to First Byte is en hoe je Time to First Byte-problemen vindt en oplost voordat je aan dit artikel begint.

Redirects hebben een grote impact op de Time to First Byte (TTFB). Elke redirect wordt opgeteld bij de tijd die een browser nodig heeft om de eerste byte data van een server te ontvangen. Zo beïnvloeden redirects de TTFB:

Hoe verhogen redirects de Time to First Byte?

Redirects zitten standaard in de volledige TTFB-meting (zie het blauwe vlak). De tijd van alle redirects telt mee in de totale TTFB-score. Hierdoor lijkt deze score mogelijk hoger dan verwacht.

Bij een redirect doorloopt de pagina meestal deze stappen:

• De browser stuurt een eerste verzoek naar de originele URL.
• De server verwerkt dit verzoek en reageert met een redirect-statuscode (bijv. 301 of 302).
• De browser stuurt daarna een nieuw verzoek naar de nieuwe URL.
• De server verwerkt dit tweede verzoek en begint met het sturen van de daadwerkelijke content.

Soorten redirects en hun impact

Niet alle redirects zijn hetzelfde. Kennis van de verschillende soorten helpt je te bepalen welke redirects je als eerste moet verwijderen:

Een enkele redirect voegt meestal 50 tot 300 milliseconden toe aan de TTFB. Dit hangt af van de netwerkcondities en de reactietijd van de server. Wanneer twee of drie redirects elkaar opvolgen, tellen deze tijden bij elkaar op. Dit kan de TTFB ver boven de 'goede' grens van 800 ms duwen.

Langere verwerkingstijd van de server

Deze extra verwerkingstijd verhoogt de totale TTFB. Elke stap kost de server tijd om het verzoek te verwerken en te reageren.

Redirect-chains

Soms vinden er meerdere redirects plaats voordat de eindbestemming is bereikt. Dit vormt een 'redirect-chain' die de TTFB verhoogt. Elke redirect in de reeks voegt zijn eigen verwerkingstijd toe. Dit vergroot de vertraging voordat de eerste byte van de daadwerkelijke content wordt ontvangen.

Een veelvoorkomend voorbeeld van een redirect-chain:

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

In dit voorbeeld vinden er drie redirects plaats voordat de browser content ontvangt. De eerste redirect (HTTP naar HTTPS) elimineer je met HSTS. De tweede en derde redirect elimineer je door interne links direct naar de uiteindelijke URL te laten wijzen.

Netwerklatency

Redirects vereisen vaak extra round trips over het netwerk tussen client en server. Dit zorgt voor extra netwerklatency, zeker als de redirects over verschillende domeinen of servers gaan. De fysieke afstand tussen de client en server kan de TTFB bij elke redirect verder negatief beïnvloeden.

JavaScript-redirects vs. server-side redirects: Alleen server-side redirects (die werken met een 30x redirect-header) tellen mee voor de Time to First Byte. JavaScript-redirects tellen niet mee voor de Time to First Byte, omdat de server dan al een volledig antwoord (200) heeft gestuurd.

Je zou kunnen denken dat JavaScript-redirects beter zijn, omdat ze niet meetellen voor de Time to First Byte. Helaas zijn JavaScript-redirects veel trager voor echte gebruikers en zorgen ze voor een slechte UX.

Impact op UX (en SEO)

Redirects zijn soms nodig, maar hun impact op de TTFB kan bredere gevolgen hebben:

• UX: Een tragere TTFB door redirects vertraagt de eerste weergave van de pagina. Dit frustreert gebruikers.
• SEO: Hoewel TTFB geen directe rankingfactor is, beïnvloedt het andere metrics zoals Largest Contentful Paint (LCP). Dit is een Core Web Vital waar zoekmachines naar kijken.
• Crawl budget: Crawlers van zoekmachines volgen redirects. Elke redirect kost extra crawl budget. Voor grote websites vertraagt dit de ontdekking van nieuwe of bijgewerkte content.

Hoe meet je TTFB-problemen door redirects?

Gebruik een RUM-tool zoals CoreDash om de impact van redirects op echte gebruikers te zien. Met Real User Monitoring track je de Core Web Vitals in groot detail.

Klik in CoreDash op 'redirect count' om je data te segmenteren op het aantal redirects. Klik daarna bijvoorbeeld op het segment '1 redirect' om de RUM-data hierop te filteren en alle getroffen URLs te bekijken.

Een redirect-audit uitvoeren voor je site

Een systematische redirect-audit bestaat uit drie stappen:

Stap 1: Crawl je site

Gebruik een crawling-tool (zoals MarketingTracer, Screaming Frog of Sitebulb) om je hele website te crawlen. De crawler toont alle interne URLs die reageren met een 3xx-statuscode. Exporteer de lijst en sorteer deze op het aantal inkomende interne links dat naar elke geredirecte URL wijst.

Stap 2: Vind redirect-chains

Filter de crawl-resultaten op URLs die redirecten naar een URL die op zijn beurt ook weer redirect. Los deze chains als eerste op, want ze vermenigvuldigen de TTFB-straf.

Stap 3: Los op en verifieer

Update je interne links zodat ze direct naar de uiteindelijke bestemmings-URL wijzen. Crawl na de update je site opnieuw. Zo verifieer je dat interne navigatie geen redirects meer veroorzaakt. Gebruik de volgende JavaScript-snippet om redirects vanuit de browser te detecteren:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Hoe beperk je de impact van redirects?

Volg deze 3 simpele stappen als vuistregel om redirect-problemen te voorkomen:

• Minimaliseer het gebruik van redirects waar mogelijk.
• Voorkom redirect-chains. Laat links direct naar de uiteindelijke bestemmings-URL wijzen.
• Gebruik waar mogelijk server-side redirects in plaats van client-side redirects. Deze zijn over het algemeen sneller.

Same-origin redirects. Same-origin redirects komen van links op je eigen website. Je hebt volledige controle over deze links. Geef het oplossen van deze links prioriteit wanneer je werkt aan de Time to First Byte. Je vindt deze interne redirects door een van de beschikbare tools te gebruiken om je hele website op redirects te controleren.

Cross-origin redirects. Cross-origin redirects komen van links op andere websites. Hier heb je weinig controle over. Neem bij high-impact links die veel verkeer genereren contact op met de webmaster van die site om de link aan te passen.

Redirect-chains. Meerdere redirects of redirect-chains ontstaan wanneer een enkele redirect niet naar de uiteindelijke locatie van de resource verwijst. Dit soort redirects leggen meer druk op de Time to First Byte en moet je absoluut vermijden. Gebruik nogmaals een tool om deze redirects op te sporen en te fixen.

HTTP naar HTTPS redirects en HSTS

HTTP naar HTTPS redirects zijn een van de meest voorkomende soorten redirects. Elke bezoeker die je domein intypt zonder "https://" of een oude HTTP-link volgt, krijgt een 301-redirect. De Strict-Transport-Security header (HSTS) elimineert deze redirect voor terugkerende bezoekers door de browser te forceren altijd HTTPS te gebruiken.

Voeg de volgende header toe aan je server-response om HSTS in te schakelen:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Dit is wat elke directive betekent:

• max-age=31536000: de browser onthoudt dat hij HTTPS moet gebruiken voor dit domein gedurende één jaar (31.536.000 seconden).
• includeSubDomains: past de HTTPS-verplichting ook toe op alle subdomeinen.
• preload: staat toe dat je domein wordt opgenomen in de ingebouwde HSTS preload-lijst van de browser. Hierdoor gebruikt zelfs het allereerste bezoek HTTPS zonder redirect.

Bezoek hstspreload.org om je domein in te sturen voor de HSTS preload-lijst. Zodra je domein op deze lijst staat, maken browsers nooit meer een HTTP-verzoek naar je domein. Dit elimineert de HTTP naar HTTPS redirect volledig voor alle bezoekers.

In Apache voeg je HSTS toe met:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

In Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Over het algemeen raden we aan om:

1. Je interne links regelmatig te controleren en te updaten. Wanneer je de locatie van een pagina wijzigt, update dan je interne links naar die pagina. Zo zorg je dat er geen verwijzingen naar de oude locatie achterblijven.
2. Redirects op serverniveau af te handelen. De voorkeursmethode is een 301-redirect. Een 301 is een permanente redirect, terwijl een 302 een tijdelijke redirect is. Tijdelijke redirects worden mogelijk niet geüpdatet in zoekmachines.
3. Relatieve URLs te gebruiken: gebruik relatieve URLs in plaats van absolute URLs wanneer je linkt naar pagina's op je eigen website. Dit helpt onnodige redirects voorkomen.
4. Canonieke URLs te gebruiken: heb je meerdere pagina's met vergelijkbare content? Gebruik dan een canonieke URL om de voorkeursversie aan te geven. Dit helpt duplicate content en onnodige redirects voorkomen.

Verder lezen: optimalisatiegidsen

Gerelateerde gidsen:

• 103 Early Hints: verlaag de waargenomen TTFB door resource-hints te sturen terwijl de server het volledige antwoord verwerkt.
• Cloudflare configureren voor performance: optimaliseer je CDN-configuratie om redirect-chains te verminderen en de wereldwijde TTFB te verbeteren.

TTFB-onderdelen: volledige gidsen

De wachtduur is een van de vijf onderdelen van de TTFB. Verken de andere onderdelen om het volledige plaatje te begrijpen:

• TTFB-problemen vinden en oplossen: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Cacheduur: service worker-performance, browser cache lookups en bfcache.
• DNS-duur: DNS-provider selectie, TTL-configuratie en dns-prefetch.
• Verbindingsduur: TCP-handshake, TLS-optimalisatie, HTTP/3 en preconnect.
• Request-duur: serververwerkingstijd, database queries en backend-optimalisatie.