Wat zijn HTTP/2 en HTTP/3? Een praktische gids voor WordPress-sites

HTTP/2 en HTTP/3 zijn de twee huidige versies van het Hypertext Transfer Protocol, de taal die browsers gebruiken om pagina's op te vragen bij webservers. HTTP/2 werd in 2015 gestandaardiseerd en wordt door 100% van de moderne browsers ondersteund. HTTP/3, in 2022 gefinaliseerd als RFC 9114, wordt sinds 2024 door alle grote browsers ondersteund. Beide zijn naadloze upgrades ten opzichte van HTTP/1.1: zelfde URLs, zelfde HTML, maar aanzienlijk snellere paginaladingen, vooral op mobiele netwerken en verbindingen met hoge latentie.

Snel antwoord: welke versie zou mijn WordPress-site moeten gebruiken?

In 2026 is het juiste antwoord "HTTP/3 met HTTP/2-fallback". Elke browser onderhandelt automatisch de hoogste versie die beide partijen ondersteunen, je hoeft dus niet te kiezen. Als je server HTTP/3 spreekt, gebruiken moderne browsers HTTP/3; oudere browsers vallen terug op HTTP/2; zeer oude clients op HTTP/1.1. Er is geen scenario waarin HTTP/2 of HTTP/3 trager is dan HTTP/1.1 voor een echte WordPress-pagina, dus de enige vraag is of je hostingstack het ondersteunt.

Welk probleem lost HTTP/2 op ten opzichte van HTTP/1.1?

HTTP/1.1, het protocol dat het web droeg van 1997 tot 2015, heeft één fatale fout op een moderne site: het opent één TCP-verbinding per resource, en slechts zes parallel per domein. Een typische WordPress-pagina laadt 50 tot 150 resources (CSS, JS, afbeeldingen, fonts, trackingscripts). Onder HTTP/1.1 serialiseren die 100+ requests door een wachtrij van zes verbindingen, elk wachtend tot de vorige klaar is. De browser zit letterlijk stil te wachten tot er plekken vrijkomen.

HTTP/2 lost dit op met drie veranderingen:

Multiplexing. Eén enkele TCP-verbinding draagt een onbeperkt aantal parallelle request/response-paren (streams genoemd). Alle 150 resources reizen over één verbinding, in elkaar gevlochten.
Header-compressie (HPACK). HTTP-headers (cookies, User-Agent, referer) tellen vaak op tot meerdere KB per request. HPACK comprimeert ze en onthoudt herhaalde headers, waardoor overhead per request van kilobytes naar bytes daalt.
Binaire framing. HTTP/1.1 is tekstgebaseerd en dubbelzinnig te parsen. HTTP/2 gebruikt een binair frame-formaat dat sneller te verwerken is voor servers en proxies, en elimineert een hele klasse van smuggling- en parsingaanvallen.

Netto-effect: een WordPress-pagina die in 4 seconden laadt over HTTP/1.1 laadt doorgaans in 1,5 tot 2,5 seconden over HTTP/2, op dezelfde server. De verbetering is groter op mobiele netwerken omdat de verbindingsopzet-overhead over alle requests wordt geamortiseerd.

Wat voegt HTTP/3 toe bovenop HTTP/2?

HTTP/3 behoudt alles wat HTTP/2 introduceerde (multiplexing, header-compressie, binaire framing) maar vervangt het onderliggende transport. In plaats van TCP draait HTTP/3 op QUIC, een transportprotocol gebouwd op UDP. Klinkt als implementatiedetail maar lost drie echte performance-problemen op:

Head-of-line blocking op TCP-niveau. HTTP/2 multiplext streams over één TCP-verbinding, maar TCP zelf levert pakketten in volgorde. Als één pakket wegvalt, blokkeren alle streams op die verbinding tot de hertransmissie aankomt. QUIC handelt pakketverlies per stream af, dus één gemist pakket beïnvloedt alleen de stream waar het bij hoort.
Sneller verbindingsopzet. Een HTTPS-verbinding over TCP vereist drie round trips (TCP-handshake, dan TLS-handshake). QUIC combineert ze in één round trip voor nieuwe verbindingen, en nul round trips voor herhaalverbindingen binnen enkele minuten (0-RTT genoemd). Op een mobiele verbinding met 100ms latentie bespaart dit 200-300ms voordat de eerste byte content überhaupt begint te laden.
Connection migration. QUIC-verbindingen worden geïdentificeerd door een connection ID, niet door IP + poort. Wanneer een telefoon overschakelt van Wi-Fi naar mobiel, overleeft de QUIC-verbinding. TCP-verbindingen zouden opnieuw moeten verbinden.

