12 min. lees

HTTP/2: de complete gids voor moderne webprestaties

Het protocol voor hypertextoverdracht heeft sinds zijn ontstaan een enorme ontwikkeling doorgemaakt en HTTP/2 vertegenwoordigt een van de belangrijkste sprongen voorwaarts in de manier waarop we gegevens over het wereldwijde web versturen. Als je de afgelopen jaren hebt gemerkt dat webpagina’s sneller laden, is de kans groot dat HTTP/2 achter de schermen aan het werk is.

Deze gids beschrijft alles wat je moet weten over HTTP/2, van de basisprincipes en prestatievoordelen tot praktische implementatiestappen. Of je nu een ontwikkelaar bent die zijn webserver wil optimaliseren of gewoon nieuwsgierig is naar wat moderne websites zo bijzonder maakt, hier vind je bruikbare inzichten.

Snel antwoord: Wat is HTTP/2 en waarom is het belangrijk?

HTTP/2 is een belangrijke herziening van het hypertext transfer protocol versie 1.1, gestandaardiseerd door de Internet Engineering Task Force in RFC 7540 (mei 2015). Het richt zich op het verminderen van de latentie, het verbeteren van het gebruik van netwerkbronnen en het aanzienlijk sneller laden van webpagina’s – en dit allesmet behoud van volledige achterwaartse compatibiliteit met de bestaande HTTP-semantiek.

In 2026 is HTTP/2 bijna alomtegenwoordig. Volgens gegevens van W3Techs maakt meer dan 1/3 van de topwebsites actief gebruik van HTTP/2, en de meeste grote CDN’s (Cloudflare, AWS CloudFront, Fastly) schakelen het standaard in voor HTTPS-verkeer. Als je site op HTTPS draait met een moderne webserver, profiteer je waarschijnlijk al van HTTP/2 zonder extra configuratie.

Het protocol introduceert een aantal belangrijke functies die de prestatieproblemen van HTTP 1.1 aanpakken:

  • Multiplexing: Meerdere gegevensstromen reizen tegelijkertijd over een enkele TCP-verbinding
  • Headercompressie (HPACK): Introductie van headerveldcompressie die overbodige HTTP-headermetagegevens drastisch vermindert
  • Binaire framelaag: Een volledig generieke framelaag die tekstgebaseerde commando’s vervangt door efficiënte binaire berichtframing
  • Server push: Proactieve levering van bronnen voordat de browser er expliciet om vraagt
  • Stream prioritering: Client hints die servers vertellen welke bronnen het belangrijkst zijn

Dit is wat dit in de praktijk betekent:

  • Sneller laden van pagina’s, vooral op sites met veel bronnen
  • Minder TCP-verbindingen nodig per oorsprong
  • Betere prestaties op mobiele netwerken met hoge latentie
  • Verbeterd netwerkgebruik over de hele linie

Van HTTP/0.9 naar HTTP/2: een korte geschiedenis

Het HTTP-protocol heeft een lange weg afgelegd sinds Tim Berners-Lee in 1991 HTTP/0.9 introduceerde als een eenvoudig mechanisme voor het ophalen van HTML-documenten. HTTP/1.0 volgde in 1996 en voegde headers en statuscodes toe. HTTP/1.1 werd gestandaardiseerd in RFC 2068 (1997) en later verfijnd in RFC 2616 (1999). Bijna twintig jaar lang vormde HTTP/1.1 de ruggengraat van de client-servercommunicatie op het web.

Maar het web is drastisch veranderd. Moderne webpagina’s veranderden van eenvoudige documenten in complexe toepassingen die tientallen JavaScript-bundels, CSS-bestanden, afbeeldingen en API-aanroepen laadden. Zelfs met breedbandverbindingen en krachtige hardware zorgde de architectuur van HTTP/1.1 voor knelpunten:

  • Kop van de lijn blokkeren: Elke TCP-verbinding kon slechts één verzoek tegelijk verwerken, wat onnodig netwerkverkeer veroorzaakte omdat bronnen in de wachtrij stonden
  • Verbindingsoverhead: Desktop webbrowsers en mobiele webbrowsers openen doorgaans 6-8 parallelle TCP-verbindingen per origin om deze beperking te omzeilen.
  • Overbodige headers: Elk HTTP-verzoek verzond herhaaldelijk dezelfde verbose headers (cookies, user-agent, accept headers)

