Navigatie overslaan
Deel IV Hoofdstuk 19

Compressie

Inleiding

Door het gebruik van HTTP-compressie laadt een website sneller en is daardoor een betere gebruikerservaring gegarandeerd. Het niet uitvoeren van compressie op HTTP zorgt voor een slechtere gebruikerservaring, kan de groeisnelheid van de gerelateerde webservice beïnvloeden en heeft invloed op de zoekresultaten. Effectief gebruik van compressie kan paginagewicht verminderen, webprestaties verbeteren, en is daarom een belangrijk onderdeel van zoekmachineoptimalisatie.

Hoewel compressie met verlies vaak acceptabel is voor afbeeldingen en andere typen media, willen we voor tekst compressie zonder verlies gebruiken, d.w.z. de exacte tekst herstellen na decompressie.

Welk type inhoud moeten we comprimeren?

Voor de meeste op tekst gebaseerde items, zoals HTML, CSS, JavaScript, JSON of SVG, evenals bepaalde niet-tekstindelingen zoals woff, ttf, ico, wordt het gebruik van compressie aanbevolen.

Een gestapeld staafdiagram met de gebruikssnelheid van verschillende compressiealgoritmen, uitgesplitst naar het inhoudstype. De gestapelde staven verdelen het gebruik van Brotli, Gzip en geen compressie. text/html is het enige inhoudstype dat minder dan 50% van de tijd wordt gecomprimeerd. application/json en image/svg+xml zijn elk ongeveer 64% gecomprimeerd. text/css en application/javascript zijn elk ongeveer 85% gecomprimeerd. application/x-javascript en text/javascript zijn voor meer dan 90% gecomprimeerd.
Figuur 19.1. Compressiemethoden voor verschillende inhoudstypen

De afbeelding toont het percentage reacties van een bepaald inhoudstype met Brotli, Gzip of zonder tekstcompressie. Het is verrassend dat hoewel al deze inhoudstypen zouden profiteren van compressie, het bereik van de percentages sterk varieert over de verschillende inhoudstypen: slechts 44% gebruikt compressie voor text/html tegen 93% voor application/x-javascript.

Voor op afbeeldingen gebaseerde middelen is op tekst gebaseerde compressie minder nuttig en wordt deze niet algemeen toegepast. Uit de gegevens blijkt dat het percentage afbeeldingsreacties dat Brotli of Gzip gebruikt, erg laag is, minder dan 4%. Voor meer informatie over niet op tekst gebaseerde middelen, bekijk het hoofdstuk Media.

Dit geeft aan welke compressiemethoden, indien van toepassing, worden gebruikt voor alle inhoudstypen die afbeeldingen zijn. Voor alle drie de afbeeldingstypen, d.w.z. jpeg, png en gif, wordt ongeveer 96,5% gebruikt, er wordt geen compressie gebruikt.
Figuur 19.2. Compressiemethoden voor afbeeldingstypen op desktop.

Hoe gebruikt u HTTP-compressie?

Om de grootte van de bestanden die we willen aanbieden te verkleinen, kan men eerst enkele minimizers gebruiken, bijv. HTMLMinifier, CSSNano of UglifyJS. Er worden echter grotere voordelen verwacht van het gebruik van compressie.

Er zijn twee manieren om de compressie aan de serverzijde uit te voeren:

  • Voorgecomprimeerd (middelen van tevoren comprimeren en opslaan)
  • Dynamisch gecomprimeerd (bestanden on-the-fly comprimeren nadat een verzoek is gedaan)

Omdat voorcompressie vooraf wordt gedaan, kunnen we meer tijd besteden aan het comprimeren van de activa. Voor dynamisch gecomprimeerde bronnen moeten we de compressieniveaus zo kiezen dat compressie minder tijd kost dan het tijdsverschil tussen het verzenden van een niet-gecomprimeerd versus een gecomprimeerd bestand. Dit verschil wordt bevestigd als we kijken naar de aanbevelingen voor compressieniveaus voor beide methoden.

Brotli Gzip
Voorgecomprimeerd 11 9 of Zopfli
Dynamisch gecomprimeerd 5 6
Figuur 19.3. Aanbevolen compressieniveaus om te gebruiken.

Momenteel wordt praktisch alle tekstcompressie uitgevoerd door een van de twee HTTP-inhoudscoderingen: Gzip en Brotli. Beide worden breed ondersteund door browsers: kan ik Brotli gebruiken/kan ik Gzip gebruiken

Als u Gzip wilt gebruiken, overweeg dan om Zopfli te gebruiken, die kleinere Gzip-compatibele bestanden genereert. Dit moet vooral worden gedaan voor voorgecomprimeerde bronnen, aangezien hier de grootste winst wordt verwacht. Zie deze vergelijking tussen Gzip en Zopfli die rekening houdt met verschillende compressieniveaus voor Gzip.

Veel populaire servers ondersteunen dynamisch en/of voorgecomprimeerd HTTP en veel van hen ondersteunen Brotli.

