TTFB Request Duration: Verminder de verwerkingstijd van de server

Verminder het Request Duration-subonderdeel 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 subonderdeel van de TTFB. Het meet de tijd die uw server daadwerkelijk besteedt aan het verwerken van een verzoek: ontvangen, applicatielogica uitvoeren, databases bevragen en het HTML-antwoord genereren. Van alle TTFB-subonderdelen is request duration degene waarover u de meeste controle heeft. In mijn ervaring met het auditen van sites met CoreDash is het de grootste bijdrager aan een trage TTFB op de meerderheid van websites.

De Time to First Byte (TTFB) kan worden opgedeeld 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 richt zich op het request duration-gedeelte van de Time to First Byte. Als u niet zeker weet wat request duration betekent, begin dan met wat is de Time to First Byte en TTFB-problemen identificeren en oplossen.

Wat er gebeurt tijdens de Request Duration

Request duration begint op het moment dat de server het HTTP-verzoek ontvangt en eindigt wanneer het de eerste byte van het antwoord 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 het verzoek en routeert het naar de applicatielaag.
2. Application bootstrap: het framework initialiseert. In WordPress betekent dit het laden van de core, actieve plugins en het thema. In Node.js/Express betekent dit middleware-uitvoering.
3. Business logic: uw applicatiecode draait: authenticatiecontroles, rechtenvalidatie, datatransformatie, templateselectie.
4. Databasequery's: de applicatie bevraagt MySQL, PostgreSQL, MongoDB of welke dataopslag u ook gebruikt. Dit is vaak de traagste stap.
5. Response-generatie: de applicatie rendert het HTML- (of JSON-) antwoord uit templates, componentbomen of serialisatielogica.

Elk van deze stappen voegt tijd toe. Een goed geoptimaliseerde server voltooit de gehele keten in minder dan 100ms. Een slecht geoptimaliseerde kan 800ms of meer kosten, en dat is voordat DNS, verbinding en netwerklatentie zelfs maar in beeld komen.

Hoe Request Duration te meten met de Server-Timing API

