Wat zijn gzip en HTTP/3, en wat moet je als eerste verbeteren voor de laadprestaties van webpagina's?

gzip is een manier om de hoeveelheid te verzenden data te verkleinen door de tekstbestanden van een webpagina te comprimeren, terwijl HTTP/3 een protocol is dat verandert hoe meerdere verzoeken worden afgehandeld en pakketverlies wordt aangepakt door HTTP via QUIC te leveren. Beide kunnen het laden van pagina's helpen, maar ze lossen niet hetzelfde probleem op. In plaats van te vragen: „Wat is sneller, gzip of HTTP/3?”, is het nauwkeuriger om eerst te vragen waar de bottleneck van de huidige pagina ligt: verzonden bytes, netwerkverlies, serverrespons, afbeeldingen, rendering of JavaScript.www.rfc-editor.org↗datatracker.ietf.org↗

Een van de meest voorkomende misvattingen in de praktijk is dat het inschakelen van HTTP/3 automatisch een hele website sneller maakt. HTTP/3 kan een belangrijke fundamentele verbetering zijn, maar vervangt geen oplossingen voor een te grote afbeelding boven de vouw, renderblokkerende CSS of JavaScript, of een trage serverrespons. Omgekeerd kan het inschakelen van gzip of Brotli de overdrachtsomvang merkbaar verkleinen met een relatief kleine configuratiewijziging als een site tekstreacties helemaal niet comprimeert.web.dev↗developer.mozilla.org↗

Wat is gzip precies?

gzip is een veelgebruikte contentcodering (Content-Encoding) voor HTTP. Een server comprimeert oorspronkelijke HTML, CSS, JavaScript, JSON, SVG en vergelijkbare content in gzip-formaat voordat die wordt verzonden, waarna de browser deze decomprimeert en de oorspronkelijke content gebruikt. De HTTP Semantics-specificatie definieert gzip als een contentcodering die compressie uit de LZ77-familie en een 32-bits CRC gebruikt.www.rfc-editor.org↗www.rfc-editor.org↗

Het belangrijkste punt is dat het logische bestandstype niet verandert. Zelfs wanneer een server bijvoorbeeld app.js met gzip levert, voert de browser uiteindelijk dezelfde JavaScript uit. Wat verandert, is het aantal bytes dat over het netwerk gaat. Wanneer een bestand kleiner is, kost downloaden via beperkte bandbreedte minder tijd en kan ook het mobiele dataverbruik van een gebruiker dalen.www.rfc-editor.org↗developer.chrome.com↗

Hoe kiezen browsers en servers een compressiemethode?

Browsers gebruiken de requestheader Accept-Encoding om aan te geven welke compressieformaten ze kunnen decoderen. Op basis van die lijst en de prioriteiten daarin kiest de server een geschikte representatie en voegt deze een header zoals Content-Encoding: gzip of Content-Encoding: br aan de respons toe. br betekent Brotli.www.rfc-editor.org↗developer.mozilla.org↗

Als een server of CDN voor dezelfde URL verschillende responsen levert afhankelijk van de compressiemethode, is het gebruikelijk om Vary: Accept-Encoding te verzenden zodat caches ze onderscheiden. Anders kan een gecomprimeerde representatie die voor één client is opgeslagen, onterecht worden hergebruikt voor een verzoek met andere voorwaarden.www.rfc-editor.org↗

Het volgende is een conceptuele stroom:

1. De browser vermeldt ondersteunde formaten, zoals Accept-Encoding: br, gzip.
2. De server of CDN kiest een van de Brotli-, gzip- of ongecomprimeerde versies van het bestand.
3. Naast de response body vermeldt deze het gekozen formaat in Content-Encoding.
4. De browser decomprimeert de respons tijdens of na ontvangst en gaat vervolgens verder met HTML-parsing, het toepassen van CSS en het uitvoeren van JavaScript.

