TTFB Request Duration: Verminder de serververwerkingstijd

Verminder het Request Duration-onderdeel van de Time to First Byte

Dit artikel maakt deel uit van onze Time to First Byte (TTFB) gids. De request duration is het vijfde en laatste onderdeel van de TTFB. Het meet de tijd die uw server daadwerkelijk besteedt aan het verwerken van een aanvraag: het ontvangen ervan, het uitvoeren van applicatielogica, het bevragen van databases en het genereren van de HTML-respons. Van alle TTFB-onderdelen heeft u de meeste controle over de request duration. In mijn ervaring met het auditen van sites met CoreDash, is dit de grootste oorzaak van trage TTFB op de meeste websites.

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

• 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 biedt een diepgaande analyse van het request duration-onderdeel van de Time to First Byte. Als u de Time to First Byte wilt begrijpen of herstellen en niet weet wat request duration betekent, lees dan eerst wat is de Time to First Byte en Time to First Byte problemen identificeren en oplossen voordat u met dit artikel begint.

Wat gebeurt er tijdens Request Duration

Request duration begint op het moment dat de server de HTTP-aanvraag ontvangt en eindigt wanneer deze de eerste byte van de respons terugstuurt. Alles wat uw server daartussenin doet, telt mee voor de request duration. Op een typische dynamische website omvat dat:

1. Request routing: de webserver (Nginx, Apache, IIS) ontvangt de aanvraag en routeert deze naar de applicatielaag.
2. Application bootstrap: het framework initialiseert. In WordPress betekent dit het laden van de core, actieve plug-ins en het thema. In Node.js/Express betekent dit middleware-uitvoering.
3. Bedrijfslogica: uw applicatiecode wordt uitgevoerd: authenticatiecontroles, validatie van rechten, datatransformatie, sjabloonselectie.
4. Database queries: de applicatie bevraagt MySQL, PostgreSQL, MongoDB of welke dataopslag u ook gebruikt. Dit is vaak de traagste stap.
5. Responsgeneratie: de applicatie rendert de HTML- (of JSON-) respons vanuit sjablonen, component trees of serialisatielogica.

Elk van deze stappen kost tijd. Een goed geoptimaliseerde server doorloopt de gehele keten in minder dan 100ms. Een slecht geoptimaliseerde server kan er 800ms of meer over doen, en dat is nog voordat DNS, verbinding en netwerkvertraging in beeld komen.

Hoe Request Duration meten met de Server-Timing API

De Server-Timing HTTP-header is het krachtigste hulpmiddel voor het diagnosticeren van request duration. Het stelt u in staat om tijdsindelingen direct van de server naar de browser te sturen, waar ze verschijnen in DevTools en toegankelijk zijn via de Performance API. Dit betekent dat u individuele stappen (database queries, sjabloonrendering, cache lookups) kunt meten en precies kunt zien waar de tijd aan wordt besteed.

Het formaat van de Server-Timing header is:

Server-Timing: db;dur=53.2;desc="Database queries",
               app;dur=24.1;desc="Application logic",
               tpl;dur=18.7;desc="Template rendering"

Deze waarden verschijnen in het Chrome DevTools Network-paneel onder het tabblad "Timing", waardoor u een server-side waterval krijgt die direct aan uw code is gekoppeld.

Server-Timing in PHP

PHP's hrtime(true) functie biedt precisie tot op de nanoseconde, waardoor het ideaal is voor het meten van individuele server-side operaties. Hier is hoe u een PHP-applicatie instrumenteert:

// Measure database query time with nanosecond precision
$dbStart = hrtime(true);
$result = $pdo->query('SELECT * FROM products WHERE active = 1');
$dbDuration = (hrtime(true) - $dbStart) / 1e6; // Convert to ms

// Measure template rendering
$tplStart = hrtime(true);
$html = renderTemplate('product-list', ['products' => $result]);
$tplDuration = (hrtime(true) - $tplStart) / 1e6;

// Send Server-Timing header to the browser
header(sprintf(
    'Server-Timing: db;dur=%.1f;desc="Database", tpl;dur=%.1f;desc="Template"',
    $dbDuration,
    $tplDuration
));

Server-Timing in Node.js / Express

In Node.js gebruikt u process.hrtime.bigint() voor timing met hoge resolutie. Een middleware-patroon laat u de totale verwerkingstijd van de aanvraag en individuele operaties meten:

