De subparte Waiting Duration van de Time to First Byte verkorten

De Waiting Duration van de Time to First Byte verkorten

Dit artikel maakt deel uit van onze gids over de Time to First Byte (TTFB). De waiting duration is het eerste subonderdeel van de TTFB en bestaat voornamelijk uit redirect-tijd en browser queuing (wachtrijvorming in de browser). Een hoge waiting duration wordt bijna altijd veroorzaakt door onnodige redirects die extra round trips toevoegen voordat de server kan beginnen met het verwerken van de eigenlijke aanvraag.

De Time to First Byte (TTFB) kan worden onderverdeeld in de volgende subonderdelen:

• Waiting + Redirect (of waiting duration)
• Worker + Cache (of cache duration)
• DNS (of DNS duration)
• Connection (of connection duration)
• Request (of request duration)

Wilt u de Time to First Byte optimaliseren? Dit artikel behandelt het waiting duration-gedeelte van de Time to First Byte. Als u de Time to First Byte wilt begrijpen of herstellen en u weet niet wat waiting duration betekent, lees dan eerst wat is de Time to First Byte en Time to First Byte-problemen identificeren en herstellen voordat u aan dit artikel begint.

Redirects kunnen een grote impact hebben op de Time to First Byte (TTFB), omdat elke redirect wordt opgeteld bij de tijd die een browser nodig heeft om de eerste byte aan gegevens van een server te ontvangen. Hier leest u hoe redirects de TTFB beïnvloeden:

Hoe verhogen redirects de Time to First Byte?

Redirects worden doorgaans opgenomen in de volledige TTFB-meting. Dit betekent dat de tijd die nodig is voor alle redirects wordt meegerekend in de totale TTFB-score, waardoor deze mogelijk hoger uitvalt dan verwacht.

Wanneer een pagina wordt geredirect, zijn dit de gebruikelijke stappen:

• De browser stuurt een eerste verzoek naar de oorspronkelijke URL.
• De server verwerkt dit verzoek en antwoordt met een redirect-statuscode (bijv. 301 of 302).
• De browser stuurt vervolgens een nieuw verzoek naar de geredirecte URL.
• De server verwerkt dit tweede verzoek en begint met het verzenden van de eigenlijke inhoud.

Typen redirects en hun impact

Niet alle redirects zijn gelijk. Het begrijpen van de verschillende typen helpt u bij het prioriteren van welke redirects u het eerst moet elimineren:

Een enkele redirect voegt doorgaans 50 tot 300 milliseconden toe aan de TTFB, afhankelijk van de netwerkomstandigheden en de responstijd van de server. Wanneer twee of drie redirects aan elkaar geschakeld zijn (chains), tellen deze tijden bij elkaar op en kunnen ze de TTFB ruim boven de "goede" drempelwaarde van 800 ms duwen.

Verhoogde serververwerkingstijd

Deze extra verwerking verhoogt de totale TTFB, aangezien elke stap tijd kost voor de server om het verzoek af te handelen en te antwoorden.

Redirect Chains

In sommige gevallen kunnen er meerdere redirects plaatsvinden voordat de eindbestemming wordt bereikt. Dit creëert een "redirect chain" die de TTFB verhoogt. Elke redirect in de keten voegt zijn eigen verwerkingstijd toe, wat bijdraagt aan de vertraging voordat de eerste byte van de eigenlijke inhoud 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/nl/

In dit voorbeeld vinden er drie redirects plaats voordat de browser enige inhoud ontvangt. De eerste redirect (HTTP naar HTTPS) kan worden geëlimineerd met HSTS. De tweede en derde redirects kunnen worden geëlimineerd door interne links bij te werken zodat ze direct naar de uiteindelijke URL wijzen.

Netwerklatentie (Network Latency)

Redirects brengen vaak extra netwerk round trips met zich mee tussen de client en de server. Dit introduceert extra netwerklatentie, vooral als de redirects betrekking hebben op verschillende domeinen of servers. De fysieke afstand tussen de client en de server voor elke redirect kan de TTFB verder beïnvloeden.

JavaScript redirects vs Server-side redirects: Alleen server-side redirects (die werken met een 30x redirect header) worden opgeteld bij de Time to First Byte. JavaScript redirects worden niet opgeteld bij de Time to First Byte omdat er al een volledig antwoord (200) door de server is verzonden.

Men zou kunnen denken dat JavaScript redirects de voorkeur verdienen omdat ze niet bijdragen aan de Time to First Byte. Helaas zijn JavaScript redirects veel langzamer voor echte gebruikers en veroorzaken ze een slechte user experience.

Impact op user experience (en SEO)

Hoewel redirects soms noodzakelijk zijn, kan hun impact op de TTFB bredere gevolgen hebben:

• User Experience: Een tragere TTFB als gevolg van redirects kan de initiële randerings-fase van de pagina vertragen, wat gebruikers kan frustreren.
• SEO: Hoewel TTFB geen directe rankingfactor is, beïnvloedt het andere metrieken zoals Largest Contentful Paint (LCP), wat een Core Web Vital is die door zoekmachines wordt meegewogen.
• Crawl budget: Crawlers van zoekmachines volgen redirects, wat betekent dat elke redirect extra crawlbudget verbruikt. Voor grote websites kan dit de ontdekking van nieuwe of bijgewerkte inhoud vertragen.

Hoe TTFB-problemen veroorzaakt door redirects te meten

Om de impact te vinden die echte gebruikers ervaren als gevolg van redirects, moet u een RUM-tool zoals CoreDash gebruiken. Met Real User Monitoring kunt u de Core Web Vitals zeer gedetailleerd volgen.