Google herkende deze problemen en lanceerde het SPDY-project in 2009. SPDY werd voor het eerst geïmplementeerd in Chrome rond 2010 en introduceerde verschillende innovaties:

  • Binaire framing in plaats van op tekst gebaseerde protocollen
  • Meerdere verzoeken multiplexen over een enkele verbinding
  • Kopcompressie om overhead te verminderen
  • Stream-prioritering voor kritieke bronnen

De IETF HTTP Working Group zag het potentieel van SPDY en nam het over als uitgangspunt voor HTTP/2 in 2012. Na uitgebreid werk door de ietf http werkgroep werden RFC 7540 (HTTP/2) en RFC 7541 (HPACK) gepubliceerd in mei 2015.

De browser werd snel overgenomen:

  • Chrome heeft SPDY afgeschreven ten gunste van HTTP/2 vanaf Chrome 51 (mei 2016)
  • Firefox heeft HTTP/2-ondersteuning toegevoegd in versie 36 (februari 2015)
  • Safari gevolgd in versie 9 (september 2015)
  • Microsoft Edge wordt al vanaf de eerste release geleverd met HTTP/2-ondersteuning
  • Zelfs Internet Explorer 11 heeft HTTP/2-ondersteuning gekregen op Windows 8.1 en hoger

Ontwerpdoelen en belangrijkste verschillen met HTTP/1.1

HTTP/2 is volledig compatibel met de HTTP/1.1 semantiek. Methoden zoals GET en POST werken identiek. Statuscodes blijven ongewijzigd. URI’s en HTTP-headervelden volgen dezelfde regels. Wat verandert is hoe deze gegevens over de draad bewegen – de mechanica van de transportlaag die de werkelijke laadsnelheid bepaalt.

De ontwerpdoelen van het protocol waren duidelijk:

DoelHoe HTTP/2 dit bereikt
Latency verminderenMultiplexing elimineert HTTP-level head of line blokkering
Beter gebruik van verbindingenEen enkele TCP-verbinding verwerkt alle verzoeken naar een oorsprong
Kopregel boven het hoofd afsnijdenHPACK-compressie verkleint eerder overgedragen headerwaarden
Mobiele prestaties verbeterenMinder verbindingen en kleinere headers zijn gunstig voor netwerken met hoge latentie

Het mooie van dit ontwerp is de achterwaartse compatibiliteit op applicatieniveau. Je bestaande webapplicatiecode – routes, handlers, responslogica – hoeft niet te veranderen. Alleen de client en server stack moeten HTTP/2 ondersteunen om voordelen te zien.

Dit staat in schril contrast met de HTTP/1.1 workarounds die ontwikkelaars handmatig moesten implementeren:

  • Domain sharding: Activa verspreiden over meerdere domeinen om meer verbindingen te openen
  • Aaneenschakelen van middelen: CSS- en JavaScript-bestanden bundelen om aanvragen te verminderen
  • Afbeelding sprites: Meerdere afbeeldingen combineren in één bestand
  • Inlinen: CSS en JavaScript rechtstreeks in HTML insluiten

De kernmechanismen van HTTP/2 vervangen deze hacks:

  • Binaire framelaag: Berichten opgesplitst in frames dragen gegevens efficiënt over als binaire protocoleenheden
  • Multiplexed streams: Meerdere gelijktijdige uitwisselingen gebeuren via dezelfde verbinding
  • HPACK headercompressie: Dynamische tabellen houden headers bij, waardoor redundantie wordt geëlimineerd
  • Server push: Servers sturen proactief bronnen die de client nodig heeft
  • Stream prioritering: Klanten geven aan welke bronnen het belangrijkst zijn via gewichten voor stroomafhankelijkheid

Binaire frames, streams, berichten en multiplexing

Het hart van HTTP/2 is de binaire framelaag, een fundamenteel verschil met het op tekst gebaseerde HTTP/1.1 formaat. Elk HTTP bericht wordt opgedeeld in binaire frames met een consistente frame layout: een 9-byte frame header die lengte, type, vlaggen en stream identifiers bevat, gevolgd door optionele payload data.

Om de hiërarchie te begrijpen, moet je drie concepten begrijpen:

Streams zijn onafhankelijke, bidirectionele kanalen binnen een enkele verbinding. Elke stream heeft een unieke identifier van 31 bits. Clients initiëren streams met oneven genummerde ID’s (1, 3, 5…), terwijl servers even genummerde ID’s (2, 4, 6…) gebruiken voor door de server geïnitieerde streams zoals push. Een onverwachte stream identifier veroorzaakt een fout. De instelling voor maximale gelijktijdige streams bepaalt hoeveel er gelijktijdig actief kunnen zijn.

Berichten vertegenwoordigen volledige HTTP verzoeken of antwoorden. Een compleet headerblok bestaat uit een of meer frames, en antwoorden kunnen meerdere gegevensframes voor de body bevatten. Als een ontvanger header block fragmenten tegenkomt, zet hij ze opnieuw in elkaar om het volledige bericht te reconstrueren.

Frames zijn de kleinste eenheden op de draad. Veel voorkomende frame- en fouttypes zijn:

  • DATA-frames: Dragen inhoud verzoek/antwoord
  • HEADERS frame: Bevat HTTP-headervelden, mogelijk opgesplitst over meerdere frames die header block fragmenten worden genoemd
  • INSTELLINGEN: Verbindingscontroleberichten voor configuratie
  • WINDOW_UPDATE: Aanpassingen in het venster voor stroomregeling
  • PUSH_PROMISE: Kondigt server push aan
  • RST_STREAM: Beëindigt een stream met een foutcode
  • GOAWAY: Initieert sierlijk afsluiten van de verbinding

De magie gebeurt door multiplexing. Omdat frames van meerdere gelijktijdig geopende streams door elkaar kunnen lopen via een enkele TCP-verbinding, waarbij beide eindpunten frames door elkaar lopen als dat nodig is, is er geen wachttijd. De ontvanger voegt frames samen op basis van stream identifier.

Denk aan het laden van een typische webpagina die:

  • index.html (10 KB)
  • styles.css (25 KB)
  • app.js (100 KB)
  • logo.png (15 KB)
  • heldenafbeelding.jpg (200 KB)

Met HTTP/1.1 opent je browser meerdere verbindingen om deze parallel op te halen, waarbij nog steeds limieten worden overschreden. Met HTTP/2 worden alle vijf bronnen gelijktijdig verzonden over één verbinding als meerdere gegevensstromen. DATA-frames van verschillende streams lopen in elkaar over, waarbij zowel de client als de server de hele verbinding efficiënt beheren.

Dit elimineert de noodzaak voor meerdere TCP-verbindingen, waardoor de overhead van het venster voor de controle van de verbindingsstroom wordt verminderd en de webprestaties aanzienlijk worden verbeterd.

Koptekstcompressie met HPACK

HPACK, gedefinieerd in RFC 7541 (gepubliceerd samen met HTTP/2 in mei 2015), biedt headercompressie speciaal ontworpen voor HTTP/2. Dit is belangrijk omdat HTTP/1.1 headers zeer uitgebreid en volledig ongecomprimeerd waren, wat onnodig netwerkverkeer veroorzaakte bij elke aanvraag.

Kijk eens naar de headers van een typisch HTTP-verzoek:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...

Deze headers overschrijden vaak 700-800 bytes per verzoek. Met cookies kunnen ze oplopen tot enkele kilobytes. Vermenigvuldig dit met tientallen aanvragen per pagina en je verspilt aanzienlijke bandbreedte – vooral pijnlijk op mobiele netwerken.

HPACK comprimeert headers via drie mechanismen:

  1. Statische tabel: 61 vooraf gedefinieerde algemene headerveld/waardeparen (zoals :method: GET of :status: 200) die nooit hoeven te worden verzonden
  2. Dynamische tabel: Een verbindingsspecifieke tabel die client en server samen bouwen en waarin eerder overgedragen headerwaarden worden opgeslagen voor hergebruik.
  3. Huffman codering: Stringwaarden worden gecodeerd met behulp van een vooraf gedefinieerde Huffman-tabel, waardoor tekstweergaven worden verkleind.

Het resultaat is dramatisch. Nadat het eerste verzoek gemeenschappelijke headers in de dynamische tabel heeft gezet, kunnen volgende verzoeken alleen indexreferenties verzenden. Headers die begonnen als kilobytes krimpen tot tientallen bytes.

