Verminder de wachttijd sub-onderdeel van de Time to First Byte
De wachttijd bestaat uit redirects en andere browserprocessen. Begrijp het sub-onderdeel van de TTFB om de totale time to first byte te verminderen
Verminder de wachttijd van de Time to First Byte
De Time to First Byte (TTFB) kan worden opgesplitst in de volgende subonderdelen:
- Waiting + Redirect (of wachttijd)
- Worker + Cache (of cacheduur)
- DNS (of DNS-duur)
- Connectie (of connectieduur)
- Request (of requestduur)
Wil je de Time to First Byte optimaliseren? Dit artikel biedt een diepgaande analyse van het wachttijdgedeelte van de Time to First Byte. Als je de time to first byte wilt begrijpen of oplossen en niet weet wat de wachttijd betekent, lees dan alsjeblieft [url=/nl/core-web-vitals/time-to-first-byte]wat is de time to first byte[/url] en [url=/nl/core-web-vitals/time-to-first-byte/fix-and-identify]time to first byte problemen vinden en oplossen[/url] voordat je 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 data van een server te ontvangen. Hier is hoe redirects de TTFB beïnvloeden:
Table of Contents!
Hoe verhogen redirects de Time to first byte?
Redirects worden meestal opgenomen in de volledige TTFB-meting (zie blauwe kader). Dit betekent dat de tijd die nodig is voor alle redirects wordt meegerekend in de totale TTFB-score, waardoor deze mogelijk hoger lijkt dan verwacht.
Wanneer een pagina wordt omgeleid, zijn dit de gebruikelijke stappen die plaatsvinden:
- De browser stuurt een initieel verzoek naar de oorspronkelijke URL.
- De server verwerkt dit verzoek en reageert met een redirect statuscode (bijv. 301 of 302).
- De browser stuurt vervolgens een nieuw verzoek naar de omgeleide URL.De server verwerkt dit tweede verzoek en begint de daadwerkelijke inhoud te verzenden.
Verhoogde Serververwerkingstijd
Deze extra verwerking verhoogt de totale TTFB, aangezien elke stap tijd vereist voor de server om het verzoek af te handelen en te reageren.
Redirect-ketens
In sommige gevallen kunnen meerdere redirects optreden voordat de eindbestemming wordt bereikt. Dit creëert een "redirect-keten" die de TTFB kan verhogen. Elke redirect in de keten voegt zijn eigen verwerkingstijd toe, wat bijdraagt aan de vertraging voordat de eerste byte van de daadwerkelijke inhoud wordt ontvangen.
Netwerklatentie
Redirects brengen vaak extra netwerk-round-trips met zich mee tussen de client en server. Dit introduceert extra netwerklatentie, vooral als de redirects verschillende domeinen of servers betreffen. De fysieke afstand tussen de client en 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 toegevoegd aan de Time to First Byte. JavaScript redirects worden niet toegevoegd aan de Time to First Byte omdat een volledig antwoord (200) door de server is verzonden.
Men zou kunnen denken dat JavaScript redirects de voorkeur zouden moeten hebben omdat ze niet bijdragen aan de time to first byte. Helaas zijn JavaScript redirects een stuk trager voor echte gebruikers en zullen ze een oorzaak zijn van slechte User Experience,
Impact op User Experience (en SEO)
Hoewel redirects soms noodzakelijk zijn, kan hun impact op TTFB bredere implicaties hebben:
- User Experience: Tragere TTFB door redirects kan de initiële rendering van de pagina vertragen, wat gebruikers mogelijk frustreert.
- SEO: Hoewel TTFB geen directe rankingfactor is, beïnvloedt het andere metrieken zoals Largest Contentful Paint (LCP), wat een Core Web Vital is waar zoekmachines rekening mee houden.
Hoe meet je TTFB-problemen veroorzaakt door redirects
Om de impact te vinden die echte gebruikers ervaren door redirects, zul je een RUM-tool zoals CoreDash moeten gebruiken. Real user monitoring laat je de Core Web Vitals tot in detail volgen.
In CoreDash klik je gewoon 'op redirect count' om je data gesegmenteerd per redirect count te visualiseren. Klik vervolgens bijvoorbeeld op een '1 redirect' segment om de RUM-data te filteren op '1 redirect' en alle getroffen url's te bekijken.

Hoe minimaliseer je Redirect Impact
Als algemene regel volg je deze 3 simpele stappen om redirect-problemen te voorkomen:
- Minimaliseer het gebruik van redirects waar mogelijk.
- Vermijd redirect-ketens door links bij te werken zodat ze direct naar de uiteindelijke bestemmings-URL verwijzen.
- Gebruik server-side redirects in plaats van client-side redirects wanneer mogelijk, aangezien ze over het algemeen sneller zijn.
Same origin redirects. Same-origin redirects komen voort uit links op je eigen website. Je zou volledige controle over deze links moeten hebben en je zou het repareren van deze links prioriteit moeten geven bij het werken aan de Time to First Byte. De typische methode om deze interne redirects te vinden is door een van de beschikbare [url=https://www.marketingtracer.com/]tools[/url] te gebruiken die je in staat stellen je hele website te controleren op redirects.
Cross-origin redirects. Cross-origin redirects komen voort uit links op andere websites. Je hebt hier heel weinig controle over. Voor links met een hoge impact die veel verkeer genereren, overweeg dan contact op te nemen met de webmaster van de site om de gelinkte URL bij te werken.
Redirect-ketens. Meervoudige redirects of redirect-ketens treden op wanneer een enkele redirect niet doorverwijst naar de uiteindelijke locatie van de resource. Deze typen redirects belasten de Time to First Byte meer en moeten koste wat het kost vermeden worden. Gebruik opnieuw een [url=https://www.marketingtracer.com/]tool[/url] om deze typen redirects te vinden en repareer ze!
HTTP-naar-HTTPS redirects. Een manier om hier omheen te komen is door de Strict-Transport-Security header (HSTS) te gebruiken, die HTTPS afdwingt bij het eerste bezoek aan een origin, en vervolgens de browser vertelt om in toekomstige bezoeken onmiddellijk toegang te krijgen tot de origin via het HTTPS-schema.
In het algemeen raden we aan om:
- Regelmatig je interne links te controleren en bij te werken! Wanneer je de locatie van een pagina wijzigt, werk dan je interne links naar die pagina bij om ervoor te zorgen dat er geen verwijzingen naar de eerdere paginalocatie overblijven.
- Handel redirects af op serverniveau. Waarbij de voorkeursmethode voor redirect een 301 redirect is. Een 301 redirect is een permanente redirect, terwijl een 302 redirect een tijdelijke redirect is. Tijdelijke redirects, bijvoorbeeld, worden mogelijk niet bijgewerkt in zoekmachines.
- Gebruik relatieve URL's: Wanneer je linkt naar pagina's op je eigen website, gebruik dan relatieve URL's in plaats van absolute URL's. Dit helpt onnodige redirects te voorkomen.
- Gebruik canonieke URL's: Als je meerdere pagina's hebt met vergelijkbare inhoud, gebruik dan een canonieke URL om de voorkeursversie van de pagina aan te geven. Dit helpt duplicate content en onnodige redirects te voorkomen.
Urgent Fix Required?
Google Search Console failing? I offer rapid-response auditing to identify the failure point within 48 hours.
- 48hr Turnaround
- Rapid Response
- Failure Identification