Werkelijke winst bovenop HTTP/2: doorgaans 5-15% sneller voor eerste paginaladingen, meer op verliesgevoelige mobiele netwerken, minder op een stabiele kabelverbinding.

Hoe controleer ik welke HTTP-versie mijn WordPress-site momenteel gebruikt?

Vier betrouwbare methoden, van snelst naar meest gezaghebbend:

InspectWP-rapport. De Performance-sectie van elk InspectWP-rapport vermeldt de voor het hoofddocument onderhandelde HTTP-versie. Eén regel, geen setup.
Chrome DevTools. Open DevTools (F12), tabblad Network, herlaad de pagina, rechtsklik op een kolomkop en schakel "Protocol" in. De kolom toont h2 voor HTTP/2 en h3 voor HTTP/3 (in sommige Chrome-versies ook http/3).
Commandoregel met curl. Voer curl -I --http2 https://jouwsite.com uit voor HTTP/2 of curl -I --http3 https://jouwsite.com voor HTTP/3 (curl 7.66+ vereist). De responsregel toont HTTP/2 200 of HTTP/3 200.
Openbare testtools. https://http3check.net test specifiek HTTP/3-ondersteuning. https://tools.keycdn.com/http2-test test HTTP/2-ondersteuning. Beide retourneren de onderhandelde versie en de Alt-Svc-header (die HTTP/3-ondersteuning adverteert).

Eén valkuil: een site kan HTTP/3 adverteren in zijn Alt-Svc-header zonder dat HTTP/3 daadwerkelijk werkt. De header zegt tegen de browser "probeer volgende keer HTTP/3 op UDP-poort 443", maar als UDP ergens onderweg geblokkeerd is, valt de browser stilzwijgend terug op HTTP/2. Verifieer altijd met een echte request, niet alleen via de Alt-Svc-header.

Hoe schakel ik HTTP/2 of HTTP/3 in op een WordPress-site?

HTTP-versies worden op webserverniveau onderhandeld. WordPress zelf heeft hier niets mee te maken; de keuze ligt tussen je hostingstack en de browser. Drie scenario's dekken bijna alle sites:

Scenario 1: managed WordPress-hosting

Bijna elke managed WordPress-host (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) levert sinds 2018 HTTP/2 standaard. HTTP/3-ondersteuning is nu wijdverspreid maar niet universeel in 2026. Kinsta, Cloudways, SiteGround, Raidboxes en Pressable hebben HTTP/3 standaard ingeschakeld. WP Engine biedt het als toggle. Staat je host niet in deze lijst, vraag de support; meestal een wijziging met één klik.

Scenario 2: shared hosting met cPanel of Plesk

cPanel-hosts (IONOS, Hostinger, veel resellers) leveren doorgaans HTTP/2 standaard en HTTP/3 op nieuwere accounts. Controleer door EasyApache 4 in te schakelen met de module mod_http2 als die nog niet aanwezig is. HTTP/3 in Apache vereist de module mod_http3 die nog als experimenteel geldt. De pragmatische route op shared hosting is om Cloudflare ervoor te zetten (gratis tier voldoet) en Cloudflare de HTTP/3-terminatie te laten regelen, hun standaard sinds 2019.

Scenario 3: zelfbeheerde VPS of dedicated server

De configuratie hangt af van je webserver:

nginx. HTTP/2 vereist nginx 1.9.5+ en de http2-directive op je listen-regel: listen 443 ssl http2;. HTTP/3 vereist nginx 1.25+ gecompileerd met QUIC-ondersteuning: listen 443 quic reuseport; listen 443 ssl; plus add_header Alt-Svc 'h3=":443"; ma=86400';. De reuseport-vlag is kritisch of HTTP/3 start stilzwijgend niet.
Apache. HTTP/2 vereist ingeschakelde mod_http2 en de directive Protocols h2 h2c http/1.1 in je virtuele host. HTTP/3 in Apache is nog experimenteel; de meeste Apache-productie-setups blijven bij HTTP/2 en zetten nginx, Caddy of Cloudflare ervoor voor HTTP/3.
Caddy. HTTP/3 is standaard ingeschakeld sinds Caddy 2.6. Niks te configureren; als HTTPS werkt, werkt HTTP/3.
LiteSpeed en OpenLiteSpeed. Beide leveren HTTP/3 standaard. Een reden waarom LiteSpeed marktaandeel heeft gewonnen in WordPress-hosting.

Eén vereiste die bij zelfbeheerde setups vaak wordt vergeten: HTTP/3 vereist UDP-poort 443 open in je firewall. Veel standaard serverconfiguraties openen alleen TCP 443. Voer op Ubuntu sudo ufw allow 443/udp uit, of het equivalent voor jouw firewall-stack.