gzip kan in dit proces de overdrachtstijd verkorten, maar elimineert niet de tijd die de browser besteedt aan het parsen en uitvoeren van JavaScript. Compressie is één onderdeel van prestaties, geen oplossing voor elke vertragingsbron.developer.chrome.com↗web.dev↗

Voor welke bestanden is gzip nuttig?

gzip is bijzonder geschikt voor tekst met veel herhaalde tekenreeksen en structuren. Data met veel herhaling, zoals HTML-tags, CSS-selectors, JavaScript-identificatoren en -syntaxis, en JSON-veldnaam, kunnen na compressie veel kleiner worden voor overdracht. Algemene richtlijnen voor webprestaties bevelen ook aan compressie toe te passen op tekstresources en assets uit te sluiten die al zijn gecomprimeerd.developer.mozilla.org↗web.dev↗

Voor formaten die zelf al compressie toepassen, zoals JPEG, WebP, AVIF, video, audio en gecomprimeerde archieven, kan gzip opnieuw toepassen weinig voordeel bieden. Hetzelfde geldt voor kleine bestanden. web.dev legt uit dat resources kleiner dan ongeveer 1 KiB inefficiënt kunnen comprimeren of geen betekenisvolle besparing opleveren.developer.mozilla.org↗web.dev↗

Een belangrijk onderscheid hierbij is dat tussen overdrachtsgrootte en oorspronkelijke grootte. In het Network-paneel van ontwikkelaarstools kun je de gecomprimeerde downloadgrootte vergelijken met de ongecomprimeerde grootte, en kun je de responseheader Content-Encoding controleren om na te gaan of compressie werkelijk is toegepast.developer.chrome.com↗

Wat is het verschil tussen gzip en Brotli?

Brotli is geen opvolger van gzip; het is een ander algoritme dat naast gzip kan worden gekozen voor HTTP-contentcompressie. Op het moderne web is het gebruikelijk om Brotli voor tekstassets prioriteit te geven en tegelijk gzip aan te bieden voor clients die Brotli niet kunnen gebruiken. Omdat browsers Accept-Encoding verzenden en servers over het resultaat onderhandelen, kunnen afhankelijk van de client verschillende gecomprimeerde representaties voor dezelfde URL worden verzonden.developer.mozilla.org↗developer.mozilla.org↗

Over het algemeen kan Brotli voor webtekst kleinere resultaten opleveren dan gzip. Dat betekent echter niet altijd een evenredige verbetering van de totale ervaren paginasnelheid. Als de bespaarde bytes beperkt zijn, of als afbeeldingen, serververwerking of JavaScript-uitvoering de bottleneck vormen, kan overstappen van gzip naar Brotli maar een beperkt effect hebben. Op servers die dynamisch comprimeren, kunnen instellingen die de compressieverhouding verhogen ook het CPU-gebruik en de responslatentie verhogen. Statische assets moeten daarom vooraf worden gecomprimeerd tijdens de build- of CDN-fase, terwijl dynamische responsen moeten worden afgestemd op de werkelijke belasting.web.dev↗web.dev↗

Met andere woorden: de selectiecriteria lijken meer op het volgende dan op „Brotli is altijd beter”:

• Als tekstassets groot zijn en er veel eerste bezoekers zijn, overweeg dan zowel Brotli als gzip te leveren.
• Als een CDN al geschikte compressie biedt, comprimeer dezelfde content dan niet opnieuw in de applicatie.
• Meet voor een dynamische dienst met beperkte server-CPU de balans tussen compressieniveau en TTFB.
• Als afbeeldingen en video een groot deel van de pagina uitmaken, kan mediaoptimalisatie vóór tekstcompressie komen.

Wat verandert HTTP/3?

HTTP/3 is een standaard die de request-responsesemantiek van HTTP behoudt, maar TCP als transportbasis vervangt door QUIC. QUIC werkt via UDP, maar is niet simpelweg een manier om HTTP via UDP te verzenden. Het biedt functies zoals het opzetten van verbindingen, versleuteling, betrouwbaarheid, congestiecontrole en gemultiplexte streams, en HTTP/3 gebruikt deze functies om HTTP-berichten te leveren.datatracker.ietf.org↗developer.mozilla.org↗