HPACK is specifiek ontworpen om beveiligingsproblemen zoals CRIME en BREACH te vermijden die eerdere compressieschema’s zoals SPDY’s DEFLATE beïnvloedden. Door statische Huffman codes en zorgvuldig tabelbeheer te gebruiken, voorkomt HPACK dat aanvallers compressieverhoudingsanalyse kunnen gebruiken om geheimen uit gemengde gegevens van aanvaller en slachtoffer te halen.

Het is de moeite waard om op te merken dat HPACK alleen op HTTP-headers werkt. Response bodies gebruiken nog steeds standaard inhoudscoderingsmechanismen zoals gzip of Brotli op de HTTP-laag, volledig los van headercompressie.

Server Push en Stream Prioritering

HTTP/2 introduceert twee optimalisatiefuncties die ontworpen zijn om HTTP/1.1 workarounds te vervangen: server push voor proactieve levering van bronnen en stream prioritering voor intelligente ordening van bronnen.

Server Push

Server push staat een webserver toe om bronnen naar de client te sturen voordat ze expliciet zijn aangevraagd. Het mechanisme werkt via PUSH_PROMISE frames:

  • Klant vraagt /index.html aan
  • De server antwoordt met HTML maar stuurt ook PUSH_PROMISE frames waarin wordt aangekondigd dat /styles.css en /app.js worden gepusht.
  • De server stuurt deze bronnen naar nieuwe streams op initiatief van de server (met stream identifiers die even nummers gebruiken, volgens de regels voor het toewijzen van stream identifiers met een lagere waarde)
  • Browser ontvangt bronnen voordat het parsen van HTML ontdekt dat het ze nodig heeft

Dit elimineert retourritten. In plaats van:

  1. HTML opvragen → HTML ontvangen
  2. HTML ontleden, ontdekken welke CSS nodig is → CSS opvragen
  3. CSS ontleden, benodigde lettertypen ontdekken → Lettertypen aanvragen

Server push voegt stap 2-3 samen in stap 1.

Server push is in de praktijk echter problematisch gebleken:

  • Browsers hebben mogelijk al bronnen in de cache staan, waardoor pushes verspilling zijn
  • Verkeerd geconfigureerde servers pushen te agressief, waardoor bandbreedte wordt verspild
  • Cache digest-mechanismen zijn nooit op grote schaal toegepast
  • Veel CDN’s en browsers beperken of schakelen push standaard uit

Cliënten kunnen push volledig uitschakelen door SETTINGS_ENABLE_PUSH = 0 in te stellen in hun verbindingsvoorwoord. Als een voorwoord voor een cliëntverbinding push onmiddellijk uitschakelt, bestaat het voorwoord voor een serververbinding uit bevestiging en naleving.

Prioriteren van stromen

Met stream prioritering kunnen clients het belang van bronnen aangeven, waardoor servers bandbreedte effectief kunnen toewijzen. Het mechanisme gebruikt:

  • Gewichten: Waarden van 1-256 die het relatieve belang aangeven
  • Afhankelijkheden: Streams kunnen afhankelijk zijn van andere streams en een afhankelijkheidsboom vormen via stroomafhankelijkheidsdeclaraties

Praktisch voorbeeld:

  • HTML-stream (gewicht 256, geen afhankelijkheid) – hoogste prioriteit
  • CSS-stream (gewicht 200, afhankelijk van HTML) – hoge prioriteit
  • Above-fold afbeeldingen (gewicht 100, afhankelijk van CSS)
  • Analytics JavaScript (gewicht 16, afhankelijk van HTML) – lage prioriteit

Dit zorgt ervoor dat kritieke renderbronnen als eerste aankomen, waardoor de waargenomen laadsnelheid verbetert, zelfs als de totale overdrachtstijd gelijk blijft.

Belangrijk voorbehoud:

  • Prioritering is adviserend, niet verplicht
  • Serverimplementaties variëren sterk in hoe ze prioriteiten eren
  • Tussenpersonen (proxy’s, CDN’s) kunnen frames opnieuw ordenen
  • Tuning vereist testen met echt verkeer, geen aannames

De geadverteerde gelijktijdige stroomlimiet beïnvloedt hoeveel streams tegelijkertijd actieve prioriteiten kunnen hebben.

Flowcontrole, foutafhandeling en veiligheidsoverwegingen