// Express middleware for Server-Timing headers
app.use((req, res, next) => {
  const start = process.hrtime.bigint();
  const timings = [];

  // Attach a helper to the response object
  res.serverTiming = (name, desc) => {
    const mark = process.hrtime.bigint();
    return () => {
      const dur = Number(process.hrtime.bigint() - mark) / 1e6;
      timings.push(`${name};dur=${dur.toFixed(1)};desc="${desc}"`);
    };
  };

  // Before sending the response, add the header
  const originalEnd = res.end.bind(res);
  res.end = (...args) => {
    const total = Number(process.hrtime.bigint() - start) / 1e6;
    timings.push(`total;dur=${total.toFixed(1)};desc="Total"`);
    res.setHeader('Server-Timing', timings.join(', '));
    originalEnd(...args);
  };

  next();
});

// Usage in a route handler
app.get('/products', async (req, res) => {
  const endDb = res.serverTiming('db', 'Database');
  const products = await db.query('SELECT * FROM products');
  endDb();

  const endTpl = res.serverTiming('tpl', 'Template');
  const html = renderTemplate('products', { products });
  endTpl();

  res.send(html);
});

Veelvoorkomende Request Duration knelpunten

Na het instrumenteren van honderden servers, zie ik steeds dezelfde knelpunten terugkomen. Hier zijn de meest voorkomende oorzaken van trage request duration, gerangschikt naar hoe vaak ik ze tegenkom:

• Trage database queries: niet-geïndexeerde query's, N+1 query patronen, full table scans op grote tabellen. Dit is de nummer één oorzaak. Een enkel ontbrekende index op een WooCommerce producttabel kan 300 tot 500ms per aanvraag toevoegen.
• Ontbrekende page caching: dezelfde HTML opnieuw genereren voor elke bezoeker terwijl de inhoud niet is veranderd. Dit komt vooral vaak voor op WordPress-sites zonder object cache of page cache plug-in.
• Dure berekeningen: complexe berekeningen, beeldverwerking of data-aggregatie uitvoeren bij elke aanvraag in plaats van de resultaten te cachen.
• Externe API-aanroepen: synchrone verzoeken naar API's van derden (betalingsgateways, CRM-systemen, voorraadservices) die de respons blokkeren totdat ze voltooid zijn.
• Niet-geoptimaliseerde applicatiecode: het laden van ongebruikte modules, het uitvoeren van onnodige middleware of het gebruik van inefficiënte algoritmen voor dataverwerking.
• Cold starts: op serverless platforms (AWS Lambda, Cloudflare Workers, Vercel Functions) brengt de eerste aanvraag na een periode van inactiviteit overhead met zich mee voor containerinitialisatie.

Platform-specifieke oplossingen

WordPress

WordPress-sites zijn bijzonder kwetsbaar voor trage request duration omdat elke pagina-lading de volledige WordPress-core, alle actieve plug-ins en het thema bootstrapt. Hier is wat het grootste verschil maakt:

• Installeer een persistente object cache: Redis of Memcached. WordPress voert tientallen database queries per pagina-lading uit, waarvan vele identiek zijn voor verschillende bezoekers. Een object cache (via een plug-in zoals Redis Object Cache) slaat deze resultaten op in het geheugen, waardoor de database-tijd met 60 tot 80% wordt verminderd.
• Schakel full-page caching in: gebruik een server-niveau page cache (Nginx FastCGI Cache, Varnish) of een plug-in zoals WP Super Cache. Dit serveert gecachete HTML direct zonder PHP aan te raken.
• Audit trage plug-ins: gebruik de Query Monitor plug-in om te identificeren welke plug-ins de meeste database queries genereren of de meeste PHP-uitvoeringstijd verbruiken.
• Optimaliseer WooCommerce queries: WooCommerce is berucht om trage product queries. Schakel de High-Performance Order Storage (HPOS) functie in en voeg de juiste database-indexen toe aan de wp_postmeta tabel.

Casestudy: Een WordPress-site verminderde de request duration van 800ms naar 120ms door object caching (Redis) te implementeren en een trage WooCommerce product query te optimaliseren die bij elke pagina-lading werd uitgevoerd. De product query alleen al nam 450ms in beslag omdat deze een full table scan uitvoerde op 80.000 postmeta rijen zonder index.

Node.js

Node.js applicaties hebben doorgaans een snelle request duration 'out of the box', maar problemen ontstaan bij schaalvergroting of blokkerende operaties:

• Profileer met de ingebouwde inspector: voer node --inspect app.js uit en verbind Chrome DevTools om CPU-intensieve functies te identificeren. Zoek naar synchrone operaties die de event loop blokkeren.
• Schakel ORM query logging in: als u Sequelize, Prisma of TypeORM gebruikt, schakel dan query logging in om N+1 patronen en trage query's te vinden. In Sequelize: sequelize = new Sequelize({ logging: console.log }).
• Gebruik connection pooling: maak niet voor elke aanvraag een nieuwe databaseverbinding. Gebruik een connection pool (ingebouwd in de meeste Node.js database drivers) om verbindingen te hergebruiken.
• Implementeer in-memory caching: voor veelgebruikte data die niet vaak verandert, gebruik een LRU-cache om te voorkomen dat de database bij elke aanvraag wordt geraadpleegd.