HTTP/1.1 had aanzienlijke beperkingen bij het afhandelen van verzoeken via één verbinding, waardoor het gebruik van meerdere parallelle TCP-verbindingen wijdverspreid raakte. HTTP/2 verbeterde dit door meerdere verzoeken over één TCP-verbinding te multiplexen. Omdat TCP echter een geordende levering van ontvangen data garandeert, kunnen gegevens die na een pakketverlies aankomen niet op volgorde aan de applicatie worden doorgegeven totdat dat verlies is hersteld. In HTTP/2 kan deze vertraging op TCP-niveau meerdere HTTP-streams beïnvloeden.datatracker.ietf.org↗www.rfc-editor.org↗

QUIC van HTTP/3 beheert betrouwbare, geordende levering per stream. Daardoor hoeft verlies van data op één stream niet noodzakelijk ook niet-gerelateerde streams te stoppen. RFC 9000 legt uit dat wanneer een pakket verloren gaat, alleen de streams die data uit dat pakket bevatten worden geblokkeerd in afwachting van herverzending, terwijl andere streams kunnen doorgaan.www.rfc-editor.org↗

Hoe nauwkeurig is de uitspraak „head-of-line blocking wordt geëlimineerd”?

Wat HTTP/3 primair aanpakt, is head-of-line blocking op transportlaag over de volledige verbinding. Het is onjuist om dit te interpreteren alsof alle wachttijd verdwijnt.

Ten eerste blijft volgorde binnen één stream van belang. Als een eerder deel in dezelfde stream verloren gaat, zoals de body van een HTML-document of één grote afbeelding, kunnen latere gegevens in die stream niet volledig worden gebruikt totdat de vereiste volgorde is hersteld. Ten tweede: als data uit meerdere streams in één QUIC-pakket waren opgenomen, kan verlies van dat pakket meerdere van die streams tegelijk vertragen.www.rfc-editor.org↗

De voordelen van HTTP/3 kunnen daarom vooral merkbaar zijn op netwerken waar pakketverlies of herordening optreedt. Bij het bekijken van een kleine pagina op een bekabelde verbinding met lage latentie en weinig pakketverlies kan het verschil met HTTP/2 daarentegen klein zijn of verschillen afhankelijk van de meetomstandigheden. HTTP/3 is namelijk geen technologie die op magische wijze bytes verkleint; het is een architectuur die beperkt hoe ver wachttijd tijdens transport zich verspreidt.datatracker.ietf.org↗www.rfc-editor.org↗

Waarin verschilt QPACK van HTTP/3 van gzip?

HTTP/3 bevat een headercompressiemechanisme genaamd QPACK. Hierdoor kan gemakkelijk de indruk ontstaan dat HTTP/3 gzip omvat, maar ze worden op verschillende doelen toegepast. QPACK is ontworpen om headervelden in HTTP-verzoeken en -responsen, zoals Cookie, Content-Type en Cache-Control, efficiënt weer te geven. gzip en Brotli zijn contentcoderingen die response bodies zoals HTML, CSS en JavaScript comprimeren.datatracker.ietf.org↗www.rfc-editor.org↗

HPACK van HTTP/2 steunt op de aanname dat de status van headercompressie in volgorde wordt geleverd, maar die aanname is niet zonder meer toepasbaar op de onafhankelijke streamarchitectuur van QUIC. QPACK gebruikt afzonderlijke unidirectionele streams om de status van dynamische tabellen te beheren, zodat implementaties een evenwicht kunnen vinden tussen compressie-efficiëntie en het risico op headerblokkering.datatracker.ietf.org↗datatracker.ietf.org↗

Voor de feitelijke paginaprestaties is het nuttig om hun rollen als volgt te zien:

• gzip en Brotli: verkleinen het overdrachtsvolume van tekstbodies.
• QPACK: verbetert de overdrachtsefficiëntie voor request- en responseheaders.
• HTTP/3 en QUIC: beperken hoe transportvertragingen door meerdere verzoeken en verliesomstandigheden zich naar andere verzoeken verspreiden.
• Caching: voorkomt dat resources die al zijn ontvangen opnieuw worden overgedragen.
• Afbeeldings- en codeoptimalisatie: verkleint de hoeveelheid werk die überhaupt moet worden gedownload en verwerkt.

Dit zijn geen concurrerende keuzes waaruit je er één kiest; het zijn complementaire benaderingen voor verschillende bottlenecks.

Wat zijn de grotere bottlenecks in ervaren snelheid van webpagina's?

De laadsnelheid die gebruikers ervaren is geen enkel getal. De tijd totdat de server de eerste byte stuurt, de tijd totdat de belangrijkste content boven de vouw zichtbaar wordt en de tijd totdat knoppen en invoervelden reageren, kunnen elk door verschillende oorzaken worden vertraagd. Vooral LCP (Largest Contentful Paint) vertegenwoordigt het moment waarop de grootste afbeelding, het grootste tekstblok of de grootste video in de viewport wordt gerenderd, waardoor deze metriek nuttig is voor het beoordelen van de ervaring van de eerste pagina.web.dev↗

Een trage LCP betekent niet altijd dat netwerkcompressie de oorzaak is. web.dev beveelt aan bij het diagnosticeren van LCP onderscheid te maken tussen TTFB, vertraging bij het laden van resources, laadtijd van resources en vertraging bij het renderen van elementen. Zelfs als een afbeelding bijvoorbeeld snel downloadt, kan grote CSS rendering blokkeren, of kan de hoofdthread te druk zijn met lange JavaScript-taken om de afbeelding weer te geven.web.dev↗

Wanneer de afbeelding boven de vouw de bottleneck is

Het grootste element boven de vouw is vaak een afbeelding, zoals een grote productfoto op een productdetailpagina, een hoofdafbeelding op de homepage van een nieuwssite of een banner op een reispagina. In deze situatie biedt het inschakelen van gzip weinig hulp voor JPEG-, WebP- of AVIF-bestanden zelf. Effectiever is het om afbeeldingen te leveren die zijn afgestemd op hun weergaveafmetingen, geschikte moderne formaten te gebruiken en de LCP-afbeelding niet te vertragen met loading="lazy". Indien nodig kun je een prioriteitshint geven met fetchpriority="high", maar een hoge prioriteit zonder onderscheid aan veel afbeeldingen geven kan juist concurrentie veroorzaken.web.dev↗web.dev↗

Wanneer CSS en JavaScript de bottleneck zijn

CSS heeft renderblokkerende eigenschappen omdat het voorkomt dat content zonder styling verschijnt. Te grote CSS, CSS die niet nodig is voor de eerste weergave en synchroon geladen scripts kunnen de weergave van de hoofdcontent echter vertragen. Zelfs nadat de overdracht is voltooid, gebruiken grote JavaScript-bundles de hoofdthread van de browser voor parsing, compilatie en uitvoering; alleen de downloadgrootte met gzip verminderen is dus mogelijk niet voldoende.developer.chrome.com↗web.dev↗

JavaScript-prestaties moeten daarom afzonderlijk van compressie worden onderzocht. Mogelijke maatregelen zijn ongebruikte code verwijderen, functies die niet nodig zijn voor de eerste weergave lazy-loaden, lange taken opsplitsen en, waar mogelijk, server-side rendering of prerendering gebruiken zodat de eerste HTML kerncontent en resources voor ontdekking blootlegt. Server-side rendering kan echter ook de serververwerkingstijd verhogen en TTFB beïnvloeden, dus architectuurwijzigingen moeten met metingen worden beoordeeld.web.dev↗

Wanneer serverrespons en caching de bottleneck zijn