Huidige status van HTTP-compressie

Ongeveer 60% van de HTTP-reacties wordt geleverd zonder tekstgebaseerde compressie. Dit lijkt misschien een verrassende statistiek, maar houd er rekening mee dat deze is gebaseerd op alle HTTP-reacties in de dataset. Sommige inhoud, zoals afbeeldingen, zal niet profiteren van deze compressie-algoritmen en wordt daarom niet vaak gebruikt, zoals weergegeven in figuur 19.2.

Inhoud Codering Desktop Mobiel Gecombineerd
Geen Tekstcompressie 60,06% 59,31% 59,67%
Gzip 30,82% 31,56% 31,21%
Brotli 9,10% 9,11% 9,11%
Andere 0,02% 0,02% 0,02%
Figuur 19.4. Overname van compressie-algoritmen.

Van de bronnen die gecomprimeerd worden aangeboden, gebruikt de meerderheid Gzip (77%) of Brotli (23%). De andere compressie-algoritmen worden niet vaak gebruikt.

Een staafdiagram met de gebruikssnelheden van verschillende compressie-algoritmen voor HTTP-reacties. 77,39% van de HTTP-reacties die compressie gebruiken, maakt gebruik van het Gzip-algoritme, 22,59% gebruikt Brotli en 0,03% gebruikt een andere methode.
Figuur 19.5. Compressie-algoritme voor HTTP-reacties.

In de onderstaande grafiek worden de top 11 inhoudstypen weergegeven met vakgroottes die het relatieve aantal reacties vertegenwoordigen. De kleur van elk vak geeft aan hoeveel van deze bronnen gecomprimeerd werden bediend, oranje geeft een laag compressiepercentage aan, terwijl blauw een hoog compressiepercentage aangeeft. De meeste media-inhoud is oranje gearceerd, wat wordt verwacht aangezien Gzip en Brotli weinig tot geen voordeel voor hen zouden hebben. De meeste tekstinhoud is blauw gearceerd om aan te geven dat ze worden gecomprimeerd. De lichtblauwe arcering voor sommige inhoudstypen geeft echter aan dat ze niet zo consistent worden gecomprimeerd als de andere.

Boomkaart-diagram met afbeelding/jpeg (91.926.198 reacties - 3,27% gecomprimeerd), applicatie/javascript (80.360.676 reacties - 84,88% gecomprimeerd), afbeelding/png (66.351.767 reacties - 3,7% gecomprimeerd), tekst/css (54.104.482 reacties - 84,0% gecomprimeerd), tekst/html (48.670.006 reacties - 44,25% gecomprimeerd), afbeelding/gif (39.390.408 reacties - 3,42% gecomprimeerd), tekst/javascript (35.491.375 reacties - 90,74% gecomprimeerd), applicatie/x-javascript (22.714.896 reacties - 93,14% gecomprimeerd), applicatie/json (13.453.942 reacties - 63,02% gecomprimeerd), tekst/plain (4.629.644 reacties - 32,89% gecomprimeerd).
Figuur 19.6. Compressie op type op desktoppagina’s.

In figuur 19.1 hierboven wordt het percentage compressie gebruikt per inhoud-type uitgesplitst, in figuur 19.6 wordt dit percentage aangeduid met kleur. De twee figuren vertellen vergelijkbare verhalen: niet op tekst gebaseerde middelen worden zelden gecomprimeerd, terwijl op tekst gebaseerde middelen vaak worden gecomprimeerd. De compressiesnelheden zijn ook vergelijkbaar voor zowel mobiel als desktop.

Eerste-partij versus derden compressie

In het hoofdstuk Derden leren we over derden en hun invloed op de prestaties. Het gebruik van derden kan ook gevolgen hebben voor de compressie.

Desktop Mobiel
Inhoud Codering Eerste-Partij Derden Eerste-Partij Derden
Geen Tekstcompressie 61,93% 57,81% 60,36% 58,11%
Gzip 30,95% 30,66% 32,36% 30,65%
br 7,09% 11,51% 7,26% 11,22%
deflate 0,02% 0,01% 0,02% 0,01%
Anders / ongeldig 0,01% 0,01% 0,01% 0,01%
Figuur 19.7. Eerste-partij versus derden compressie per apparaattype.

Wanneer we compressietechnieken tussen eerste en derde partijen vergelijken, kunnen we zien dat inhoud van derden de neiging heeft om meer gecomprimeerd te worden dan eerste inhoud. Bovendien is het percentage Brotli-compressie hoger voor inhoud van derden. Dit komt waarschijnlijk door het aantal bronnen dat wordt geleverd door de grotere derde partijen die doorgaans Brotli ondersteunen, zoals Google en Facebook.

Vergeleken met de resultaten van vorig jaar, kunnen we zien dat er een aanzienlijke toename was in het gebruik van compressie, met name Brotli voor eerste-partijen, bijna tot het punt dat het gebruik van compressie ongeveer 40% is voor zowel eerste als derde partij, en voor desktop en mobiel. Binnen de reacties die wel compressie gebruiken, is voor eerste partijen de ratio van Brotli-compressie slechts 18%, terwijl de ratio voor derden 27% is.