Welke rol spelen Cloudflare en andere CDNs?

Een CDN voor je origin-server termineert doorgaans het moderne protocol aan de edge, en praat dan met je origin via HTTP/1.1 of HTTP/2. Vanuit het oogpunt van de bezoeker loopt de verbinding naar het edge-knooppunt van het CDN (vaak 20-50ms verderop) over HTTP/3, snel en modern. De link van CDN naar origin gebeurt server-naar-server in datacenternetwerken waar het protocol veel minder uitmaakt. Daarom geeft Cloudflare voor een shared host die alleen HTTP/1.1 spreekt toch het grootste deel van de snelheidswinst. De bezoeker raakt je origin nooit direct aan.

De catch: als je origin een cache-busting-header teruggeeft (no-cache, no-store) of je content niet cachebaar is (ingelogde WordPress-pagina's, WooCommerce-winkelwagen), moet het CDN bij elke request naar de origin, en de trage origin-naar-CDN-hop wordt de bottleneck. Voor die gevallen telt het protocol op de origin nog steeds.

Veelvoorkomende fouten en hoe ze te vermijden

HTTP/2 behandelen als wondermiddel voor trage sites. HTTP/2 lost verbindingsoverhead op. Het lost geen traag PHP op, geen ongeoptimaliseerde queries, geen 5MB hero-afbeeldingen, geen render-blokkerende JavaScript. Als je TTFB (time to first byte) 2 seconden is, bespaart overschakelen op HTTP/3 je 200ms. De andere 1800ms zijn nog steeds PHP en database.
Vergeten HTTP/1.1 ingeschakeld te houden. Zoekmachine-crawlers, monitoringtools en oude clientbibliotheken spreken soms alleen HTTP/1.1. HTTP/1.1 volledig uitschakelen breekt ze. Moderne webservers onderhandelen automatisch de hoogste wederzijds ondersteunde versie; houd alle drie (h3, h2, http/1.1) ingeschakeld.
Assets concateneren en inlinen uit HTTP/1.1-gewoonte. Onder HTTP/1.1 was 30 CSS-bestanden combineren tot 1 een grote winst vanwege de verbindingslimiet. Onder HTTP/2 en HTTP/3 verliest die optimalisatie aan belang en kan zelfs schaden (één grote bundle invalideert de cache bij elke wijziging; 30 kleine bestanden invalideren alleen de gewijzigde). De meeste WordPress-performanceplugins zetten standaard nog steeds "alles combineren" omdat gebruikers dat verwachten, maar dat is in 2026 niet meer de juiste default.
Aannemen dat Alt-Svc betekent dat HTTP/3 werkt. De header adverteert HTTP/3-ondersteuning; hij garandeert niet dat de verbinding daadwerkelijk tot stand komt. Verifieer altijd met curl of DevTools.
UDP blokkeren bij de firewall. Een veelvoorkomende oorzaak waarom HTTP/3 stilzwijgend niet werkt. Controleer zowel de serverfirewall als de netwerkfirewall (security group bij cloudprovider, ISP-filtering op consumentverbindingen).

HTTP/2, HTTP/3 en Core Web Vitals

Google's Core Web Vitals meten Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Van de drie wordt LCP het sterkst beïnvloed door de HTTP-versie. Het LCP-element (meestal de hero-afbeelding of het grootste blok boven de vouw) moet volledig gedownload zijn voordat LCP kan worden gerapporteerd, en downloadsnelheid is precies wat HTTP/2 en HTTP/3 verbeteren. Sites die van HTTP/1.1 naar HTTP/2 verschuiven, zien LCP gemiddeld met 300-800ms dalen. De sprong van HTTP/2 naar HTTP/3 is kleiner, doorgaans 50-200ms, maar op mobiele netwerken met pakketverlies kan deze groter zijn.

Wat InspectWP controleert

De Performance-sectie van elk InspectWP-rapport toont welke HTTP-versie werd onderhandeld voor het hoofddocument, plus content-encoding (gzip, Brotli) en totale HTML-grootte. Als je site in 2026 nog op HTTP/1.1 draait, markeert het rapport dat als waarschuwing, omdat het een van de meest impactvolle, minst inspannende performance-winsten is die beschikbaar zijn, meestal één schakelaar in het hostingpaneel. Zit je op HTTP/2 maar niet op HTTP/3, dan verschijnt dat als informatief; HTTP/3 is de moderne default maar HTTP/2 is nog volledig acceptabel. De versie die je browser ziet is de versie die je bezoekers krijgen, dus het rapport weerspiegelt echte performance, geen theoretische configuratie.