Wanneer TTFB lang is, kan de browser volgende resources moeilijk ontdekken voordat deze de HTML ontvangt. Veelvoorkomende oorzaken zijn een server die ver weg staat, langdurige databaseverwerking en personalisatie, onnodige redirects en onbenutte cachingmogelijkheden. HTTP/3 kan in deze situatie een deel van de overdrachtsfase verbeteren, maar verkleint niet rechtstreeks de tijd die de server nodig heeft om de eerste respons te genereren.web.dev↗

Caching verschilt qua karakter van andere prestatieverbeteringen. gzip verstuurt dezelfde data in een kleinere vorm, HTTP/3 verandert de verbindingseigenschappen die voor de gegevenslevering worden gebruikt, en caching voorkomt dat data bij daarvoor in aanmerking komende herhaalbezoeken opnieuw wordt verzonden. Voor een dienst met een groot aandeel terugkerende bezoekers kan een passend cachingbeleid een groter merkbaar verschil opleveren dan het veranderen van compressiealgoritmen. Cachingstrategieën voor responsen die vaak veranderen of per gebruiker verschillen, zoals HTML, moeten echter zorgvuldiger worden ontworpen.www.rfc-editor.org↗developer.chrome.com↗

Wat is de praktische rangorde van prestatieverbeteringen naar ervaren impact?

Er is geen vaste rangorde die voor elke site geldt. Resultaten verschillen op basis van paginasamenstelling, de verhouding tussen eerste en terugkerende bezoekers, gebruikersnetwerken, serverlocaties en bestaande configuratie. Toch is voor typische content-, commerce- en servicepagina's waar grote bottlenecks nog aanwezig zijn, de volgende onderzoeksvolgorde praktisch.

1. Zoek uit wat de kerncontent boven de vouw vertraagt. Onderzoek eerst de grootte, ontdekkingstijd en prioriteit van de LCP-afbeelding, renderblokkerende CSS, synchrone JavaScript en onnodige client-side rendering.web.dev↗
2. Beoordeel serverresponstijd en caching. Controleer TTFB, redirects, CDN-plaatsing, caching van statische assets en vertragingen in backendverwerking.web.dev↗www.rfc-editor.org↗
3. Controleer tekstcompressie voor HTML, CSS, JavaScript en JSON. Als deze niet zijn gecomprimeerd, heeft het toepassen van gzip of Brotli hoge prioriteit. Als ze al correct zijn gecomprimeerd, kan extra winst binnen hetzelfde gebied beperkt zijn.developer.mozilla.org↗developer.chrome.com↗
4. Verklein het totale overdrachtsvolume en optimaliseer de samenstelling van verzoeken. Ruim grote afbeeldingen, scripts en resources van derden op, en stel verzoeken uit totdat ze werkelijk nodig zijn. Grote netwerkpayloads worden geassocieerd met lange laadtijden.developer.chrome.com↗developer.chrome.com↗
5. Bied HTTP/3 aan, behoud een HTTP/2-fallback en valideer dit met echt verkeer. Vergelijk resultaten vóór en na de wijziging, vooral op mobiele omgevingen, omgevingen met hoge latentie en pakketverlies, en pagina's met veel gelijktijdige verzoeken.datatracker.ietf.org↗www.rfc-editor.org↗

Deze rangorde kent belangrijke uitzonderingen. Als een applicatie ongecomprimeerde tekstresponsen van meer dan 1 MB heeft, kan gzip of Brotli toepassen in stap 3 de grootste verbetering op korte termijn zijn. Als een hoofdafbeelding daarentegen meerdere MB groot is en tekst al met Brotli is gecomprimeerd, heeft afbeeldingsoptimalisatie prioriteit. Als de server meerdere seconden nodig heeft om HTML te genereren, gaan backend- en cachingwerk vooraf aan HTTP/3.developer.mozilla.org↗web.dev↗developer.chrome.com↗

Als je alleen gzip en HTTP/3 vergelijkt

Als je uitsluitend tussen deze twee technologieën kiest, is de beslissing relatief eenvoudig.