Hoe u compressie op uw sites kunt analyseren

U kunt Firefox Developer Tools of Chrome DevTools gebruiken om snel uit te zoeken welke inhoud een website al comprimeert. Ga hiervoor naar het tabblad Netwerk, klik met de rechtermuisknop en activeer “Content Encoding” onder Response Headers. Als u over de grootte van individuele bestanden zweeft, ziet u “transferred over network” en “resource size”. Geaggregeerd voor de hele site kan men de grootte/overgedragen grootte voor Firefox en “transferred” en “resources” voor Chrome linksonder op het tabblad Netwerk zien.

Gebruik DevTools om te controleren of er inhoudscodering op uw site wordt gebruikt
Afbeelding die laat zien hoe DevTools te gebruiken om te zien of inhoudscodering wordt gebruikt.
Figuur 19.8. Gebruik DevTools om te controleren of er inhoudscodering op uw site wordt gebruikt

Een ander hulpmiddel om compressie op uw site beter te begrijpen, is de Google-hulpmiddelLighthouse, waarmee u een reeks audits op webpagina’s kunt uitvoeren. De tekstcompressie-audit evalueert of een site kan profiteren van aanvullende tekstgebaseerde compressie. Het doet dit door te proberen bronnen te comprimeren en te evalueren of de grootte van een object kan worden verminderd met ten minste 10% en 1.400 bytes. Afhankelijk van de score ziet u mogelijk een compressieadvies in de resultaten, met een lijst met specifieke bronnen die kunnen worden gecomprimeerd.

Omdat het HTTP Archive Lighthouse-audits uitvoert voor elke mobiele pagina, kunnen we de scores van alle sites samenvoegen om te zien hoeveel kans er is om meer inhoud te comprimeren. In totaal slaagt 74% van de websites voor deze audit, terwijl bijna 13% van de websites onder de 40 scoort. Dit is een verbetering van 11,5% in vergelijking met 62,5% van de passerende scores vorig jaar.

Gestapeld staafdiagram waarin de pagina's met scores worden opgesplitst die worden ontvangen voor de Lighthouse-audit “tekstcompressie inschakelen”. Het laat zien dat 7% van de sites minder dan 10% scoort, 6% van de sites scoort tussen 10-39%, 10% van sites scoort tussen 40-79%, 3% van sites scoort tussen 80-99% en 74% van de sites heeft een pas met meer dan 100% van de tekstitems die worden gecomprimeerd.
Figuur 19.9. Tekstcompressie Lighthouse scores.

Gevolgtrekking

In vergelijking met de Almanac van vorig jaar is er een duidelijke trend om meer tekstcompressie te gebruiken. Het aantal reacties dat geen gebruik maakt van tekstcompressie is met iets meer dan 2% gedaald, terwijl het gebruik van Brotli met bijna 2% is toegenomen. De Lighthouse-scores zijn aanzienlijk verbeterd.

Tekstcompressie wordt veel gebruikt voor de relevante indelingen, hoewel er nog steeds een aanzienlijk percentage HTTP-reacties is dat baat zou kunnen hebben bij extra compressie. U kunt profiteren door de configuratie van uw server onder de loep te nemen en de compressiemethoden en -niveaus naar wens in te stellen. Een grote impact voor een positievere gebruikerservaring zou kunnen worden bereikt door zorgvuldig de standaardinstellingen te kiezen voor de meest populaire HTTP-servers.

Auteurs

  • Moritz Firsching
    Moritz Firsching is software-engineer bij Google Zwitserland, waar hij werkt aan progressieve afbeeldingsindelingen en lettertypecompressie. Daarvoor deed Moritz onderzoek als wiskundige die polytopen bestudeerde.
  • Luca Versari
    Luca Versari is een software-engineer bij Google en werkt aan JPEG XL. Hij is bezig met het afronden van een doctoraat in grafiekcompressie en heeft een achtergrond in wiskunde.
  • Sami Boukortt
    Sami kwam bij Google nadat hij zijn studie technische wiskunde had afgerond. Na een paar jaar verre interesse in compressie, maakte hij er uiteindelijk in 2018 zijn fulltime werkonderwerp van.
  • Jyrki Alakuijala
    Jyrki Alakuijala is een actief lid van de open source-softwaregemeenschap en onderzoeker naar datacompressie. Jyrki werkt bij Google als technisch leider/manager, en zijn recent gepubliceerde werk was met Zopfli, Butteraugli, Guetzli, Gipfeli, WebP lossless, Brotli en JPEG XL-compressie-indelingen en -algoritmen, en twee hashing-algoritmen, CityHash en HighwayHash. Voordat hij bij Google ging werken, ontwikkelde hij software voor de planning van neurochirurgie en bestralingstherapie.