HTTP/2 implementeert zijn eigen flow control en foutafhandeling boven TCP, waarmee scenario’s worden aangepakt waarbij de intelligentie van de applicatielaag beter presteert dan de standaardinstellingen van de transportlaag.

Debietregeling

Flowcontrole voorkomt dat snelle afzenders langzame ontvangers overweldigen. HTTP/2 gebruikt een op krediet gebaseerd systeem met WINDOW_UPDATE frames:

  • Elke stream heeft zijn eigen venster voor debietregeling van de ontvanger
  • De verbinding heeft ook een venster voor verbindingsstroomregeling
  • Standaard venstergrootte: 65.535 bytes (64 KB)
  • Verzenders kunnen geen DATA-frames verzenden die het beschikbare venster van de ontvanger overschrijden
  • Ontvangers sturen WINDOW_UPDATE frames om meer krediet te geven

Belangrijkste kenmerken:

  • Flow control is hop-by-hop (van toepassing tussen elk zender/ontvanger paar)
  • Het kan niet worden uitgeschakeld
  • Alleen DATA-frames tellen mee voor het venster; andere verplichte framegegevens niet.
  • Zowel stream flow control als connection flow control werken onafhankelijk van elkaar

Dit voorkomt dat een enkele snelle stroom de bronnen van de verbinding monopoliseert, wat vooral belangrijk is wanneer proxy’s of CDN’s tussen clients en oorsprong staan.

Foutafhandeling

HTTP/2 biedt granulaire foutsignalering:

  • Fouten op stream-niveau: RST_STREAM beëindigt onmiddellijk een stroom zonder de andere te beïnvloeden, met foutcodes als PROTOCOL_ERROR of FLOW_CONTROL_ERROR.
  • Fouten op verbindingsniveau: GOAWAY sluit de verbinding netjes af, zodat verzoeken tijdens de vlucht kunnen worden voltooid terwijl nieuwe verzoeken worden voorkomen.

Het protocol definieert een register met foutcodes:

  • PROTOCOL_ERROR (0x1): Algemene protocolschending
  • FLOW_CONTROL_ERROR (0x3): Flow control-regels geschonden
  • FRAME_SIZE_ERROR (0x6): Frame overschreden SETTINGS_MAX_FRAME_SIZE
  • INADEQUATE_SECURITY (0xc): Beveiligingsconfiguratie transportlaag onvoldoende

Beveiligingsoverwegingen

Hoewel RFC 7540 technisch gezien geen versleuteling vereist, vereisen alle grote webbrowsers HTTP/2 over transportlaagbeveiliging (TLS). Dit maakt TLS 1.2+ de de facto basislijn:

  • Verbinding begint met TLS-handshake inclusief ALPN (Application-Layer Protocol Negotiation)
  • ALPN-extensie onderhandelt over “h2”-identifier voor HTTP/2
  • Servers moeten zwakke cipher suites vermijden die op de zwarte lijst van de spec staan
  • Cipher suites die RC4 of andere verouderde algoritmen gebruiken veroorzaken INADEQUATE_SECURITY fouten

Privacyoverwegingen zijn onder andere:

  • INSTELLINGEN en prioriteitspatronen kunnen clients vingerafdrukken geven
  • Eén verbinding per herkomst correleert alle gebruikersactiviteit met die herkomst
  • Binair protocol camoufleert verkeer, maar verbergt het niet voor netwerkwaarnemers

TCP Head-of-Line Blokkeren

HTTP/2 lost blokkering op HTTP-niveau op door middel van multiplexing, maar blokkering op TCP-niveau blijft bestaan. Wanneer een TCP pakket verloren gaat, blokkeren alle streams op die verbinding totdat de heruitzending is voltooid, zelfs streams waarvan de gegevens succesvol zijn aangekomen.

Deze beperking motiveerde HTTP/3, dat over QUIC (gebaseerd op UDP) loopt om echte stream-onafhankelijkheid te bieden. Pakketverlies bij één stream blokkeert andere streams niet.

HTTP/2 in de praktijk implementeren en gebruiken

In 2026 is het inschakelen van HTTP/2 eenvoudig. De meeste moderne webservers en CDN’s ondersteunen het out of the box, voornamelijk via HTTPS. Het HTTP-upgrade mechanisme handelt de onderhandelingen transparant af.

