Uw PageSpeed Insights geeft een rode TTFB weer. De onmiddellijke reflex: “je hebt meer CPU nodig” of “je hebt een VPS nodig”. Drie weken later is de rekening verdubbeld en is de serververtraging slechts met 40 ms veranderd. Het scenario is banaal: we hebben een symptoom behandeld zonder de link te identificeren die de eerste byte vertraagt.
Time To First Byte meet de tijd tussen het HTTP-verzoek en de ontvangst van de eerste antwoordbyte. Het condenseert DNS, TLS, netwerkroutering, serverwachtrij, PHP-uitvoering, SQL-query's en optioneel API-oproepen. Het kopen van CPU verkort de trage DNS-resolutie of een niet-geïndexeerde SQL-join niet.
Meet correct — zonder verstrikt te raken in de cache
Een “lab” TTFB en een “echte gebruiker” TTFB vertellen twee verhalen. PageSpeed en Lighthouse meten vaak vanuit datacenters van Google, soms met hot caching. WebPageTest, een krul van uw machine of RUM-rapporten (Real User Monitoring) maken het plaatje compleet.
Minimale procedure:
- Test 'origin — Directe server-URL of
Cache-Control: no-cacheheader. - Vergelijk cache AAN/UIT — een statische pagina (
/favicon.ico) versus een dynamische PHP-pagina. - Herhaal vanuit twee regio's — netwerklatentie ≠ traagheid van de applicatie.
- Let op de tijd — een langzaam zwembad om 14.00 uur. kan aanvaardbaar zijn om 3 uur 's nachts.
| Meting | Wat het isoleert | Limiet |
|---|---|---|
TTFB statische .html pagina | Netwerk + webserver | Negeer PHP/SQL |
| TTFB dynamische pagina | Volledige keten | Mengt verschillende oorzaken |
curl -w '%{time_starttransfer}' | Raw-server, reproduceerbaar | Geen browserweergave |
PHP-FPM-logboeken slowlog | Scripts > drempel (bijv. 5 s) | Kan MySQL niet alleen zien |
Een uitstekende TTFB op een CDN-pagina bewijst niet dat je WordPress snel is. Het bewijst vooral dat de edge-cache werkt.
De keten van verdachten, in bruikbare volgorde
Bekijk deze lijst voordat u een “trage server”-ticket opent. Elke link heeft verschillende signalen.
DNS. Een verkeerd geconfigureerde TTL of langzame oplosser voegt 100-300 ms toe voordat de server zelfs maar reageert. Controleer met dig of tools zoals DNSPerf.
TLS en HTTP/2. SSL-onderhandeling over een slecht gekoppeld certificaat of een verouderde code kost tijd. Zelden het grootste knelpunt, maar wel meetbaar.
PHP-FPM-wachtrij. Als alle werkers bezig zijn, wacht het verzoek: de TTFB gaat omhoog zonder dat het script traag is. Symptoom: Variabele TTFB, pieken gecorreleerd met verkeer.
Traag PHP-script. WordPress-plug-ins, zware autoload, onnodige loops. De FPM slowlog en Blackfire identificeren de boosdoenerfunctie.
Database. Query's zonder indexen, overbelaste postmeta-tabellen, afwezigheid van objectcache (Redis). MySQL slow_query_log is je vriend.
Externe oproepen. Synchrone weer-, CRM- en betalings-API's bij het weergeven van pagina's blokkeren de gehele TTFB.
Typische scenario's: A versus B
| Symptoom | Waarschijnlijke oorzaak | Actie vóór upgrade |
|---|---|---|
| TTFB stabiel ~800 ms, weinig verkeer | SQL-query of plug-in | Profiler, index, objectcache |
| TTFB 200 ms in de ochtend, 2 s in de middag | Verzadigde FPM-werknemers | Pas pm.max_children aan, niet alleen CPU |
| TTFB OK in Frankrijk, traag in de VS | Geografie, geen server | CDN of dichtstbijzijnde regio |
TTFB 50 ms op .html, 900 ms op / | Applicatie, geen hosting | OPcache, paginacache, WP optimaliseren |
De top: de CPU is zelden de eerste hefboom
Dit is wat de pagina's "Premium 8 vCPU-aanbieding" behandelen.
De host kan een snelle server leveren. Het herschrijft uw SELECT * FROM wp_postmeta-query niet. Het verwarren van deze twee vertraagt de echte correctie en verhoogt het budget zonder bewijs.
Beslis en ga vooruit zonder blinde vlek
- Meet originele TTFB, met en zonder cache, gedurende 24 uur.
- Isoleer de link (DNS → FPM → SQL → API).
- Repareer de applicatie voordat u hostingaanbiedingen vergelijkt.
- Opnieuw testen met hetzelfde scenario; Evalueer pas dan een hoger plan of een accommodatievergelijker.
Voor WordPress-sites kunt u deze diagnose vergelijken met de handleidingen OPcache en PHP-FPM. Om hosts te filteren op basis van uw netwerkbeperkingen, raadpleegt u de overzicht.
Veelgestelde vragen
Welke TTFB is acceptabel voor een PHP-site?
Minder dan 200 ms aan de serverzijde voor een dynamische, niet-gecachte pagina is solide. Tussen 200 en 600 ms, graaf de ketting. Daarnaast moet u meten voordat u meer grondstoffen aanschaft.
Bevat TTFB CDN?
Ja, als het verzoek via een CDN gaat. Test de oorsprong met cache-bypass om de echte PHP-prestaties te zien.
Hoe weet ik of het PHP of de database is?
Vergelijk een statische pagina met een dynamische pagina, activeer het MySQL langzame querylogboek en profiel in staging met Blackfire of Xdebug.
Verhelpt het veranderen van host een hoge TTFB?
Zelden zonder de applicatie te corrigeren. Een overbelaste server kan latentie veroorzaken; een langzame SQL-query zal overal traag blijven.
De volgende keer dat er een rode TTFB verschijnt, stelt u een vraag voordat u een CPU aanschaft: welke stap in de keten duurde hoe lang? Het antwoord staat vaak in een logboek en niet in een offerte.