• Wanneer tekst niet is gecomprimeerd: gzip of Brotli komt meestal eerst. Dit verkleint de hoeveelheid te verzenden data, dus op elke ondersteunde verbinding zijn voordelen te verwachten.
• Wanneer compressie al correct werkt: de relatieve waarde van HTTP/3 neemt toe. De werkelijke verbetering hangt echter af van netwerkkwaliteit en verzoekstructuur.
• Voor pagina's met veel afbeeldingen en video: gzip noch HTTP/3 alleen lost waarschijnlijk het grotere probleem op. Mediaoptimalisatie komt eerst.
• Voor grote JavaScript-applicaties: gzip is slechts een beginpunt. Je moet ook uitvoeringskosten na de overdracht onderzoeken om een blijvende merkbare verbetering te bereiken.
• Voor diensten met veel herhaalbezoeken: cache-hitratio's kunnen een grotere variabele zijn dan het wijzigen van compressiemethoden.

Daarom is geen van beide conclusies — „gzip gaat altijd vóór HTTP/3” of „HTTP/3 is nieuwer, dus gaat het altijd voor” — juist. Een nauwkeurigere uitspraak is: contentcompressie is de basisprioriteit voor ongecomprimeerde tekst, terwijl HTTP/3 een fundamentele optimalisatie is die aanvullende voordelen kan bieden afhankelijk van transportomstandigheden en verzoekpatronen.

Met welke beperkingen moet je rekening houden bij de invoering van HTTP/3?

Om HTTP/3 aan te bieden, moeten servers, CDN's, load balancers, firewalls en observabilitytools QUIC- en UDP-gebaseerd verkeer correct kunnen verwerken. Omdat sommige clients of netwerkpaden HTTP/3 mogelijk niet kunnen gebruiken, is een geleidelijke uitrol die ook HTTP/2 of HTTP/1.1 biedt doorgaans passend. De HTTP/3-standaard is gebaseerd op QUIC en definieert het proces waarmee een client een HTTP/3-server ontdekt en vervolgens een QUIC-verbinding opzet.datatracker.ietf.org↗

Vanuit operationeel perspectief is het belangrijk om succes niet alleen op basis van een protocolwijziging te beoordelen. Monitor samen het aandeel HTTP/3-verbindingen, fouten- en retrypercentages, TTFB, LCP, foutpercentages en CPU-gebruik. Vooral wanneer een CDN of proxy voor de origin staat, kan het protocol dat bij de originserver zichtbaar is afwijken van het protocol dat de browser van de eindgebruiker werkelijk gebruikte; client-side observatie moet dus ook worden meegenomen.developer.chrome.com↗developer.chrome.com↗

Zijn er beveiligingsoverwegingen bij compressie?

Ja. Zelfs met HTTPS kan een aanvaller mogelijk een geheim afleiden door verschillen in ciphertextlengte te observeren als door een aanvaller beheerste invoer en geheime waarden samen in dezelfde compressiecontext worden gecomprimeerd. De HTTP Semantics- en HTTP/3-specificaties waarschuwen tegen situaties waarin gevoelige data en door een aanvaller beheerste data samen worden gecomprimeerd, en noemen het uitschakelen van compressie voor gevoelige data of het scheiden van compressiecontexten als de betrouwbaarste mitigaties.www.rfc-editor.org↗www.rfc-editor.org↗

Dit betekent niet dat elke gzip-respons gevaarlijk is. De kernvraag is of gereflecteerde gebruikersinvoer, authenticatiegerelateerde geheimen en omstandigheden waarin een aanvaller herhaaldelijk verzoeken kan doen en responsgroottes kan observeren, allemaal tegelijk bestaan. Op gevoelige flows zoals inloggen, betalingen en accountherstel mogen niet mechanisch dezelfde compressiebeleidsregels worden toegepast als op algemene statische assets; ze moeten samen met het beveiligingsontwerp worden beoordeeld.www.rfc-editor.org↗datatracker.ietf.org↗

Wat moet ik op mijn site meten?

