Snelheid is geen luxe meer - het is een rankingfactor, een conversiefactor en voor veel bezoekers het verschil tussen blijven en wegklikken. Als je al bezig bent met WordPress performance-optimalisatie, heb je waarschijnlijk gewerkt aan caching, database-tuning en image optimization. Maar er is een fundamentelere laag die vaak over het hoofd wordt gezien: het protocol waarmee je site wordt uitgeleverd. HTTP/3 belooft snellere verbindingen, minder latency en betere prestaties op mobiele netwerken. Maar wat levert het concreet op voor WordPress?
Wat is HTTP/3 en waarom bestaat het?
HTTP/3 is de opvolger van HTTP/2 en de derde grote versie van het protocol dat het web aandrijft. Het grootste verschil zit niet in hoe data wordt gestructureerd, maar in hoe die data wordt verstuurd. Waar HTTP/1.1 en HTTP/2 draaien op TCP (Transmission Control Protocol), maakt HTTP/3 gebruik van QUIC - een transportprotocol dat oorspronkelijk door Google is ontwikkeld.
TCP heeft decennialang goed gewerkt, maar heeft een fundamenteel probleem: het is ontworpen in een tijd waarin verbindingen stabiel en bedraad waren. Bij elke nieuwe verbinding is er een handshake nodig, en bij versleutelde verbindingen (TLS) komt daar nog een extra handshake bovenop. Dat kost tijd - en op mobiele netwerken met wisselende verbindingen tikt dat flink aan.
QUIC lost dit op door de transport- en versleutelingshandshake samen te voegen. Het resultaat: minder roundtrips voordat de eerste byte data wordt verstuurd, oftewel een lagere Time to First Byte (TTFB).
HTTP/2 vs HTTP/3: de belangrijkste verschillen
Om te begrijpen wat HTTP/3 beter doet, helpt het om te zien waar HTTP/2 tekortschiet.
Head-of-line blocking
HTTP/2 introduceerde multiplexing: meerdere requests over één TCP-verbinding. Dat was een enorme verbetering ten opzichte van HTTP/1.1, maar het creëerde een nieuw probleem. Als één pakketje in de TCP-stream verloren gaat, moet de hele verbinding wachten tot dat pakketje opnieuw is verstuurd. Dit heet head-of-line blocking.
HTTP/3 lost dit op doordat QUIC elke stream onafhankelijk behandelt. Een verloren pakket in stream A blokkeert stream B niet. Voor WordPress-sites die veel assets laden - CSS, JavaScript, fonts, afbeeldingen - maakt dat een merkbaar verschil.
Verbindingsopbouw
Een typische HTTP/2-verbinding met TLS 1.2 vereist twee tot drie roundtrips voordat data kan stromen. HTTP/3 met QUIC reduceert dit tot één roundtrip, of zelfs nul roundtrips bij een herhaald bezoek (0-RTT). Voor terugkerende bezoekers op je WordPress-site betekent dit dat de verbinding vrijwel direct staat.
Verbindingsmigratie
Zit je in de trein en wissel je van zendmast? Bij TCP betekent dat een nieuwe verbinding. QUIC ondersteunt verbindingsmigratie: de verbinding blijft bestaan, ook als het onderliggende netwerk verandert. Voor mobiele bezoekers - en dat is inmiddels het merendeel - is dat een groot voordeel.
| Eigenschap | HTTP/2 | HTTP/3 |
|---|---|---|
| Transportlaag | TCP | QUIC (UDP) |
| Handshake roundtrips | 2-3 | 1 (of 0 bij herbezoek) |
| Head-of-line blocking | Ja (op TCP-niveau) | Nee (per stream) |
| Verbindingsmigratie | Nee | Ja |
| Versleuteling | Optioneel (TLS apart) | Altijd ingebouwd |
Wat levert HTTP/3 concreet op voor WordPress?
De theorie klinkt veelbelovend, maar wat merk je er in de praktijk van? Dat hangt af van je situatie.
Lagere TTFB
De snellere verbindingsopbouw vertaalt zich direct in een lagere TTFB. Als je al bottlenecks meet en monitort, weet je dat TTFB een van de eerste metrics is die je moet optimaliseren. HTTP/3 pakt dit aan op protocolniveau - iets wat geen plugin of theme-aanpassing kan doen.
Het effect is het grootst voor bezoekers die fysiek ver van je server zitten. Elke roundtrip die je bespaart, bespaart ook de latency van die afstand. In combinatie met een CDN zoals Cloudflare worden die voordelen nog verder uitvergroot.
Betere mobiele prestaties
Mobiele verbindingen zijn inherent minder stabiel dan vaste verbindingen. Pakketverlies is normaal, en netwerkovergangen gebeuren constant. HTTP/3 is hier specifiek voor ontworpen. De onafhankelijke streams en verbindingsmigratie zorgen ervoor dat je WordPress-site stabieler laadt op telefoons en tablets.
Bedenk dat Google's Core Web Vitals worden gemeten op basis van echte gebruikerservaringen - en een groot deel van die gebruikers zit op mobiel. Een betere mobiele ervaring vertaalt zich dus ook in betere SEO-scores.
Snellere asset-levering
Een gemiddelde WordPress-pagina laadt tientallen assets: stylesheets, scripts, fonts, afbeeldingen. Bij HTTP/2 kunnen die allemaal vast komen te zitten door één verloren pakket. HTTP/3 elimineert dat risico. In combinatie met image optimization en goed geconfigureerde full page caching vormt HTTP/3 een extra laag in je performance-stack.
Wanneer merk je weinig verschil?
Eerlijkheid gebiedt te zeggen: niet elke site zal een dramatisch verschil merken. Als je bezoekers voornamelijk op snelle, stabiele verbindingen zitten (denk aan een intern bedrijfsnetwerk) en je server dichtbij staat, is het voordeel klein. Ook als je TTFB al extreem laag is dankzij Redis caching en een goed getunede PHP-FPM configuratie, zal de winst marginaal zijn.
HTTP/3 is geen wondermiddel. Het vervangt geen goede serverarchitectuur of slimme caching. Het is een aanvulling - maar wel een waardevolle.
HTTP/3 activeren voor je WordPress-site
Het goede nieuws: je hoeft niets aan WordPress zelf te veranderen. HTTP/3 wordt afgehandeld op server- of CDN-niveau. Hier zijn de meest gangbare opties.
Via Cloudflare
Als je Cloudflare gebruikt als CDN - en dat raden we aan voor de meeste WordPress-setups - is HTTP/3 activeren eenvoudig:
- Log in op je Cloudflare-dashboard
- Ga naar Speed → Optimization → Protocol Optimization
- Schakel HTTP/3 (with QUIC) in
Cloudflare handelt de QUIC-verbinding af tussen de bezoeker en het Cloudflare-netwerk. De verbinding tussen Cloudflare en je origin-server blijft HTTP/2 of HTTP/1.1 - maar dat is prima, want het grootste voordeel zit in de last mile naar de bezoeker.
Via je webserver
Wil je HTTP/3 direct op je server aanbieden, dan heb je iets meer werk. NGINX ondersteunt HTTP/3 sinds versie 1.25.0 (experimenteel) en stabiel vanaf recente builds. LiteSpeed ondersteunt het out-of-the-box.
Voor NGINX heb je een build nodig met de --with-http_v3_module flag en een TLS-bibliotheek die QUIC ondersteunt (zoals BoringSSL of de nieuwere OpenSSL-versies). De configuratie ziet er dan ongeveer zo uit:
server {
listen 443 quic reuseport;
listen 443 ssl;
ssl_certificate /pad/naar/certificaat.pem;
ssl_certificate_key /pad/naar/key.pem;
add_header Alt-Svc 'h3=":443"; ma=86400';
}
De Alt-Svc header vertelt de browser dat HTTP/3 beschikbaar is. Bij het eerste bezoek zal de browser HTTP/2 gebruiken en daarna overschakelen naar HTTP/3.
Via managed hosting
Steeds meer managed WordPress-hosters ondersteunen HTTP/3, vaak via hun eigen CDN-laag. Controleer bij je hostingprovider of het beschikbaar is. Als je werkt met een multi-server setup, zorg er dan voor dat de load balancer ook QUIC-verkeer (UDP poort 443) doorlaat.
HTTP/3 verifiëren en testen
Na het activeren wil je natuurlijk controleren of het werkt.
Chrome DevTools
Open Chrome DevTools (F12), ga naar het Network-tabblad, klik met de rechtermuisknop op de kolomheaders en voeg Protocol toe. Herlaad de pagina. Als je h3 ziet bij de requests, werkt HTTP/3.
Online tools
Gebruik https://http3check.net om snel te controleren of je domein HTTP/3 ondersteunt. De tool test of de Alt-Svc header correct wordt verstuurd en of de QUIC-verbinding lukt.
Performance meten
Meet je Core Web Vitals voor en na het activeren van HTTP/3. Gebruik Google PageSpeed Insights voor lab-data en het Chrome UX Report (CrUX) voor velddata. Let vooral op:
- TTFB: zou moeten dalen, vooral voor mobiel
- LCP: kan verbeteren door snellere asset-levering
- FCP: profiteert van de snellere verbindingsopbouw
HTTP/3 in de context van je performance-stack
HTTP/3 staat niet op zichzelf. Het is één onderdeel van een complete performance-strategie. Zie het als een laag in je stack:
- Serverlaag: PHP-FPM tuning, database-optimalisatie
- Applicatielaag: query-optimalisatie, plugin-audit
- Cachinglaag: Object caching met Redis, full page caching
- Leveringslaag: CDN, image optimization, HTTP/3
Elke laag bouwt voort op de vorige. HTTP/3 optimaliseren heeft weinig zin als je server 2 seconden nodig heeft om een pagina te genereren. Begin bij de basis en werk je omhoog.
Browserondersteuning en valkuilen
HTTP/3 wordt breed ondersteund door moderne browsers. Chrome, Firefox, Edge en Safari ondersteunen het allemaal. Maar er zijn een paar aandachtspunten.
Firewalls en UDP
QUIC draait op UDP in plaats van TCP. Sommige bedrijfsnetwerken en firewalls blokkeren UDP-verkeer op poort 443. In dat geval valt de browser automatisch terug op HTTP/2 - er is dus geen risico op onbereikbaarheid. Maar het betekent wel dat een deel van je bezoekers niet van HTTP/3 profiteert.
Geen server push
HTTP/2 introduceerde server push, waarmee de server proactief resources kon sturen. HTTP/3 ondersteunt dit niet meer, en dat is geen gemis - in de praktijk bleek server push zelden effectief en veroorzaakte het vaak meer overhead dan winst. Moderne alternatieven zoals 103 Early Hints bieden een betere aanpak.
Monitoring
Zorg dat je monitoring en logging correct zijn geconfigureerd. QUIC-verbindingen verschijnen anders in serverlogboeken dan TCP-verbindingen. Als je performance bottlenecks meet, controleer dan dat je tools QUIC-verkeer correct registreren.
Veelgestelde vragen
Wat is HTTP/3?
HTTP/3 is de nieuwste versie van het Hypertext Transfer Protocol. Het gebruikt QUIC in plaats van TCP als transportlaag, waardoor verbindingen sneller worden opgezet en data betrouwbaarder wordt verstuurd - vooral op instabiele netwerken.
Maakt HTTP/3 mijn WordPress-site sneller?
Ja, in de meeste gevallen wel. HTTP/3 vermindert verbindingsopbouwtijd en lost het head-of-line blocking probleem op. Vooral mobiele bezoekers en gebruikers op grotere afstand merken het verschil.
Moet ik mijn WordPress-site aanpassen voor HTTP/3?
Nee, WordPress zelf hoeft niet aangepast te worden. HTTP/3 wordt afgehandeld op server- en CDN-niveau. Je hoeft alleen te zorgen dat je hosting of CDN-provider het ondersteunt.
Ondersteunt Cloudflare HTTP/3 voor WordPress?
Ja. Cloudflare biedt HTTP/3-ondersteuning aan die je met één klik kunt activeren in het dashboard. In combinatie met WordPress is dit een van de eenvoudigste manieren om HTTP/3 in te schakelen.
Kan ik controleren of mijn site HTTP/3 gebruikt?
Ja. Open Chrome DevTools, ga naar het Network-tabblad en voeg de kolom 'Protocol' toe. Als je h3 ziet staan bij de requests, gebruikt je site HTTP/3. Je kunt ook online tools zoals http3check.net gebruiken.
Conclusie
HTTP/3 is geen revolutie die je WordPress-site van de ene op de andere dag twee keer zo snel maakt. Het is een evolutie - een slimmere manier om data te transporteren die vooral op mobiele en instabiele verbindingen merkbare voordelen biedt. De drempel om het te activeren is laag, zeker als je al een CDN als Cloudflare gebruikt.
Als je serieus bezig bent met WordPress-performance, hoort HTTP/3 in je toolkit. Niet als eerste stap - begin bij je server- en applicatielaag - maar als een waardevolle aanvulling die het verschil kan maken voor je bezoekers en je zoekposities.