Snelheidsadvies gaat meestal over dingen die u zelf in de hand hebt: kleinere afbeeldingen, minder plugins, betere caching. Maar er is een laag onder dat alles die net zo veel uitmaakt en waar u nauwelijks over leest, omdat u er als websitebeheerder niets aan kunt sleutelen. Het gaat om het protocol waarmee uw server en de browser van de bezoeker met elkaar praten.
De verschillen tussen HTTP/1.1, HTTP/2 en het nieuwere HTTP/3 zijn groot, vooral op mobiel. Als u weet wat u ondersteunt, weet u ook of bepaalde adviezen op internet nog voor u gelden of dat u ze juist beter kunt negeren. Dit artikel legt uit wat er verandert, hoe u het controleert en wat u ermee doet.
Waarom het protocol uitmaakt
Een gemiddelde WordPress-pagina bestaat niet uit één bestand, maar uit vijftig tot honderdvijftig losse onderdelen: het HTML-document, een paar stijlbestanden, wat scripts, lettertypen en tientallen afbeeldingen. Elk onderdeel moet apart worden opgehaald.
Onder HTTP/1.1, het protocol uit de jaren negentig, kon een browser maar een handjevol bestanden tegelijk ophalen per verbinding, in de volgorde waarin ze waren aangevraagd. Bleef er één hangen, dan stond de rest te wachten. Dat heet blokkeren aan de kop van de rij, en het is de reden dat websites vroeger zo traag aanvoelden ondanks een snelle verbinding.
HTTP/2 loste dat op door meerdere bestanden door één verbinding te sturen, tegelijk en in willekeurige volgorde. Bovendien worden de kopgegevens gecomprimeerd, wat bij honderd verzoeken zomaar tientallen kilobytes scheelt. Voor een WordPress-site met veel losse bestanden is dat een merkbare verbetering, zonder dat u iets aanpast.
Wat HTTP/3 daar bovenop doet
HTTP/2 loste het blokkeren op HTTP-niveau op, maar niet op het niveau eronder. Alles liep nog steeds over TCP, en als daar één pakketje verloren gaat, wacht de hele verbinding tot het opnieuw is verstuurd. Ook de bestanden die allang waren aangekomen.
HTTP/3 verlaat TCP en gebruikt QUIC, een protocol dat op UDP is gebouwd. Een verloren pakketje houdt daar alleen zijn eigen stroom op, niet de rest. Daarnaast is het opzetten van een verbinding sneller: waar TCP en TLS samen meerdere heen-en-weertjes nodig hebben, doet QUIC het in één, en bij een terugkerende bezoeker soms in nul.
Waar merkt u dat? Vooral bij mobiele bezoekers en bij mindere verbindingen. Op glasvezel in een stil huis is het verschil klein. In de trein tussen Utrecht en Zwolle, of op een druk 4G-netwerk, kan het schelen in halve seconden. Nog een voordeel: QUIC overleeft een netwerkwissel. Loopt een bezoeker van wifi naar mobiel, dan blijft de verbinding staan in plaats van opnieuw te beginnen.
Hoe u controleert wat u hebt
Dit kost u twee minuten en vraagt geen technische kennis.
- Open uw website in Chrome of Edge en druk op F12.
- Ga naar het tabblad Netwerk en ververs de pagina.
- Klik met de rechtermuisknop op de kolomkoppen en zet de kolom Protocol aan.
- Kijk wat er staat: http/1.1, h2 of h3.
Ziet u overal http/1.1, dan loopt u achter en is dat een gesprek met uw hostingpartij waard. Ziet u h2, dan zit u goed en is HTTP/3 een verbetering in de marge. Ziet u h3, dan bent u bij de tijd.
Let op een detail: het protocol kan per bestand verschillen. Uw eigen server doet misschien h2, terwijl een lettertype dat u van een externe dienst haalt over h3 binnenkomt, of andersom. Ook geldt: HTTP/2 en HTTP/3 vereisen allebei een geldig beveiligingscertificaat. Zonder https krijgt u ze sowieso niet.
Advies dat verouderd is
Dit is voor de dagelijkse praktijk het belangrijkste deel. Een flink deel van het snelheidsadvies dat u online tegenkomt, stamt uit het tijdperk van HTTP/1.1 en kan onder HTTP/2 of HTTP/3 juist schadelijk zijn.
- CSS- en JavaScript-bestanden samenvoegen. Vroeger zinvol, omdat elk extra verzoek duur was. Nu maakt u er één groot bestand van dat bij elke wijziging volledig opnieuw opgehaald moet worden, terwijl kleine losse bestanden prima parallel binnenkomen en beter cachebaar zijn.
- Afbeeldingen samenvoegen tot één sprite. Zelfde verhaal. Extra werk, weinig winst, en lastig te onderhouden.
- Bestanden over meerdere subdomeinen verdelen. Dit omzeilde de limiet op gelijktijdige verbindingen van HTTP/1.1. Onder HTTP/2 kost het juist tijd, want elk extra domein vraagt een eigen verbinding en certificaatcontrole.
- Server push. Even de belofte van HTTP/2, inmiddels uit Chrome verwijderd. Gebruik in plaats daarvan een preload-verwijzing voor het handjevol bestanden dat echt vooraan moet.
Draait uw site nog op HTTP/1.1 en past u tegelijkertijd al deze moderne adviezen toe, dan werkt u zichzelf tegen. En andersom net zo goed. Als u meerdere plugins hebt draaien die aan combineren en samenvoegen doen, is ons artikel over het stapelen van optimalisatieplugins de moeite waard.
Wat u aan uw hostingpartij vraagt
U kunt HTTP/3 niet zelf aanzetten in WordPress. Het is een serverinstelling. Wel kunt u er gericht naar vragen, en dat gesprek verloopt beter met de juiste woorden.
- Ondersteunt u HTTP/2 op alle pakketten, of alleen op de duurdere?
- Is HTTP/3 met QUIC beschikbaar, en zo ja, moet ik het zelf aanzetten?
- Welke webserver draait er, en welke PHP-versie?
- Wordt er een netwerkdienst voorgeschakeld die dit eventueel afhandelt?
Dat laatste is een praktische omweg. Gebruikt u een netwerk zoals Cloudflare of een vergelijkbare dienst voor uw site, dan praat de bezoeker met dat netwerk en niet rechtstreeks met uw server. Ondersteunt dat netwerk HTTP/3, dan profiteert uw bezoeker daarvan, ook als uw eigen server nog HTTP/1.1 spreekt. Meer daarover leest u in ons stuk over een CDN voor WordPress.
Verwacht geen wonderen
Eerlijk blijven: het protocol is niet uw grootste probleem. Als uw server anderhalve seconde nodig heeft voordat er iets vertrekt, of als uw homepage acht megabyte aan ongecomprimeerde foto’s bevat, dan verandert HTTP/3 daar weinig aan. Het protocol maakt het transport efficiënter, niet de vracht lichter.
In de praktijk zien wij bij de overstap van HTTP/1.1 naar HTTP/2 een merkbare verbetering, vooral bij beeldrijke sites. Van HTTP/2 naar HTTP/3 is de winst kleiner en vooral zichtbaar bij mobiele bezoekers. Het is dus geen reden om te verhuizen, maar wel een signaal: een hostingpartij die in 2026 nog geen HTTP/2 aanbiedt, loopt waarschijnlijk op meer punten achter.
Een voorbeeld
Een architectenbureau uit Nijmegen had een portfoliosite met veel grote foto’s. De cijfers waren op desktop redelijk en op mobiel slecht. Er was al veel aan afbeeldingen gedaan zonder dat het echt hielp.
Bij het meekijken bleek het protocol op http/1.1 te staan: het hostingpakket was jaren oud en nooit meegegaan met de nieuwere omgeving van diezelfde aanbieder. Eén verzoek aan de klantenservice, een verhuizing naar het actuele platform, en de site sprak h2 met HTTP/3 als optie. De laadtijd op mobiel ging van 5,4 naar ruwweg 3,6 seconden, zonder dat er ook maar één regel aan de site is veranderd.
Uw volgende stap
Doe de controle in de ontwikkelaarstools. Staat er h2 of h3, dan kunt u dit onderwerp afvinken en uw energie richten op afbeeldingen, caching en het aantal plugins. Staat er http/1.1, dan hebt u een concrete vraag voor uw hostingpartij en mogelijk een makkelijke winst te pakken. Wilt u weten hoeveel er verder nog te halen valt, dan geeft een snelheidsonderzoek een compleet beeld van waar de tijd blijft.
