HTTP/2 is de tweede grote versie van het Hypertext Transfer Protocol, in mei 2015 vastgelegd als RFC 7540. Het was de eerste belangrijke update van HTTP sinds HTTP/1.1 in 1997 werd gestandaardiseerd, en pakte fundamentele prestatieproblemen aan die het web bijna twee decennia plaagden. Serveert uw WordPress-site nog content via HTTP/1.1, dan laat u waarschijnlijk aanzienlijke prestatiewinst liggen.
Het protocol kwam voort uit het experimentele SPDY-protocol van Google, dat sinds 2012 in gebruik was en bewees dat de kernideeën achter HTTP/2 (multiplexing, header-compressie, prioritisatie) goed werkten in de praktijk. Toen de IETF HTTP/2 standaardiseerde, werd SPDY uitgefaseerd en vormden de ideeën ervan de basis van de nieuwe standaard.
Belangrijkste verbeteringen ten opzichte van HTTP/1.1
Om te begrijpen waarom HTTP/2 ertoe doet, moet u eerst weten wat er mis was met HTTP/1.1. Onder het oude protocol kon elke TCP-verbinding maar één request tegelijk verwerken. Moest uw browser 40 resources laden (een typische WordPress-pagina), dan moest hij meerdere verbindingen openen (browsers staan doorgaans 6 per domein toe) en de overige requests in de wachtrij zetten. Dit creëerde kunstmatige knelpunten die elke pagina-laad vertraagden.
HTTP/2 lost dit en meer op:
Multiplexing: dit is de allerbelangrijkste verbetering. HTTP/2 staat toe dat meerdere requests en responses tegelijkertijd onderweg zijn over één enkele TCP-verbinding. Uw browser kan tegelijk uw CSS-bestand, drie JavaScript-bestanden en tien afbeeldingen aanvragen, allemaal over één verbinding. Geen wachten meer, geen wachtrijen, geen kunstmatige limieten. De server stuurt responses terug zodra ze beschikbaar zijn, en de browser stelt ze samen. Deze enkele wijziging kan de laadtijden voor resource-zware WordPress-sites drastisch verkorten.
Header-compressie (HPACK): HTTP-headers worden bij elk request en elke response meegestuurd. In HTTP/1.1 zijn deze headers platte tekst en vaak repetitief. Dezelfde cookies, user-agent-strings en accept-headers worden steeds opnieuw verstuurd. HTTP/2 gebruikt het compressie-algoritme HPACK, dat een gedeelde tabel van veelvoorkomende header-velden bijhoudt tussen client en server. Na het eerste request hoeven volgende headers alleen nog de verschillen te versturen. Voor een WordPress-site die per pagina meer dan 50 resources laadt, kan dit per pagina-laad tientallen kilobytes besparen.
Binary framing: HTTP/1.1 is een tekstgebaseerd protocol, wat betekent dat de parser regeleinden moet zoeken, verschillende tekstcoderingen moet verwerken en met diverse edge cases moet omgaan. HTTP/2 gebruikt een binaire framinglaag die alle communicatie in goed gedefinieerde frames verpakt. Binaire data is sneller te parsen, foutgevoeliger en compacter. U merkt hier als gebruiker niets van, maar het verlaagt de verwerkingsoverhead op zowel server als client.
Stream-prioritisatie: HTTP/2 laat de browser de server vertellen welke resources belangrijker zijn. Bijvoorbeeld kan de browser aangeven dat het hoofd-CSS-bestand vóór achtergrondafbeeldingen geleverd moet worden. De server kan dan bandbreedte navenant toewijzen. In de praktijk verschillen browser-implementaties van prioritisatie, en niet alle servers gaan er perfect mee om, maar voor veel sites levert het toch zinvolle verbeteringen op.
Server Push: deze functie laat de server resources naar de browser sturen voordat deze er überhaupt om vraagt. Wanneer de browser een HTML-pagina opvraagt, kan de server al de CSS- en JavaScript-bestanden meeduwen waarvan hij weet dat de browser ze daarna nodig heeft. Dit elimineert de round-trip-vertraging waarmee de browser eerst moet ontdekken dat hij een resource nodig heeft en deze vervolgens moet aanvragen. In de praktijk is Server Push echter beperkt aangenomen. Het is lastig correct te implementeren (resources duwen die de browser al gecached heeft, verspilt bandbreedte), en sommige CDN's hebben de ondersteuning ervan uitgefaseerd. Chrome heeft Server Push in versie 106 (2022) verwijderd. Het concept leeft voort in het 103 Early Hints-mechanisme, dat eenvoudiger en praktischer is.
Waarom domain sharding niet meer nodig is
In het HTTP/1.1-tijdperk gebruikten webontwikkelaars een truc genaamd domain sharding om de limiet van zes verbindingen per domein te omzeilen. Ze serveerden afbeeldingen vanaf img1.example.com, CSS vanaf cdn.example.com en fonts vanaf weer een ander subdomein. Zo vermenigvuldigden ze het aantal parallelle verbindingen dat de browser kon openen.
Met HTTP/2 is domain sharding niet alleen onnodig, maar zelfs contraproductief. Omdat HTTP/2 alle requests over één enkele verbinding multiplext, dwingt het splitsen van resources over meerdere domeinen de browser om extra TCP-verbindingen en TLS-handshakes op te zetten. Elke nieuwe verbinding voegt latentie toe. Een WordPress-site die voor HTTP/1.1 met domain sharding was geoptimaliseerd, zou zijn resources bij overstap naar HTTP/2 moeten consolideren op minder domeinen.
Eveneens wordt het aaneenrijgen van CSS- en JavaScript-bestanden tot één bundel (een andere veelvoorkomende HTTP/1.1-optimalisatie) minder belangrijk met HTTP/2. Het versturen van veel kleinere bestanden werkt efficiënt dankzij multiplexing, en heeft als bijkomend voordeel dat caching beter werkt: verandert één klein bestand, dan hoeft alleen dat bestand opnieuw gedownload te worden, niet de hele samengevoegde bundel.
HTTP/2 vereist in de praktijk HTTPS
De HTTP/2-specificatie vereist technisch geen versleuteling. Het kan over gewoon TCP (h2c, voor HTTP/2 cleartext). Echter, alle grote browsers (Chrome, Firefox, Safari, Edge) hebben besloten HTTP/2 alleen via TLS te implementeren (h2). Dit betekent dat u in alle praktische gevallen een SSL/TLS-certificaat nodig heeft om HTTP/2 te gebruiken.
Dit is eigenlijk geen beperking meer. Gratis certificaten van Let's Encrypt hebben HTTPS voor iedereen toegankelijk gemaakt, en de meeste WordPress-hostingproviders nemen SSL-certificaten op in hun pakketten. Staat uw WordPress-site nog op platte HTTP, dan is overstappen naar HTTPS een voorwaarde voor HTTP/2, en het brengt zijn eigen beveiligingsvoordelen mee.
HTTP/3 en QUIC: de volgende stap
HTTP/3 (RFC 9114, vastgelegd in juni 2022) is de volgende evolutie. Waar HTTP/2 op TCP draait, vervangt HTTP/3 TCP volledig door een nieuw transportprotocol genaamd QUIC. QUIC is gebouwd op UDP en integreert TLS 1.3-versleuteling rechtstreeks in de transportlaag. De belangrijkste voordelen van HTTP/3 ten opzichte van HTTP/2 zijn:
- Snellere verbindingsopzet: QUIC combineert de TCP-handshake en TLS-handshake in één round-trip, wat de verbindingsopbouw verkort. Voor terugkerende bezoekers kan zelfs zero-round-trip-hervatting worden bereikt.
- Geen head-of-line blocking: in HTTP/2 over TCP stagneren bij verlies van één pakket alle streams op die verbinding totdat het pakket opnieuw is verzonden. QUIC handelt pakketverlies per stream af, dus één verloren pakket vertraagt alleen de getroffen stream, niet alles.
- Betere mobiele prestaties: QUIC verwerkt netwerkwijzigingen (zoals de overstap van wifi naar mobiel internet) soepeler, omdat verbindingen worden geïdentificeerd door een connection-ID in plaats van door IP-adres en poort.
Grote CDN-providers zoals Cloudflare en Fastly ondersteunen HTTP/3 al. De meeste hostingproviders zijn nog bezig met de invoering. Voor WordPress-site-eigenaren is HTTP/3-ondersteuning grotendeels een server-side aangelegenheid; u hoeft niets aan WordPress zelf te wijzigen.
Hoe controleert u of uw host HTTP/2 ondersteunt
Er zijn verschillende manieren om te verifiëren of uw WordPress-site via HTTP/2 wordt geserveerd:
- Browser-DevTools: open in Chrome DevTools het tabblad Network, klik met de rechtermuisknop op de kolomkoppen en schakel de kolom "Protocol" in. U zou bij HTTP/2-requests
h2moeten zien staan. - Onlinetools: sites zoals KeyCDN's HTTP/2-test of de HTTP/2-checker op tools.keycdn.com kunnen HTTP/2-ondersteuning voor elke URL verifiëren.
- Commandoregel: voer
curl -I --http2 -s https://uwsite.comuit en zoek naarHTTP/2 200in de response. - InspectWP: het rapport vermeldt de gedetecteerde HTTP-versie van uw WordPress-site.
Ondersteunt uw host geen HTTP/2, dan kan een CDN zoals Cloudflare voor uw site geplaatst worden om HTTP/2 (en HTTP/3) te bieden, ook als uw origin-server alleen HTTP/1.1 spreekt. Het CDN handelt de HTTP/2-verbinding met de browser van de bezoeker af en communiceert met uw origin-server via het protocol dat die ondersteunt.
WordPress-prestatie-implicaties
Een typische WordPress-pagina laadt tussen de 20 en 80 afzonderlijke resources: stylesheets van het thema en plugins, JavaScript-bestanden, webfonts, afbeeldingen en soms externe resources van CDN's en diensten van derden. Onder HTTP/1.1 was het laden van al deze resources de grootste oorzaak van laadtijd, vanwege de verbindings- en wachtrijbeperkingen.
Na overstap naar HTTP/2 zien de meeste WordPress-sites zinvolle verbeteringen in Time to First Contentful Paint en in de algehele paginalaadtijd. De exacte verbetering hangt af van hoeveel resources uw site laadt, maar reducties van 20-50% in laadtijd komen veel voor bij sites die voorheen op HTTP/1.1 zaten. Sites met veel kleine resources (typisch voor WordPress met meerdere actieve plugins) profiteren het meest.
Houd er rekening mee dat HTTP/2 andere prestatieoptimalisaties niet vervangt. U heeft nog steeds correcte caching, beeldoptimalisatie en efficiënte code nodig. Maar HTTP/2 verwijdert een belangrijk infrastructureel knelpunt dat met geen enkele WordPress-plugin-optimalisatie te verhelpen is.
Wat InspectWP controleert
InspectWP detecteert de HTTP-protocolversie die uw WordPress-site gebruikt door de response-headers te onderzoeken. Wordt uw site via HTTP/1.1 geserveerd, dan signaleert het rapport dit als prestatieprobleem en raadt aan te upgraden naar HTTP/2. Wordt HTTP/2 of HTTP/3 gedetecteerd, dan wordt dit als positief vermeld. De HTTP-versie wordt getoond in de prestatiesectie van het rapport, naast andere serverniveau-statistieken zoals compressie en response-headers.