In CoreDash klikt u eenvoudig op "redirect count" om uw gegevens gesegmenteerd op redirect-aantal te visualiseren. Klik vervolgens bijvoorbeeld op het segment "1 redirect" om de RUM data te filteren op "1 redirect" en bekijk alle betrokken URL's.

Hoe u uw site kunt auditen op redirects

Een systematische redirect-audit omvat drie stappen:

Stap 1: Crawl uw site

Gebruik een crawling-tool (zoals MarketingTracer, Screaming Frog of Sitebulb) om uw volledige website te crawlen. De crawler rapporteert alle interne URL's die antwoorden met een 3xx-statuscode. Exporteer de lijst en sorteer op het aantal inkomende interne links die naar elke geredirecte URL wijzen.

Stap 2: Identificeer Redirect Chains

Filter de crawlresultaten op URL's die redirecten naar een andere URL die óók redirect. Deze ketens moeten als eerste worden hersteld omdat ze de TTFB-straf vermenigvuldigen.

Stap 3: Herstellen en verifiëren

Werk uw interne links bij zodat ze direct naar de uiteindelijke bestemmings-URL wijzen. Crawl na het bijwerken van de links opnieuw om te verifiëren dat de redirects niet langer worden getriggerd door interne navigatie. Gebruik het volgende JavaScript-fragment om redirects vanuit de browser te detecteren:

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

Hoe de impact van redirects te minimaliseren

Volg als algemene regel deze 3 eenvoudige stappen om redirect-problemen te voorkomen:

• Minimaliseer het gebruik van redirects waar mogelijk.
• Vermijd redirect chains door links direct naar de uiteindelijke bestemmings-URL te laten wijzen.
• Gebruik server-side redirects in plaats van client-side redirects wanneer mogelijk, omdat deze over het algemeen sneller zijn.

Same-origin redirects. Same-origin redirects zijn afkomstig van links op uw eigen website. U zou de volledige controle over deze links moeten hebben en u zou prioriteit moeten geven aan het herstellen van deze links wanneer u aan de Time to First Byte werkt. De gebruikelijke methode om deze interne redirects te vinden is door gebruik te maken van een van de beschikbare tools die uw volledige website controleren op redirects.

Cross-origin redirects. Cross-origin redirects zijn afkomstig van links op andere websites. U heeft hier weinig controle over. Voor links met een grote impact die veel verkeer genereren, kunt u overwegen contact op te nemen met de webmaster van die site om de gelinkte URL bij te werken.

Redirect chains. Meerdere redirects of redirect chains treden op wanneer een enkele redirect niet direct naar de uiteindelijke locatie van de bron leidt. Dit soort redirects belasten de Time to First Byte zwaarder en moeten ten koste van alles worden vermeden. Gebruik ook hier een tool om dit soort redirects te vinden en te herstellen.

HTTP naar HTTPS redirects en HSTS

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

Om HSTS in te schakelen, voegt u de volgende header toe aan uw serverrespons:

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

Dit is wat elke richtlijn betekent:

• max-age=31536000: de browser zal gedurende één jaar (31.536.000 seconden) onthouden om HTTPS te gebruiken voor dit domein.
• includeSubDomains: past de HTTPS-vereiste ook toe op alle subdomeinen.
• preload: staat toe dat uw domein wordt opgenomen in de ingebouwde HSTS-preloadlijst van de browser, wat betekent dat zelfs het allereerste bezoek HTTPS zal gebruiken zonder redirect.

Om uw domein aan te melden voor de HSTS-preloadlijst, gaat u naar hstspreload.org. Zodra uw domein op de preloadlijst staat, zullen browsers nooit meer een HTTP-verzoek naar uw domein sturen, waardoor de HTTP naar HTTPS redirect voor alle bezoekers volledig wordt geëlimineerd.

In Apache kunt u HSTS toevoegen 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;

In het algemeen raden we aan om:

1. Regelmatig uw interne links te controleren en bij te werken. Telkens wanneer u de locatie van een pagina wijzigt, moet u uw interne links naar die pagina bijwerken om ervoor te zorgen dat er geen verwijzingen naar de eerdere paginalocatie overblijven.
2. Redirects op serverniveau af te handelen. De voorkeursmethode voor redirects is een 301-redirect. Een 301-redirect is een permanente redirect, terwijl een 302-redirect een tijdelijke redirect is. Tijdelijke redirects worden bijvoorbeeld mogelijk niet bijgewerkt in zoekmachines.
3. Gebruik relatieve URL's: gebruik bij het linken naar pagina's op uw eigen website relatieve URL's in plaats van absolute URL's. Dit helpt onnodige redirects te voorkomen.
4. Gebruik canonical URL's: als u meerdere pagina's heeft met vergelijkbare inhoud, gebruik dan een canonical URL om de voorkeursversie van de pagina aan te geven. Dit helpt dubbele inhoud en onnodige redirects te voorkomen.

Verder lezen: Optimalisatiegidsen

Gerelateerde gidsen:

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

TTFB-subonderdelen: Volledige gidsen

De waiting duration is een van de vijf subonderdelen van de TTFB. Verken de andere subonderdelen om het volledige plaatje te begrijpen:

• TTFB-problemen herstellen en identificeren: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Cache Duration: performance van service workers, zoekacties in de browsercache en bfcache.
• DNS Duration: selectie van DNS-providers, TTL-configuratie en dns-prefetch.
• Connection Duration: TCP handshake, TLS-optimalisatie, HTTP/3 en preconnect.
• Request Duration: serververwerkingstijd, databasequery's en backend-optimalisatie.