Waarom TTFB de Basis Is van Alle Webprestaties
Time to First Byte — oftewel TTFB — meet de tijd tussen het moment dat de browser een verzoek naar je server stuurt en het moment dat die eerste byte van het antwoord terugkomt. Klinkt als een klein technisch detail, toch? Maar het is eigenlijk de absolute fundering van je webprestaties. Want als je server er twee seconden over doet om te antwoorden, kan je LCP per definitie nooit onder die twee seconden uitkomen. Geen enkele afbeeldingsoptimalisatie of lazy-loading-truc gaat dat goedmaken.
De cijfers in 2026 zijn best confronterend. De mediaan mobiele TTFB ligt volgens HTTP Archive-data rond de 1,3 seconden — ruim boven Google's aanbeveling van 800 milliseconden. Tegelijkertijd halen sites met een goed geconfigureerde CDN en edge caching routinematig een TTFB onder de 100 milliseconden. Dat is een factor 10 verschil. Eerlijk gezegd is TTFB-optimalisatie daarmee een van de meest onderschatte investeringen die je kunt doen.
In eerdere artikelen hebben we INP, LCP en CLS uitgebreid behandeld — de drie officiële Core Web Vitals. TTFB is officieel geen Core Web Vital, maar het is wél de metric die alle andere metrics direct beïnvloedt. Zie het als het fundament waarop je hele prestatiestrategie rust. Als dat fundament wankel is, heeft de rest weinig zin.
De TTFB-Waterval: Vijf Fasen Ontleed
Voordat je kunt optimaliseren, moet je snappen waar de tijd precies naartoe gaat. TTFB is namelijk niet één meting — het is de som van vijf opeenvolgende fasen. En elke fase kan een bottleneck zijn, met een compleet andere oplossing.
1. DNS-Lookup
De browser moet eerst je domeinnaam vertalen naar een IP-adres via het DNS-systeem. Bij een eerste bezoek (zonder lokale cache) kost dit al gauw 20 tot 120 milliseconden, afhankelijk van je DNS-provider en hoe complex je DNS-configuratie is. Bij herhaalde bezoeken wordt het resultaat lokaal gecacht en is deze stap vrijwel gratis.
2. TCP-Verbinding
Na de DNS-lookup zet de browser een TCP-verbinding op met je server via een drieweg-handshake. De latentie hangt direct af van de fysieke afstand tussen gebruiker en server. Een bezoeker in Amsterdam die verbindt met een server in New York? Reken maar op 80 tot 100 milliseconden extra vertraging — alleen voor deze stap.
3. TLS-Onderhandeling
Vrijwel iedere site draait tegenwoordig op HTTPS, dus na TCP volgt de TLS-handshake. Met TLS 1.2 kost dat twee extra roundtrips; met TLS 1.3 is het teruggebracht tot één. Dat ene roundtrip verschil kan bij intercontinentale verbindingen makkelijk 100 milliseconden of meer schelen.
4. Serververwerking
Dit is waar de meeste ontwikkelaars zich op richten — en terecht. Hier doet de server het echte werk: routing, authenticatie, database-queries, template-rendering, API-aanroepen naar externe diensten. Bij een simpele statische pagina duurt het een paar milliseconden. Bij een dynamische pagina met meerdere database-queries? Honderden milliseconden of zelfs seconden. Dat is waar het pijn doet.
5. Contenttransfer
De eerste byte reist terug naar de browser. De snelheid hangt af van de verbindingskwaliteit en de geografische afstand. Met een CDN wordt het antwoord geserveerd vanaf een edge-server dicht bij de gebruiker, waardoor deze fase minimaal wordt.
De Waterval Meten met de Navigation Timing API
Goed, genoeg theorie. Je kunt elke fase van de TTFB-waterval exact meten in de browser met de Navigation Timing API:
const [nav] = performance.getEntriesByType('navigation');
console.table({
'DNS-lookup': `${Math.round(nav.domainLookupEnd - nav.domainLookupStart)}ms`,
'TCP-verbinding': `${Math.round(nav.connectEnd - nav.connectStart)}ms`,
'TLS-onderhandeling': `${Math.round(nav.connectEnd - nav.secureConnectionStart)}ms`,
'Serververwerking': `${Math.round(nav.responseStart - nav.requestStart)}ms`,
'Totale TTFB': `${Math.round(nav.responseStart - nav.startTime)}ms`
});Dit geeft je een overzichtelijke tabel met de exacte verdeling per fase. Draai het op je eigen site en je weet meteen waar de bottleneck zit. Is het DNS? Overweeg een snellere provider. Is het serververwerking? Dan moet je je backend onder de loep nemen.
TTFB Meten: Van Velddata tot DevTools
Net als bij de andere Core Web Vitals heb je twee perspectieven nodig: velddata van echte gebruikers én labdata voor debugging.
Velddata met de web-vitals Bibliotheek
De web-vitals JavaScript-bibliotheek van Google meet TTFB direct in de browser van je echte bezoekers:
import { onTTFB } from 'web-vitals';
onTTFB((metric) => {
console.log('TTFB:', metric.value, 'ms');
// Stuur naar je eigen analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
name: 'TTFB',
value: metric.value,
url: window.location.href,
navigationType: metric.navigationType
}),
keepalive: true
});
});Let even op het navigationType-veld — dat is een subtiel maar belangrijk detail. Een reload heeft doorgaans een lagere TTFB dan een navigate doordat de verbinding al warm is. En een back_forward navigatie is vaak het langzaamst. Door hierop te segmenteren krijg je een véél nauwkeuriger beeld van wat er werkelijk speelt.
Labdata met WebPageTest en DevTools
WebPageTest is wat mij betreft het beste gratis hulpmiddel voor dit soort analyses. Het splitst elk verzoek netjes uit in DNS, connect, SSL, send, wait en receive — precies wat je nodig hebt om te zien waar de tijd naartoe gaat. Test altijd vanuit meerdere locaties, anders krijg je een vertekend beeld van je wereldwijde TTFB.
In Chrome DevTools kun je onder het Network-tabblad op een verzoek klikken en het Timing-paneel openen. Daar vind je de volledige waterval inclusief Waiting for server response — dat is je serververwerkingstijd.
De Server-Timing API: De Blackbox Openblazen
Oké, hier wordt het echt interessant. De standaard TTFB-meting vertelt je dat je server traag is, maar niet waarom. En dat "waarom" is precies wat je nodig hebt. De Server-Timing API lost dat op door je backend de mogelijkheid te geven om interne timings mee te sturen in de HTTP-response header.
Server-Timing Headers Instellen
Op je server voeg je een Server-Timing-header toe aan je response. Hier is een voorbeeld in Node.js:
const express = require('express');
const app = express();
app.get('/api/producten', async (req, res) => {
const timings = [];
// Database-query timen
const dbStart = performance.now();
const producten = await db.query('SELECT * FROM producten WHERE actief = true');
timings.push(`db;dur=${(performance.now() - dbStart).toFixed(1)};desc="Database query"`);
// Template-rendering timen
const renderStart = performance.now();
const html = await renderTemplate('producten', { producten });
timings.push(`render;dur=${(performance.now() - renderStart).toFixed(1)};desc="Template rendering"`);
// Cache-status meesturen
timings.push('cache;desc="MISS"');
res.set('Server-Timing', timings.join(', '));
res.send(html);
});Server-Timing Uitlezen in de Browser
De timings die je server meestuurt zijn direct beschikbaar via de Performance API:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.serverTiming && entry.serverTiming.length > 0) {
console.group(`Server-Timing voor ${entry.name}`);
for (const timing of entry.serverTiming) {
console.log(
`${timing.name} (${timing.description}): ${timing.duration}ms`
);
}
console.groupEnd();
}
}
});
observer.observe({ type: 'navigation', buffered: true });In Chrome DevTools verschijnen de Server-Timing-waarden automatisch in het Timing-paneel van het Network-tabblad. Je ziet dan precies hoeveel tijd de database-query kostte, hoeveel de template-rendering, en of je cache een hit of miss was. Dat is goud waard bij het debuggen van TTFB-problemen — zeker in productie waar je niet even een profiler kunt aanzetten.
CDN en Edge Computing: TTFB Geografisch Verkleinen
Een CDN is — laten we eerlijk zijn — veruit de meest impactvolle maatregel om TTFB te verlagen. Het principe is simpel: plaats kopieën van je content op servers over de hele wereld, zodat iedere gebruiker wordt bediend door een server die fysiek dichtbij staat.
Waarom een CDN Zo Effectief Is
Een CDN pakt TTFB op drie fronten tegelijk aan. Ten eerste verkleint het de netwerklatentie voor DNS-lookups, TCP-verbindingen en TLS-handshakes doordat de edge-server dichtbij de gebruiker staat. Ten tweede kan een CDN je pagina's cachen op edge-servers, zodat het antwoord kan worden geserveerd zonder überhaupt je origin-server te raadplegen. En ten derde bieden CDN's doorgaans strak geoptimaliseerde configuraties met HTTP/3, Brotli-compressie en snelle TLS-onderhandeling.
De cijfers spreken voor zich: Europese gebruikers dicht bij de server zien een TTFB onder de 170ms, terwijl gebruikers in India 3x hogere TTFB ervaren en gebruikers in China bijna 10x hogere TTFB (1.468ms) zien. Voor internationale doelgroepen is een CDN met wereldwijde edge-locaties geen luxe — het is een noodzaak.
Tiered Caching: De Regionale Cachelayer
Bij een standaard CDN-setup haalt elke edge-server bij een cache miss de content direct op bij je origin-server. Met tiered caching voeg je daar een regionale cachelayer aan toe, tussen edge en origin. Cloudflare noemt dit "Tiered Cache", AWS CloudFront noemt het "Origin Shield", en Fastly noemt het "Shielding". Andere naam, zelfde idee.
Even een concreet voorbeeld. Stel, je origin staat in Frankfurt en een gebruiker in Sydney heeft een cache miss. Zonder tiered caching gaat het verzoek van Sydney helemaal naar Frankfurt (200ms+ latentie per richting). Met tiered caching checkt de Sydney-POP eerst een Asia-Pacific regionale cache (zo'n 40ms), en alleen bij een miss dáár gaat het door naar Frankfurt. Het resultaat: minder belasting op je origin én een flink hogere cache hit rate.
Edge Workers voor Dynamische Content
Voor statische content is CDN-caching vrij rechttoe rechtaan. Maar wat als je dynamische content hebt die per gebruiker verschilt? Dan komen edge workers in beeld — serverless functies die draaien op CDN edge-locaties, vlak bij je gebruikers.
// Cloudflare Worker voorbeeld: dynamische content op de edge
export default {
async fetch(request, env) {
const url = new URL(request.url);
const cacheKey = `page:${url.pathname}`;
// Probeer uit de edge cache te lezen
const cached = await env.KV.get(cacheKey);
if (cached) {
return new Response(cached, {
headers: {
'Content-Type': 'text/html',
'Server-Timing': 'edge;desc="KV Cache HIT";dur=1',
'Cache-Control': 'public, max-age=60'
}
});
}
// Cache miss: haal op van de origin
const originStart = performance.now();
const response = await fetch(request);
const html = await response.text();
const originDur = (performance.now() - originStart).toFixed(1);
// Sla op in de edge cache voor volgende bezoekers
await env.KV.put(cacheKey, html, { expirationTtl: 300 });
return new Response(html, {
headers: {
'Content-Type': 'text/html',
'Server-Timing': `origin;desc="Origin fetch";dur=${originDur}`,
'Cache-Control': 'public, max-age=60'
}
});
}
};Cachingstrategieën: Van Full Page Cache tot Stale-While-Revalidate
Caching is de meest directe manier om de serververwerkingsfase van TTFB te elimineren. Maar er zijn meerdere strategieën, en ze hebben elk hun eigen trade-offs.
Full Page Cache
Bij full page caching sla je de volledige HTML-response op en serveer je die bij volgende verzoeken direct — zonder dat de server ook maar iets hoeft te doen. Je TTFB kan hiermee tot 95% dalen. Het nadeel is logisch: de content is statisch totdat de cache verloopt of je 'm handmatig leegt.
Object Caching met Redis of Memcached
Kun je volledige pagina's niet cachen (bijvoorbeeld bij gepersonaliseerde content)? Dan kun je individuele database-queries en API-responses cachen in het geheugen. Redis of Memcached slaan de resultaten op in RAM, waardoor herhaalde queries microseconden in plaats van milliseconden kosten. Dat scheelt enorm.
// Node.js voorbeeld: database-query caching met Redis
const Redis = require('ioredis');
const redis = new Redis();
async function getProducten(categoryId) {
const cacheKey = `producten:${categoryId}`;
// Probeer uit de cache te lezen
const cached = await redis.get(cacheKey);
if (cached) {
return JSON.parse(cached);
}
// Cache miss: haal uit de database
const producten = await db.query(
'SELECT * FROM producten WHERE category_id = ? AND actief = true',
[categoryId]
);
// Sla 5 minuten op in Redis
await redis.set(cacheKey, JSON.stringify(producten), 'EX', 300);
return producten;
}Stale-While-Revalidate: Het Beste van Twee Werelden
Dit is naar mijn mening de meest elegante cachingstrategie voor TTFB. Het principe: de CDN serveert de gecachte (mogelijk licht verouderde) content direct aan de gebruiker, terwijl op de achtergrond een vers exemplaar wordt opgehaald. De gebruiker krijgt altijd een razendsnel antwoord, en de cache wordt asynchroon vernieuwd. Win-win.
# Nginx configuratie voor stale-while-revalidate
location / {
proxy_pass http://backend;
# CDN mag 60 seconden cachen, daarna nog 1 uur stale serveren
# terwijl op de achtergrond wordt ververst
add_header Cache-Control "public, s-maxage=60, stale-while-revalidate=3600";
# Fallback bij origin-fouten: serveer stale content
add_header Cache-Control "stale-if-error=86400";
}Eén waarschuwing wel: caching kan een trage backend maskeren. Als je origin 3 seconden nodig heeft maar de CDN steeds een gecachte kopie serveert, merk je het probleem pas als de cache verloopt tijdens een verkeerspiek (en geloof me, dat is geen prettig moment om erachter te komen). Monitor daarom altijd je origin-responstijden apart — de Server-Timing API die we eerder bespraken is daar perfect voor.
103 Early Hints: Dode Wachttijd Productief Maken
HTTP 103 Early Hints is een relatief nieuwe techniek die de manier verandert waarop we met TTFB omgaan. Het idee is slim: in plaats van te wachten tot de server de volledige response klaar heeft, stuurt de server alvast een voorlopig antwoord met hints over welke resources de browser vast kan gaan laden.
Hoe Werkt Het?
Zodra de server een verzoek ontvangt, stuurt het direct een 103-response met Link-headers die de browser vertellen welke stylesheets, fonts en afbeeldingen alvast opgehaald kunnen worden. Terwijl de server druk bezig is met database-queries en template-rendering, is de browser al aan het laden. De "wachttijd" wordt zo productieve laadtijd.
# Nginx configuratie voor 103 Early Hints
server {
listen 443 ssl;
http2 on;
location / {
# Stuur 103 Early Hints voordat de proxy reageert
add_header Link "</css/main.css>; rel=preload; as=style" early;
add_header Link "</fonts/inter.woff2>; rel=preload; as=font; crossorigin" early;
add_header Link "</img/hero.avif>; rel=preload; as=image" early;
proxy_pass http://backend;
}
}Impact op Core Web Vitals
Even een belangrijke nuance: 103 Early Hints verlaagt niet de TTFB van het document zelf. De server heeft nog steeds evenveel tijd nodig om het antwoord samen te stellen. Maar het vermindert wél drastisch de impact van een hoge TTFB op FCP en LCP, doordat de browser een voorsprong krijgt bij het laden van kritieke resources. In de praktijk kan dit honderden milliseconden van je LCP schaven.
Cloudflare genereert automatisch 103 Early Hints op basis van Link-headers en preload-tags in je HTML. Chrome, Edge, Firefox en Safari ondersteunen het allemaal. Kortom: er is eigenlijk geen goede reden om dit niet in te zetten.
TLS 1.3 en HTTP/3: Minder Roundtrips, Snellere TTFB
Protocolverbeteringen worden bij TTFB-optimalisatie nogal eens over het hoofd gezien, maar ze kunnen behoorlijk wat uitmaken — vooral voor gebruikers op mobiele netwerken met hoge latentie.
TLS 1.3: Eén Roundtrip Minder
TLS 1.3 brengt de TLS-handshake terug van twee roundtrips naar één. Op een verbinding met 100ms latentie scheelt dat gewoon 100 milliseconden. En het wordt nog beter: TLS 1.3 ondersteunt 0-RTT-resumptie voor herhaalde verbindingen, waarmee de TLS-overhead bij herbezoeken praktisch nul wordt.
Controleer of je server TLS 1.3 ondersteunt. In Nginx:
# Nginx: forceer TLS 1.3 als minimum
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# Schakel 0-RTT in voor herhaalde verbindingen
ssl_early_data on;HTTP/3 met QUIC: Verbinding en Encryptie in Eén Stap
HTTP/3 vervangt TCP+TLS door het QUIC-protocol. QUIC combineert verbindingsopbouw en encryptie in één stap, wat tot twee roundtrips kan besparen bij de eerste verbinding. Bovendien elimineert QUIC het beruchte head-of-line blocking-probleem van HTTP/2 — een verloren pakket blokkeert niet langer alle streams.
Alle grote CDN's — Cloudflare, Fastly, AWS CloudFront — ondersteunen HTTP/3. En aan de browserkant: Chrome, Firefox, Safari en Edge doen allemaal mee. Gebruik je al een CDN? Dan is HTTP/3 vaak standaard ingeschakeld of met één klik te activeren. Doe het gewoon.
Database-Optimalisatie: De Grootste Verborgen TTFB-Killer
In zo'n 40% van alle performance-audits die ik voorbij zie komen, is de serververwerkingstijd verantwoordelijk voor meer dan 60% van de totale TTFB. En die serververwerking wordt in de meeste gevallen gedomineerd door database-queries. Laten we kijken naar de meest impactvolle optimalisaties.
Indexering en Query-Optimalisatie
Een ontbrekende index op een veelgebruikte query kan het verschil zijn tussen 2ms en 2.000ms. Ja, echt. Gebruik EXPLAIN (of EXPLAIN ANALYZE in PostgreSQL) om te controleren of je queries daadwerkelijk indexen gebruiken:
-- Controleer of een query een index gebruikt
EXPLAIN ANALYZE
SELECT * FROM bestellingen
WHERE klant_id = 12345
AND status = 'verwerkt'
ORDER BY created_at DESC
LIMIT 20;
-- Voeg een samengestelde index toe als die ontbreekt
CREATE INDEX idx_bestellingen_klant_status
ON bestellingen (klant_id, status, created_at DESC);Connection Pooling
Elke database-query heeft een verbinding nodig. Het opzetten van een nieuwe verbinding kost 20 tot 50 milliseconden — elke keer weer. Met connection pooling hergebruik je bestaande verbindingen, waardoor die overhead wegvalt. Tools als PgBouncer (PostgreSQL) of ProxySQL (MySQL) zijn hier specifiek voor gebouwd en kunnen je TTFB met tientallen milliseconden verlagen.
N+1 Query-Problemen Vermijden
Een klassiek probleem dat ik veel te vaak tegenkom: je haalt 20 producten op, en voor elk product doe je een aparte query om de categorie op te halen. Dat zijn 21 queries in plaats van 1. Gebruik JOINs of batch-queries:
-- SLECHT: N+1 patroon (21 queries voor 20 producten)
SELECT * FROM producten LIMIT 20;
-- daarna per product:
SELECT * FROM categorieen WHERE id = ?;
-- GOED: één query met JOIN (1 query totaal)
SELECT p.*, c.naam AS categorie_naam
FROM producten p
JOIN categorieen c ON p.categorie_id = c.id
LIMIT 20;DNS-Optimalisatie: De Vergeten Eerste Stap
DNS-lookups worden vaak genegeerd bij TTFB-optimalisatie, maar ze kunnen zomaar 20 tot 120 milliseconden aan je TTFB toevoegen. Drie concrete dingen die je vandaag nog kunt doen:
- Gebruik een snelle DNS-provider. Premium providers zoals Cloudflare DNS (gratis!), Google Cloud DNS of AWS Route 53 bieden responstijden onder de 20ms wereldwijd. Vergelijk dat met de 50-100ms van goedkopere providers.
- Gebruik
dns-prefetchvoor externe domeinen. Laadt je pagina resources van externe domeinen (analytics, fonts, CDN's)? Laat de browser alvast de DNS-lookup doen:
<!-- DNS prefetch voor externe domeinen -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.nl">
<!-- Preconnect voor kritieke externe domeinen (DNS + TCP + TLS) -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>- Verhoog je DNS TTL-waarden. Een hogere TTL zorgt ervoor dat het DNS-resultaat langer gecacht wordt bij resolvers en in de browser. Een TTL van 3600 seconden (1 uur) of meer is voor de meeste sites prima.
Een Compleet TTFB-Monitoringscript
Tot slot een alles-in-één monitoringscript dat TTFB meet, de waterval opsplitst en Server-Timing data verwerkt. Gebruik dit als startpunt voor je eigen Real User Monitoring:
function monitorTTFB() {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
const data = {
url: entry.name,
navigationType: entry.type,
// TTFB-waterval
dns: Math.round(entry.domainLookupEnd - entry.domainLookupStart),
tcp: Math.round(entry.connectEnd - entry.connectStart),
tls: entry.secureConnectionStart > 0
? Math.round(entry.connectEnd - entry.secureConnectionStart)
: 0,
serverProcessing: Math.round(entry.responseStart - entry.requestStart),
ttfb: Math.round(entry.responseStart - entry.startTime),
// Server-Timing data (indien beschikbaar)
serverTimings: entry.serverTiming?.map((t) => ({
name: t.name,
description: t.description,
duration: Math.round(t.duration)
})) || [],
// Protocol-info
protocol: entry.nextHopProtocol // 'h2', 'h3', etc.
};
// Stuur naar je analytics-endpoint
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/ttfb', JSON.stringify(data));
}
}
});
observer.observe({ type: 'navigation', buffered: true });
}
// Start monitoring zodra het document geladen is
if (document.readyState === 'complete') {
monitorTTFB();
} else {
window.addEventListener('load', monitorTTFB);
}Dit script geeft je per paginabezoek een compleet plaatje: hoeveel tijd ging naar DNS, hoeveel naar TLS, hoeveel naar serververwerking, welk protocol werd gebruikt, en wat de Server-Timing data onthult over je backend. Implementeer het, en je hebt een solide basis om TTFB-problemen snel te identificeren en aan te pakken.
Veelgestelde Vragen
Wat is een goede TTFB-waarde in 2026?
Google hanteert 800 milliseconden als drempelwaarde voor "goed" en 1.800 milliseconden als "slecht". Maar in de praktijk zou je moeten mikken op een TTFB onder de 200 milliseconden voor statische content en onder de 500 milliseconden voor dynamische content. Sites met een goed geconfigureerde CDN halen routinematig onder de 100 milliseconden voor gecachte pagina's.
Is TTFB een Google-rankingfactor?
Niet direct — TTFB is geen officiële Core Web Vital. Maar het beïnvloedt LCP en FCP wél direct, en die zijn rankingfactoren. Een hoge TTFB maakt het wiskundig onmogelijk om goede LCP-scores te halen, waardoor het indirect je zoekpositie beïnvloedt. En na de Google core update van maart 2026 is het gewicht van prestatie-signalen in het ranking-algoritme alleen maar sterker geworden.
Wat is het verschil tussen TTFB en servertijd?
TTFB omvat de volledige keten: DNS-lookup, TCP-verbinding, TLS-onderhandeling, serververwerking én de terugreis van de eerste byte. Servertijd (ook wel "server response time" of "waiting time") is alleen de verwerkingstijd op de server zelf. Servertijd is dus een onderdeel van TTFB. Met de Server-Timing API kun je die servertijd verder opsplitsen in database, rendering en andere componenten — superhandig voor debugging.
Kan 103 Early Hints mijn TTFB verbeteren?
Technisch gezien niet. 103 Early Hints verlaagt niet de TTFB van het document — de server heeft nog steeds evenveel verwerkingstijd nodig. Maar het vermindert de negatieve impact van een hoge TTFB op andere metrics. Doordat de browser alvast kritieke resources laadt tijdens het wachten, worden FCP en LCP aanzienlijk sneller. Het is dus geen TTFB-optimalisatie in strikte zin, maar het verzacht de gevolgen van een hoge TTFB behoorlijk.
Waarom is mijn TTFB op mobiel zo veel slechter dan op desktop?
Mobiele netwerken hebben nu eenmaal hogere latentie dan vaste verbindingen. Elke roundtrip (DNS, TCP, TLS) duurt langer, waardoor de cumulatieve TTFB snel oploopt. Daarnaast is de DNS-cache op mobiele apparaten vaak kleiner en worden verbindingen vaker verbroken bij netwerkovergangen (denk aan: wifi naar 4G en terug). De oplossing is een combinatie: een CDN met edge-locaties dicht bij je gebruikers, TLS 1.3 voor minder roundtrips, HTTP/3 voor snellere verbindingsopbouw, en preconnect-hints voor kritieke externe domeinen.