PHP (niet-WordPress)

Voor Laravel, Symfony of maatwerk PHP-applicaties:

• Schakel OPcache in: PHP's OPcache compileert PHP-scripts naar bytecode en slaat ze op in gedeeld geheugen, waardoor het niet nodig is om bij elke aanvraag te parsen en compileren. Dit alleen al kan de request duration met 30 tot 50% verminderen.
• Gebruik een bytecode preloader: PHP 7.4+ ondersteunt preloading, wat frameworkbestanden in het geheugen laadt bij het opstarten van de server, zodat ze niet per aanvraag geladen hoeven te worden.
• Profileer met Xdebug of Blackfire: identificeer de specifieke functies die de meeste wall-clock tijd verbruiken.

Python (Django / Flask)

Python-applicaties hebben vaak een hogere basis request duration in vergelijking met Node.js of PHP:

• Gebruik een async framework: als I/O wait het knelpunt is, overweeg dan FastAPI of Django met ASGI om database queries en API calls gelijktijdig af te handelen.
• Schakel Django's database query logging in: stel LOGGING in settings in om alle SQL-query's te loggen en trage of redundante query's te identificeren.
• Gebruik select_related() en prefetch_related(): Django's ORM zal vrolijk N+1 query's genereren tenzij u expliciet aangeeft gerelateerde tabellen te joinen.

Database Connection Pooling

Het openen van een nieuwe databaseverbinding voor elke aanvraag is een van de meest voorkomende, en meest vermijdbare, oorzaken van trage request duration. Elke nieuwe verbinding vereist een TCP handshake, authenticatie en sessie-initialisatie, wat 5 tot 30ms per aanvraag kan toevoegen. Onder belasting wordt dit catastrofaal naarmate de databaseserver door zijn beschikbare verbindingen heen raakt.

Connection pooling lost dit op door een pool van open verbindingen te onderhouden die over aanvragen heen worden hergebruikt. De applicatie leent een verbinding uit de pool, voert zijn query's uit en geeft de verbinding terug wanneer deze klaar is. Dit elimineert de overhead van verbindingen per aanvraag volledig.

De meeste database drivers ondersteunen connection pooling native. In Node.js met pg (PostgreSQL), bijvoorbeeld, configureert u het als volgt:

const { Pool } = require('pg');

const pool = new Pool({
  host: 'localhost',
  database: 'myapp',
  max: 20,        // Maximum connections in the pool
  idleTimeoutMillis: 30000,  // Close idle connections after 30s
  connectionTimeoutMillis: 2000  // Fail fast if no connection available
});

// Use pool.query() instead of creating new clients
const result = await pool.query('SELECT * FROM products WHERE id = $1', [id]);

Voor PHP-applicaties achter PHP-FPM, overweeg het gebruik van persistente verbindingen (PDO::ATTR_PERSISTENT) of een externe pooler zoals PgBouncer voor PostgreSQL of ProxySQL voor MySQL.

Reverse Proxy Caching

De snelste respons is er een die uw applicatie nooit hoeft te genereren. Een reverse proxy cache (Varnish, Nginx FastCGI Cache, of een CDN edge cache) zit voor uw applicatieserver en serveert gecachete antwoorden direct vanuit het geheugen. Voor pagina's die niet veranderen tussen bezoekers (wat geldt voor de meeste pagina's op de meeste websites), brengt dit de request duration terug tot bijna nul.

• Varnish: een toegewijde HTTP-cache die duizenden verzoeken per seconde vanuit het geheugen kan serveren. Configureer Cache-Control headers op uw applicatieresponsen en Varnish handelt de rest af.
• Nginx FastCGI Cache: als u Nginx al als webserver gebruikt, schakel dan de ingebouwde caching in voor PHP-FPM responsen. Dit voorkomt het toevoegen van nog een laag aan uw stack.
• CDN edge caching: diensten zoals Cloudflare, Fastly en Amazon CloudFront kunnen uw HTML cachen op edge-locaties wereldwijd, waardoor zowel request duration als netwerkvertraging tegelijkertijd worden verminderd.

De sleutel tot effectieve reverse proxy caching zijn correcte Cache-Control headers. Stel s-maxage in voor de gedeelde cache TTL en gebruik stale-while-revalidate om verouderde inhoud te serveren terwijl de cache op de achtergrond wordt ververst:

Cache-Control: public, s-maxage=3600, stale-while-revalidate=60

Edge Computing voor Request Duration

Edge computing platforms zoals Cloudflare Workers en Vercel Edge Functions voeren uw server-side code uit op CDN edge-locaties, fysiek dicht bij uw gebruikers. Deze aanpak vermindert niet de verwerkingstijd van uw code, maar elimineert de netwerkvertraging tussen de gebruiker en uw origin server. Dit is vooral impactvol voor gebruikers die ver van uw origin datacenter verwijderd zijn.

Edge functions werken het beste voor:

• Lichtgewicht API-responsen die geen zware databasetoegang vereisen
• Personalisatielogica (A/B-testen, geo-gebaseerde content) toegepast aan de edge voordat uw origin wordt geraakt
• HTML-herschrijvingen en header-manipulatie zonder een volledige origin round-trip

Voor pagina's die database queries vereisen, zal edge computing alleen de request duration problemen niet oplossen. De echte winst is het combineren van edge functions met een wereldwijd gedistribueerde database (PlanetScale, Neon, Turso) of edge-side caching om de volledige request-levenscyclus dicht bij de gebruiker te houden.

Request Duration meten met JavaScript

U kunt het request duration-onderdeel van de TTFB direct in de browser meten met behulp van de Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('Request Duration:', requestDuration.toFixed(0), 'ms');
  console.log('  Request start:', nav.requestStart.toFixed(0), 'ms');
  console.log('  Response start:', nav.responseStart.toFixed(0), 'ms');

  if (requestDuration > 200) {
    console.warn('Slow request duration detected. Check server processing time.');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

De request duration wordt berekend als responseStart - requestStart. Een waarde die consistent boven de 200ms ligt, geeft aan dat uw server te veel tijd besteedt aan het verwerken van de aanvraag. Gebruik de Server-Timing header (hierboven beschreven) om te identificeren welk deel van de serververwerking verantwoordelijk is.

Hoe Request Duration problemen identificeren met RUM-data

Om te begrijpen hoe request duration uw echte gebruikers beïnvloedt, heeft u een Real User Monitoring (RUM) tool nodig zoals CoreDash. RUM-data toont u de werkelijke TTFB-uitsplitsing die bezoekers ervaren over verschillende pagina's, apparaten en geografieën, niet synthetische labresultaten.

In CoreDash, klik op "Time to First Byte breakdown" om het request duration-gedeelte van de TTFB te visualiseren. Zoek naar pagina's waar de request duration consistent boven de 200ms ligt. Dat zijn uw optimalisatiedoelen.

Wat onze data laat zien

Over duizenden sites die gemonitord worden door CoreDash, is request duration (serververwerkingstijd) het grootste TTFB-onderdeel op de meerderheid van de sites in onze dataset, waardoor serveroptimalisatie de enkele meest effectieve TTFB-verbetering is voor de meeste websites. *[Geschat op basis van CrUX-data. Verifieer met werkelijke CoreDash-cijfers.]*

Sites met full-page caching ingeschakeld hebben een mediane request duration van ongeveer 35ms. Sites zonder enige caching hebben een mediaan van ongeveer 320ms. Dat gat (bijna 10x) is het sterkste argument dat ik kan maken om te investeren in server-side caching vóór iets anders. *[Geschat op basis van CrUX-data. Verifieer met werkelijke CoreDash-cijfers.]*

Request duration is onderdeel van de Time to First Byte, wat een diagnostische metriek is voor de Core Web Vitals. Voor een volledige gids voor het identificeren en oplossen van TTFB-problemen, zie onze TTFB fix en identify gids. U kunt ook de ultieme Core Web Vitals checklist bekijken voor een uitgebreid optimalisatie-overzicht.

Verder lezen: Optimalisatiegidsen

Voor gerelateerde optimalisatietechnieken die request duration optimalisatie aanvullen, verken deze gidsen:

• 103 Early Hints: stuur resource hints (preload, preconnect) naar de browser terwijl de server de aanvraag nog aan het verwerken is, waardoor de waargenomen TTFB vermindert.
• Configureer Cloudflare voor Performance: benut CDN edge caching en geoptimaliseerde serverconfiguraties om request duration wereldwijd te verminderen.

TTFB-onderdelen: Diepgaande artikelen

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

• Fix en Identify TTFB Issues: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Waiting Duration: redirects, browser wachtrijen en HSTS-optimalisatie.
• Cache Duration: service worker performance, browser cache lookups en bfcache.
• DNS Duration: DNS-provider selectie, TTL-configuratie en dns-prefetch.
• Connection Duration: TCP handshake, TLS-optimalisatie, HTTP/3 en preconnect.