Het team voegt nog eens dertig JavaScript-bestanden samen “omdat HTTP/1” – ook al biedt nginx al twee jaar HTTP/2 aan. De monolithische bundel verbreekt de cache bij elke patch. Tegelijkertijd distribueert een ander project zijn assets op static1, static2, static3: drie TLS-handshakes, multiplexing wordt geannuleerd door gewoonten die zijn geërfd van HTTP/1.
HTTP/2 multiplext meerdere verzoeken via één TCP/TLS-verbinding. Geen HTTP/1.1's wachtrij met zes parallelle slots meer, maar ook geen JavaScript-weergaveblokkering of afbeeldingen van vier megabytes. Multiplexing begrijpen betekent weten wat het reguleert en wat het intact laat.
Multiplexing: wat er feitelijk verandert
Onder HTTP/1.1 beperkten browsers parallelle verbindingen met hetzelfde domein, vandaar domein-sharding, CSS-sprites en aaneenschakeling van bestanden. HTTP/2 opent onafhankelijke streams op een enkele verbinding, met HPACK-headercompressie.
| Praktisch HTTP/1 | Onder HTTP/2 |
|---|---|
| Domein sharding | Contraproductief |
| CSS-sprites | Minder nodig |
| Grote enkele bundel | Modules + cache op hash |
| Zes keep-alive-verbindingen | Een rijke verbinding |
Multiplexing versnelt transport — niet de bestandsgrootte of de uitvoeringsvolgorde van JavaScript.
Een site die twaalf synchrone scripts in de <head> laadt, blijft traag, HTTP/2 of niet. De netwerkbeperking is veranderd; de beperking van het kritische weergavepad blijft bestaan.
Prioritering, blokkeren vooraan in de rij en limieten
HTTP/2 had last van head-of-queue-blokkering op TCP-niveau: het verlies van een pakket blokkeerde alle stromen. HTTP/3 (QUIC) verbetert dit punt ten opzichte van UDP. In de praktijk blijft het verminderen van het aantal synchrone scripts in de <head> effectiever dan het aanpassen van de streamprioriteiten aan de nginx-kant.
Streamprioriteiten tussen browser en server hebben een bescheiden reëel effect vergeleken met het optimaliseren van het LCP-beeld of het uitstellen van niet-essentiële JavaScript. Meet LCP, TBT en INP – niet alleen het protocol in responsheaders.
CDN, TLS-beëindiging en oorsprong
HTTP/2-beëindiging op het CDN (Cloudflare, etc.) naar een HTTP/1.1-oorsprong blijft heel gebruikelijk: de client profiteert van multiplexing, de oorsprong onderhoudt een eenvoudiger stapel. Verifieer de ALPN-onderhandeling met:
curl -I --http2 https://uw-site.voorbeeld
Bij shared hosting zonder native HTTP/2 is een gratis CDN voor de origin vaak voldoende. Vergelijk aanbiedingen via onze overzicht — ALPN h2-ondersteuning is afhankelijk van de webserver en het certificaat, niet alleen van een vakje in het paneel.
De HTTP/2-serverpush is grotendeels verouderd: Chrome heeft deze verwijderd, en vooraf laden via <link rel="preload"> biedt fijnere controle zonder bandbreedte te verspillen aan reeds in de cache opgeslagen bronnen.
HTTP/3 en geleidelijke migratie
HTTP/3 is gebaseerd op QUIC (UDP) en verbetert de prestaties op mobiele netwerken met pakketverliezen. Activering gebeurt geleidelijk aan de CDN-kant – Cloudflare, Fastly en anderen activeren het zonder herontwerp van de applicatie. Uw PHP- of Node.js-code hoeft niet te veranderen; het is de netwerklaag die evolueert.
Verwijder eerst HTTP/1-praktijken die schadelijk zijn geworden: domein-sharding, monolithische bundels, onnodige sprites. Schakel vervolgens HTTP/3 in als uw CDN dit aanbiedt. Het is een bonus, geen vereiste.
Controlelijst na HTTP/2-activering
- Verwijder domein-sharding op statische assets.
- Verdeel de bundels logisch (op route of op functionaliteit).
- Laad de LCP-afbeelding vooraf, stel het niet-kritieke JavaScript uit of asynchroon het.
- Behoud Brotli- of gzip-compressie: HTTP/2 comprimeert de antwoordteksten niet.
- Lijn de cache headers zo uit dat de netwerkversterking niet wordt geannuleerd door overmatige hervalidaties.
De top: HTTP/2-badge, site nog steeds traag
Dit is wat het protocol dat wordt weergegeven in DevTools niet garandeert.
Multiplexing begrijpen betekent dat u stopt met optimaliseren voor HTTP/1, terwijl u doorgaat met het optimaliseren van de inhoud en het kritieke pad.
Beslis en ga vooruit zonder blinde vlek
Controleer gedurende een halve dag of HTTP/2 echte winst oplevert:
- Bevestig dat HTTP/2 actief is aan de clientzijde (
curl --http2of tabblad Protocol in DevTools). - Verwijder domein-sharding op assets – meet LCP voor en na.
- Vervang de monolithische bundel door redelijke modules met hash in de naam.
- Activeer HTTP/3 via het CDN, indien beschikbaar, zonder te wachten op een herontwerp van de applicatie.
- Vergelijk hosts met TLS en HTTP/2 via de overzicht en de vergelijker.
Als de site na HTTP/2 traag blijft, ligt het knelpunt ergens anders: afbeeldingen, JavaScript, database. De technische blog biedt aanvullende handleidingen over caching en afbeeldingsformaten.
Veelgestelde vragen
Maakt HTTP/2 domein-sharding nutteloos?
Ja, in principe. Een multiplexverbinding bedient meerdere bestanden zonder nieuwe TCP/TLS-verbindingen te openen. Sharding bootst dure handdrukken na en doet vaak het voordeel van multiplex teniet. Zorg voor een schone HTTP/2-oorsprong of CDN.
Moeten we CSS/JS nog steeds samenvoegen?
Minder dan HTTP/1.1, maar een enorme bundel handhaaft een slechte cachegranulariteit: elke wijziging maakt het hele bestand ongeldig. Streef naar redelijke modules, niet naar veertig niet-gecachte microbestanden.
Is serverpush HTTP/2 nuttig?
Grotendeels nee. Chrome heeft de ondersteuning verwijderd en het vooraf laden via de <link>-tag biedt fijnere controle. Configureer nginx push niet zonder de impact op de bandbreedte te meten.
HTTP/2 overal vereist wat aan de hostkant?
TLS met ALPN h2, geldig certificaat, recente webserver (nginx, Apache, Caddy) of CDN die HTTP/2 afsluit. Controleer in gedeeld de ondersteuning in het paneel; plaats anders een CDN vóór een HTTP/1.1-oorsprong.
HTTP/2 stelt de netwerkwachtrij in, niet de JavaScript-wachtrij.