Het is veiliger om prestatieverbeteringen te valideren aan de hand van echte gebruikerservaring dan via één laboratoriumscore. Lighthouse is nuttig om snel potentiële problemen te signaleren, maar vertegenwoordigt niet alle echte gebruikers op uiteenlopende netwerken, apparaten, cachestaten en in verschillende regio's. Door ontwikkelaarstools samen met real user monitoring te gebruiken, kun je hypotheses eenvoudiger van resultaten scheiden.developer.chrome.com↗developer.chrome.com↗

Je kunt prestaties in de volgende volgorde beoordelen:

1. Controleer de huidige overdrachtsstatus. Beoordeel in het Network-paneel Content-Encoding, overdrachtsgrootte en oorspronkelijke grootte voor belangrijke HTML-, CSS-, JS- en JSON-responsen.developer.chrome.com↗
2. Controleer het protocol. Bevestig in de kolom Protocol of werkelijke verzoeken h3, h2 of http/1.1 gebruiken.
3. Segmenteer belangrijke gebruikersstatistieken. Vergelijk TTFB, LCP en interactiestatistieken op eerste tegenover herhaalbezoek, mobiel tegenover desktop, regio en netwerktype.web.dev↗web.dev↗
4. Verander één ding tegelijk. Als je tegelijk gzip-inschakeling, Brotli-ondersteuning, afbeeldingsvervangingen, JavaScript-splitsing en HTTP/3-inschakeling uitrolt, is het moeilijk om vast te stellen welke wijziging effect had.
5. Leg ook neveneffecten vast. Monitor eveneens server-CPU, foutpercentages, cache-hitratio's en percentages van mislukte HTTP/3-verbindingen of fallbacks.

Als bijvoorbeeld een ongecomprimeerde JavaScript-bundel naar gzip overschakelt en de overdrachtsgrootte daalt maar LCP nauwelijks verandert, is de volgende bottleneck waarschijnlijk een grote afbeelding, CSS of JavaScript-uitvoering in plaats van compressie. Omgekeerd kun je, wanneer de lange staart van LCP voor gebruikers op mobiele netwerken verbetert na invoering van HTTP/3, voordelen in omgevingen met veel verlies en hoge latentie vaststellen naast het bekijken van gemiddelden. Dergelijke conclusies beginnen bij gemeten bottlenecks, niet bij de naam van een technologie.web.dev↗www.rfc-editor.org↗

Samenvatting: beschouw gzip en HTTP/3 als complementaire rollen, niet als een wedstrijd in rangorde

gzip en HTTP/3 zijn beide nuttig voor webprestaties, maar de basis voor hun vergelijking verschilt. gzip verkleint de verzonden bytes voor tekstresponsen, terwijl HTTP/3 via op QUIC gebaseerde gemultiplexte streams de impact kan beperken die netwerkverlies heeft op meerdere verzoeken. QPACK van HTTP/3 is headercompressie; het vervangt de bodycompressie van gzip en Brotli niet.www.rfc-editor.org↗datatracker.ietf.org↗datatracker.ietf.org↗

De meest praktische prioriteit is eerst de werkelijke bottleneck te identificeren tussen LCP, TTFB, renderblokkering, JavaScript, afbeeldingen en caching; tekstcompressie als basis toe te voegen als die ontbreekt; en HTTP/3 vervolgens onder omstandigheden met echte gebruikers te valideren. Prestaties draaien niet om het toevoegen van één nieuwste technologie — ze draaien om het inkorten van het langste pad waarop de gebruiker moet wachten.web.dev↗developer.chrome.com↗

Verder lezen

• HTTP Semantics- en contentcoderingsspecificatieswww.rfc-editor.org↗
• HTTP/3-standaarddatatracker.ietf.org↗
• QPACK-headercompressiestandaarddatatracker.ietf.org↗
• QUIC-transportspecificatiewww.rfc-editor.org↗
• Richtlijnen voor webprestaties en LCP-optimalisatieweb.dev↗
• Overzicht van HTTP-compressiedeveloper.mozilla.org↗