Vereisten voor de client

Gebruikers hoeven niets speciaals te doen:

  • Alle moderne desktop webbrowsers (Chrome, Firefox, Safari, Edge) ondersteunen standaard HTTP/2
  • Mobiele webbrowsers (Chrome voor Android, Safari op iOS) bieden volledige ondersteuning
  • Compatibiliteit door op de huidige browserversies te blijven
  • HTTP/2 onderhandelt automatisch wanneer beschikbaar

Server-kant configuratie

Apache HTTP Server (2.4.17+):

  • Schakel de module mod_http2 in (niet de oudere mod_spdy)
  • Protocollen h2 http/1.1 toevoegen aan TLS virtuele hosts
  • Zorg ervoor dat OpenSSL-versie ALPN ondersteunt

Nginx (1.9.5+):

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... rest of configuration
}

IIS (Windows Server 2016+):

  • HTTP/2 standaard ingeschakeld voor HTTPS met TLS 1.2+
  • Geen extra configuratie nodig

CDN-aanbieders:

  • Cloudflare: HTTP/2 standaard ingeschakeld op alle plannen
  • AWS CloudFront: Standaard ingeschakeld voor HTTPS-distributies
  • Fastly: Ondersteund en standaard ingeschakeld

Verificatie en probleemoplossing

Controleer of HTTP/2 werkt met deze controlelijst:

  • Browser DevTools: Open het tabblad Netwerk, schakel de kolom Protocol in en zoek naar “h2”.
  • Opdrachtregel: curl –http2 -I https://example.com toont HTTP/2 in antwoord
  • Online hulpmiddelen: HTTP/2 testdiensten verifiëren configuratie
  • Controleer tussenpersonen: CDN of reverse proxy moet HTTP/2 ondersteunen, niet alleen origin server

Veelvoorkomende problemen die HTTP/2 verhinderen:

  • OpenSSL-versie te oud voor ALPN-ondersteuning
  • Alleen TLS 1.0/1.1 configuratie
  • Zwakke cipher suites die fallback activeren
  • Verkeerd geconfigureerde proxy verwijdert HTTP/2-ondersteuning

HTTP/2 en verder

HTTP/2 blijft het dominante protocol voor moderne webcommunicatie, zelfs nu HTTP/3 (RFC 9114, gepubliceerd in 2022) in gebruik wordt genomen. HTTP/3 pakt TCP head-of-line blokkering aan door over QUIC te lopen, maar HTTP/2’s enkele TCP verbindingsmodel blijft het merendeel van het webverkeer effectief bedienen.

Voor de meeste sites levert HTTP/2 aanzienlijke verbeteringen van de webprestaties met minimale configuratie-inspanningen. Begin vandaag nog met het uitwisselen van frames via HTTP/2 en uw gebruikers – op desktop of mobiel – zullen sneller en efficiënter pagina’s laden.

Belangrijkste opmerkingen

  • HTTP/2 revolutioneert webprestaties door multiplexing, waardoor meerdere gelijktijdige uitwisselingen via één verbinding mogelijk zijn
  • HPACK headercompressie elimineert overbodige headertransmissie, wat vooral mobiele gebruikers ten goede komt
  • Server push en stream prioritering optimaliseren de levering van bronnen, hoewel de implementatie varieert
  • Debietcontrole voorkomt dat bronnen uitgeput raken door meerdere streams
  • De implementatie is eenvoudig op moderne servers en vereist voornamelijk HTTPS-configuratie.
  • Alle belangrijke browsers ondersteunen HTTP/2, waardoor de adoptie naadloos verloopt voor eindgebruikers

Volgende stappen

Als je HTTP/2 nog niet hebt geverifieerd op je webserver, dan is het nu tijd. Open de ontwikkelaarstools van je browser, laad je site en controleer de kolom Protocol. Als je “http/1.1” ziet in plaats van “h2”, herzie dan je serverconfiguratie – je laat aanzienlijke prestatiewinst liggen.

Als je HTTP/2 al gebruikt, overweeg dan om de HTTP/2-verbindingsstatistieken van je server te controleren. Begrijpen hoe meerdere gelijktijdige streams zich gedragen onder echt verkeer helpt bij het identificeren van optimalisatiemogelijkheden voordat je gebruikers problemen opmerken.