De Server-Timing HTTP-header is het beste hulpmiddel voor het diagnosticeren van request duration. Hiermee kunt u tijdmetingen van de server rechtstreeks naar de browser sturen, waar ze verschijnen in DevTools en toegankelijk zijn via de Performance API. Dit betekent dat u individuele stappen kunt meten (databasequery's, template-rendering, cache-lookups) en precies kunt zien wat traag is.

Het Server-Timing header-formaat 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", wat u een server-side waterfall geeft die direct verwijst naar uw code.

Server-Timing in PHP

PHP's hrtime(true)-functie biedt nanosecondeprecisie, waardoor het ideaal is voor het meten van individuele server-side bewerkingen. Zo voegt u Server-Timing toe aan een PHP-applicatie:

// 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

Gebruik in Node.js process.hrtime.bigint() voor tijdmetingen met hoge resolutie. Een middleware-patroon laat u de totale verwerkingstijd van verzoeken en individuele bewerkingen 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. Hier zijn de meest voorkomende oorzaken van een trage request duration, gerangschikt op hoe vaak ik ze tegenkom:

• Trage databasequery's: query's zonder index, N+1 query-patronen, volledige tabelscans op grote tabellen. Dit is de nummer één oorzaak. Een enkele ontbrekende index op een WooCommerce-producttabel kan 300 tot 500ms per verzoek toevoegen.
• Ontbrekende paginacaching: dezelfde HTML voor elke bezoeker opnieuw genereren terwijl de inhoud niet is veranderd. Dit komt vooral voor op WordPress-sites zonder object cache of page cache-plugin.
• Dure berekeningen: complexe berekeningen, beeldverwerking of data-aggregatie bij elk verzoek uitvoeren in plaats van de resultaten te cachen.
• Externe API-calls: synchrone verzoeken aan third-party API's (betalingsgateways, CRM-systemen, inventarisdiensten) die het antwoord blokkeren totdat ze voltooid zijn.
• Niet-geoptimaliseerde applicatiecode: ongebruikte modules laden, onnodige middleware draaien of inefficiënte algoritmen gebruiken voor dataverwerking.
• Cold starts: op serverless platforms (AWS Lambda, Cloudflare Workers, Vercel Functions) brengt het eerste verzoek na een periode van inactiviteit container-initialisatie-overhead met zich mee.

Platformspecifieke oplossingen

WordPress

WordPress-sites zijn bijzonder kwetsbaar voor een trage request duration omdat elke paginalading de volledige WordPress-core, alle actieve plugins en het thema opstart. Dit maakt het grootste verschil:

• Installeer een persistent object cache: Redis of Memcached. WordPress draait tientallen databasequery's per paginalading, waarvan veel identiek zijn voor verschillende bezoekers. Een object cache (via een plugin zoals Redis Object Cache) slaat deze resultaten op in het geheugen en vermindert de databasetijd met 60 tot 80%.
• Schakel full-page caching in: gebruik een page cache op serverniveau (Nginx FastCGI Cache, Varnish) of een plugin zoals WP Super Cache. Dit levert gecachte HTML direct af zonder PHP aan te raken.
• Controleer trage plugins: gebruik de Query Monitor-plugin om te identificeren welke plugins de meeste databasequery's genereren of de meeste PHP-uitvoeringstijd verbruiken.
• Optimaliseer WooCommerce-query's: WooCommerce staat berucht om trage productquery's. Schakel de High-Performance Order Storage (HPOS)-functie in en voeg 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-productquery te optimaliseren die bij elke paginalading werd uitgevoerd. De productquery alleen was al verantwoordelijk voor 450ms omdat het een volledige tabelscan deed op 80.000 postmeta-rijen zonder index.

Node.js

Node.js-applicaties hebben doorgaans een snelle request duration out of the box, maar problemen verschijnen bij opschaling of met blokkerende bewerkingen:

• Profileer met de ingebouwde inspector: draai node --inspect app.js en verbind Chrome DevTools om CPU-intensieve functies te identificeren. Let op synchrone bewerkingen die de event loop blokkeren.
• Schakel ORM-querylogging in: als u Sequelize, Prisma of TypeORM gebruikt, schakel querylogging in om N+1-patronen en trage query's te vinden. In Sequelize: sequelize = new Sequelize({ logging: console.log }).
• Gebruik connection pooling: maak geen nieuwe databaseverbinding aan voor elk verzoek. Gebruik een connection pool (ingebouwd in de meeste Node.js-databasedrivers) om verbindingen te hergebruiken.
• Implementeer in-memory caching: gebruik voor vaak opgevraagde gegevens die niet vaak veranderen een LRU-cache om de database niet bij elk verzoek te belasten.

PHP (niet-WordPress)

Voor Laravel, Symfony of aangepaste PHP-applicaties:

• Schakel OPcache in: PHP's OPcache compileert PHP-scripts naar bytecode en slaat ze op in gedeeld geheugen, waardoor het niet meer nodig is om bij elk verzoek te parsen en compileren. Dit alleen kan de request duration al met 30 tot 50% verminderen.
• Gebruik een bytecode-preloader: PHP 8.0+ ondersteunt preloading (beschikbaar sinds PHP 7.4), dat frameworkbestanden bij het opstarten van de server in het geheugen laadt, zodat ze niet per verzoek 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 baseline request duration vergeleken met Node.js of PHP:

• Gebruik een async framework: als I/O-wachttijd het knelpunt is, overweeg FastAPI of Django met ASGI om databasequery's en API-calls gelijktijdig af te handelen.
• Schakel Django's databasequerylogging in: stel LOGGING in de instellingen in om alle SQL-query's te loggen en trage of overbodige te identificeren.
• Gebruik select_related() en prefetch_related(): Django's ORM genereert zonder problemen N+1-query's tenzij u het expliciet vertelt om gerelateerde tabellen te joinen.

Database Connection Pooling

Het openen van een nieuwe databaseverbinding voor elk verzoek is een van de meest voorkomende, en meest vermijdbare, oorzaken van een trage request duration. Elke nieuwe verbinding vereist een TCP-handshake, authenticatie en sessie-initialisatie, wat 5 tot 30ms per verzoek kan toevoegen. Onder belasting wordt dit catastrofaal wanneer de databaseserver geen beschikbare verbindingen meer heeft.

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

De meeste databasedrivers ondersteunen connection pooling standaard. In Node.js met pg (PostgreSQL) configureert u het bijvoorbeeld 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]);

