---
title: "Wat is TTFB? Uitleg en betekenis | Keurig Online"
description: "TTFB (Time to First Byte) meet de tijd tussen een HTTP-verzoek en de eerste byte van het serverantwoord."
canonical: https://www.keurigonline.nl/begrippenlijst/ttfb
last_modified: 2025-12-18
---

[Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst)

# TTFB

TTFB (Time to First Byte) meet de tijd tussen een HTTP-verzoek en de eerste byte van het serverantwoord.

Actueel: [Hosting webshop: wat heeft een kleine webshop écht nodig?](https://www.keurigonline.nl/blog/hosting-webshop)

TTFB staat voor Time to First Byte. Het is een prestatiemeting die aangeeft hoe snel een webserver reageert op een verzoek. De tijd wordt gemeten vanaf het moment dat je browser een pagina opvraagt tot het eerste stukje data binnenkomt.

De TTFB bestaat uit meerdere onderdelen. Eerst vindt de DNS-lookup plaats om het IP-adres te vinden. Daarna wordt een TCP-verbinding opgezet. Bij HTTPS volgt ook een TLS-handshake voor versleuteling. Tot slot verwerkt de server het verzoek en stuurt de eerste byte terug.

Google hanteert duidelijke richtlijnen voor TTFB. Een score onder 800 milliseconden is goed. Tussen 800 en 1800 milliseconden is gemiddeld en kan verbeterd worden. Boven 1800 milliseconden is slecht en vereist actie. Een snelle TTFB is belangrijk omdat het alle andere laadtijden beïnvloedt, zoals First Contentful Paint (FCP) en Largest Contentful Paint (LCP).

Je kunt TTFB verbeteren door betere hosting te kiezen, server-side caching te gebruiken, een CDN in te zetten, en database-queries te optimaliseren. Bij KeurigOnline helpen LiteSpeed en server-side caching om de TTFB laag te houden.

## Geschiedenis

TTFB is ontstaan als prestatiemeting in de vroege dagen van het web. Het concept werd belangrijk toen [webprestaties](https://en.wikipedia.org/wiki/Web_performance) steeds meer aandacht kregen bij zoekmachines en gebruikers.

Belangrijke ontwikkelingen:

- **2010:** Google introduceert sitesnelheid als rankingfactor
- **2018:** Mobiele snelheid wordt rankingfactor voor mobiele zoekresultaten
- **2020:** [Core Web Vitals](https://web.dev/articles/vitals) worden geïntroduceerd (TTFB ondersteunt LCP)
- **2021:** Core Web Vitals worden officiële rankingfactor

## Bronnen

1. **Google/web.dev** - [Time to First Byte (TTFB) \| Articles](https://web.dev/articles/ttfb)
2. **MDN Web Docs** - [Time to First Byte (TTFB) - Glossary](https://developer.mozilla.org/en-US/docs/Glossary/Time_to_first_byte)
3. **Wikipedia** - [Time to first byte](https://en.wikipedia.org/wiki/Time_to_first_byte)
4. **Fastly Learning** - [What is Time to First Byte?](https://www.fastly.com/learning/cdn/what-is-time-to-first-byte)

## Gerelateerde artikelen

Hosting 29 okt 2026

[Hosting webshop: wat heeft een kleine webshop écht nodig?](https://www.keurigonline.nl/blog/hosting-webshop)

- Een verkeerd ingestelde cache kan bezoekers elkaars winkelwagen laten zien[\[7\]](https://hostingradar.nl/blog/beste-webshop-hosting-woocommerce).
- Sluit in je cacheplugin altijd de winkelwagen-, afreken- en accountpagina's uit.

Juist op die ongecachete pagina's zie je hoe goed je hosting is, omdat daar de wachttijd tot de eerste byte oploopt. Lees in [wat is TTFB](https://keurigonline.nl/blog/wat-is-ttfb) hoe je die meet. En snelheid levert direct omzet op: bij retailsites gaf een mobiele site die 0,1 seconde sneller laadde 8,4% meer conversie en een 9,2% hogere gemiddelde orderwaarde (Deloitte en Google, 37 merken, 30,5 miljoen sessies)[\[8\]](https://www.deloitte.com/ie/en/services/consulting/research/milliseconds-make-millions.html). Google stelt dat één seconde vertraging de conversie tot 20% kan raken[\[9\]](https://services.google.com/fh/files/misc/3stepstoafastersite.pdf). Meer over de koppeling tussen laadtijd en vindbaarheid lees je in ons artikel over [websitesnelheid, SEO en hosting](https://keurigonline.nl/blog/website-snelheid-seo-hosting).

## De echte minimumeisen voor WooCommerce

Haal je eisen uit de documentatie van de software zelf, niet uit een advertentie. WooCommerce noemt voor versie 10.8 en hoger deze serverrequirements[\[10\]](https://woocommerce.com/document/server-requirements/):

WordPress 13 jul 2026

[WordPress-afbeeldingen naar WebP omzetten zonder plugin](https://www.keurigonline.nl/blog/wordpress-afbeeldingen-comprimeren-en-webp-omzetten)

WebP-conversie verkleint je afbeeldingen, maar lost niet automatisch je LCP-probleem op. Google's eigen fielddata relativeert het populaire "comprimeer je afbeeldingen"-advies.

Uit web.dev's eigen analyse van veelvoorkomende misvattingen over LCP blijkt dat de tijd om de afbeelding zelf te downloaden (image load duration) de kortste van de vier LCP-subfases is. Zelfs bij sites met een slechte LCP-score wordt minder dan 10% van de p75-tijd besteed aan het downloaden van de LCP-afbeelding.[\[4\]](https://web.dev/blog/common-misconceptions-lcp) De grootste winst zit meestal ergens anders: in de Time to First Byte (TTFB) en in de "resource load delay", de tijd tussen het eerste byte en het moment waarop de browser daadwerkelijk begint met downloaden van de afbeelding.

Dat betekent niet dat WebP-conversie zinloos is, het betekent dat het noodzakelijk is maar niet voldoende. Een kleinere afbeelding helpt pas echt als de browser ook weet dat hij die afbeelding met prioriteit moet ophalen. Toch krijgt 85,9% van de LCP-afbeeldingen op dit moment geen priority hint mee via `fetchpriority` of een `preload`-tag, een gemiste kans naast formaatconversie.[\[5\]](https://www.corewebvitals.io/state-of-cwv/explorer/metrics.lcp.hint) Wil je die volledige stack aanpakken, van caching tot preload-hints, lees dan ons overzicht van [Core Web Vitals-optimalisatie in WordPress](https://www.keurigonline.nl/blog/wordpress-core-web-vitals-plugin) en de bredere tips in [je WordPress-site sneller maken](https://www.keurigonline.nl/blog/wordpress-website-sneller-maken). Dit artikel focust bewust op het WebP-stuk: de conversie zelf, native en zonder plugin.

SEO 7 jul 2026

[Schema markup toevoegen aan WordPress zonder plugin (JSON-LD)](https://www.keurigonline.nl/blog/wordpress-seo-plugin-vervangen-door-schema-org-markup)

Een onafhankelijke benchmark op GeneratePress met PHP 8.2 liet zien dat Yoast Free ongeveer 33KB paginagewicht en 148ms Total Blocking Time toevoegt bovenop een kale baseline van 90ms; Rank Math Free bleef bij ongeveer 12KB en 92ms[\[9\]](https://nextgrowth.ai/rank-math-review/). WP Rocket's eigen cijfers laten een vergelijkbaar verschil zien in bestandsgrootte: 11,8MB voor Rank Math tegenover 32,4MB voor Yoast[\[9\]](https://nextgrowth.ai/rank-math-review/).

Een aparte plugin-vergelijking zet dat verschil nog scherper neer: een minimale schema-plugin van 186KB haalt gemiddeld 132ms TTFB, terwijl Yoast (bijna 15MB, 1.604 bestanden) daar 81 keer groter voor is en All in One SEO zelfs 100 keer[\[3\]](https://pluginjoy.com/seo-plugin-performance-study-2026/). AIOSEO kan bovendien tot 15 extra databasequeries per paginaload genereren, goed voor 200 tot 400ms extra TTFB op shared hosting, omdat de JSON-LD-schema bij elke request opnieuw wordt opgebouwd in plaats van gecachet[\[10\]](https://www.anewmediagroup.com/blog/how-does-aioseo-influence-page-load-speed/). Handmatige JSON-LD via `functions.php` weegt daarentegen minder dan 1KB en heeft vrijwel geen meetbare invloed op de laadtijd[\[2\]](https://dev.to/schemify/how-to-add-schema-markup-to-wordpress-without-a-plugin-1hhb).

Plugin-bloat is een bekende oorzaak van trage WordPress-sites, zoals we eerder beschreven in [5 redenen waarom je WordPress site zo langzaam is](https://www.keurigonline.nl/blog/5-redenen-waarom-je-wordpress-site-zo-langzaam-is): elke module die je uitschakelt, telt mee. Zie ook [hoe plugins je Core Web Vitals beïnvloeden](https://www.keurigonline.nl/blog/wordpress-core-web-vitals-plugin) voor het bredere plaatje.