Overweeg voor PHP-applicaties achter PHP-FPM het gebruik van persistent connections (PDO::ATTR_PERSISTENT) of een externe pooler zoals PgBouncer voor PostgreSQL of ProxySQL voor MySQL.

Reverse Proxy Caching

Het snelste antwoord is er een dat uw applicatie nooit hoeft te genereren. Een reverse proxy cache (Varnish, Nginx FastCGI Cache of een CDN edge cache) zit voor uw applicatieserver en levert gecachte antwoorden rechtstreeks vanuit het geheugen. Voor pagina's die niet veranderen tussen bezoekers (wat de meerderheid van de pagina's op de meeste websites omvat) brengt dit de request duration terug naar bijna nul.

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

De sleutel tot effectieve reverse proxy caching zijn juiste Cache-Control-headers. Stel s-maxage in voor de shared 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-platformen zoals Cloudflare Workers en Vercel Edge Functions draaien uw server-side code op CDN edge-locaties, fysiek dicht bij uw gebruikers. Edge computing maakt uw code niet sneller, maar elimineert de netwerklatentie tussen de gebruiker en uw origin-server. Dit is het belangrijkst voor gebruikers die ver van uw origin-datacenter zijn.

Edge functions werken het best voor:

• Lichtgewicht API-antwoorden die geen zware databasetoegang vereisen
• Personalisatielogica (A/B-testen, geo-gebaseerde inhoud) die aan de edge wordt toegepast voordat uw origin wordt bereikt
• HTML-herschrijvingen en header-manipulatie zonder een volledige origin-roundtrip

Voor pagina's die databasequery's vereisen, lost edge computing alleen de request duration-problemen niet op. 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-subonderdeel van de TTFB rechtstreeks in de browser meten met 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 200ms ligt, geeft aan dat uw server te veel tijd besteedt aan het verwerken van het verzoek. Gebruik de Server-Timing header (hierboven beschreven) om te identificeren welk deel van de serververwerking verantwoordelijk is.

Hoe Request Duration-problemen te 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 de daadwerkelijke TTFB-uitsplitsing die uw bezoekers ervaren over pagina's, apparaten en locaties. Geen labresultaten.

Klik in CoreDash 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 200ms ligt. Dat zijn uw optimalisatiedoelen.

Wat onze data laat zien

Over duizenden sites die door CoreDash worden gemonitord, is request duration (serververwerkingstijd) het grootste TTFB-subonderdeel op de meerderheid van sites in onze dataset, waardoor serveroptimalisatie de grootste TTFB-verbetering is voor de meeste websites.

Sites met full-page caching ingeschakeld hebben een mediane request duration van ongeveer 35ms. Sites zonder caching hebben een mediaan van ongeveer 320ms. Dat verschil (bijna 10x) is het sterkste argument dat ik kan maken om te investeren in server-side caching vóór al het andere.

Request duration is onderdeel van de Time to First Byte, wat een diagnostische metriek is voor de Core Web Vitals. Voor een complete gids over het identificeren en oplossen van TTFB-problemen, zie onze TTFB identificeren en oplossen-gids. U kunt ook de ultieme Core Web Vitals-checklist raadplegen voor een uitgebreid optimalisatieoverzicht.

Verder lezen: optimalisatiegidsen

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

• 103 Early Hints: stuur resource hints (preload, preconnect) naar de browser terwijl de server het verzoek nog verwerkt, wat de waargenomen TTFB vermindert.
• Cloudflare configureren voor prestaties: gebruik CDN edge caching en geoptimaliseerde serverconfiguraties om de request duration wereldwijd te verminderen.

TTFB-subonderdelen: complete gidsen

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

• TTFB-problemen identificeren en oplossen: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Waiting Duration: redirects, browserwachtrij en HSTS-optimalisatie.
• Cache Duration: service worker-prestaties, browser cache-lookups en bfcache.
• DNS Duration: DNS-providerselectie, TTL-configuratie en dns-prefetch.
• Connection Duration: TCP-handshake, TLS-optimalisatie, HTTP/3 en preconnect.