Nuance: Chrome gaat webpagina's sneller laden dankzij eigen compressie-algoritme

Google zet zijn compressie-algoritme in de aankomende release van zijn browser Chrome. Brotli moet vooral statische content op https-sites efficiënter kunnen inpakken. De integratie van Brotli zal echter voorlopig het browsen niet sneller maken, zoals veel media beweren.

Dat de aankomende integratie van Brotli in Chrome het laden van websites sneller zal maken, staat onder meer op Nu.nl en Android Planet, die dat op hun beurt lijken te hebben overgenomen van Engadget. Dat kan echter alleen gelden als bezoekers sites bezoeken die content aanbieden die gecomprimeerd is met Brotli. Dat geldt momenteel voor vrijwel geen enkele site. Bovendien werkt Brotli alleen voor https-verkeer en niet voor regulier bezoek aan veel sites. Google zou wel snel zijn eigen servers kunnen uitrusten met Brotli-ondersteuning.

Er lijkt Brotli-ondersteuning te komen in nginx. Veel sites gebruiken niet nginx, maar Apache of IIS, die beide dus voorlopig geen ondersteuning voor Brotli lijken te krijgen. Google zal zijn compressie-algoritme inbouwen in versie 49 van Chrome en nu is de functie dus al te gebruiken in de Canary-versie van de browser, die bij versie 50 zit. Brotli is daarin handmatig aan te zetten door het typen van chrome://flags#enable-brotli in de adresbalk en in de dropdown 'ingeschakeld' of 'enabled' te selecteren.

Als veel servers Brotli gaan ondersteunen, kan dat wel degelijk een positief effect hebben op onder meer de tijd die het kost om pagina's te laden bij trage verbindingen en het dataverbruik. Onder meer Cloudflare heeft al benchmarks gedaan op een testserver om de prestaties van Brotli te meten ten opzichte van onder meer gzip. Wanneer een groot deel van de servers content gaan comprimeren met Brotli, is momenteel niet duidelijk. Wel is bekend dat ook Mozilla het algoritme wil gaan gebruiken in Firefox.

Google kondigde zijn algoritme voor compressie in september aan, terwijl een Google-engineer op Google+ liet weten dat het in Chrome zou komen.

Reacties (38)

[rvt1]

Voordat je naar je server toe rent en gelijk Brorli installeerd kijk wel even op https://blog.cloudflare.com/results-experimenting-brotli/

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

Als ik zo zelf even snel over de resultaten kijk wacht ik het wel even af wat er verder mee gaat gebeuren, zeker voor mijn sites heeft het weinig zin, wellicht voor hele grote sites (Yahoo, google, etc...) en je hebt wat server power nodig voor goede compressie. We zullen het meemaken... over een jaar of 5?

[elmuerte]

Ze testen dan weer niet op decompressie snelheid en system resource usage (CPU en RAM) wat nogal belangrijk is voor ontvanger ongeacht of het dynamische of statische content betreft.

[MadEgg]

Decompressie is voor vrijwel elk compressialgoritme vrij eenvoudig. Het comprimeren is een puzzel mbt het samenstellen van de dictionary. Het decomprimeren is fixed business, de dictionary is vast en de references ook, dus het is een kwestie van een serie lookups uitvoeren. Ik verwacht dus, zeker gezien de gelijkenis tussen Brotli en gzip, nagenoeg geen verschil tussen Brotli en gzip wat betreft decompressie.

Dan nog is het niet heel relevant. Google ontwikkelt dit hoofdzakelijk om kosten in hun datacentra te besparen en niet om de kosten van de bezoekers te drukken. Daar zijn eenvoudigere methodes voor. Bovendien presteert zlib feitelijk meer dan voldoende voor de consument; het verschil in snelheid ga je niet merken en als je dan toch sneller pagina's wilt laden installeer je wel een adblocker, dat scheelt een heel stuk meer.

[atlaste]

Je gaat iets te kort door de bocht. Compressie komt in vele soorten en maten. Voor tekst zijn de twee meest gebruikte vormen echter Lempel-Ziv varianten (LZ*) en Flate (Deflate, ZLib, etc) gebaseerde varianten. Deze twee vormen werken beiden met een dictionary, die compleet anders wordt opgebouwd per vorm. Daarnaast wordt voor tekst in sommige gevallen de dictionary ge'seed' met een standaard taalmodel, zodat je niet vanaf nul hoeft te beginnen.

Brotli is een variant in de LZ familie, waarbij de dictionary begint met een seed. Het kenmerk van de LZ familie waarom het de laatste tijd zoveel wordt gebruikt, is dat je een betere compressie krijgt als je er meer geheugen tegenaan smijt.

Wat er eigenlijk gebeurt bij deze algoritmes is dat je het verleden vastlegt en bij eerder voorgekomen informatie (van voldoende grootte) een 'pointer' geeft naar iets wat je eerder al hebt gezien ipv. de informatie zelf. Dat kan uit als de pointer minder bytes kost dan de data zelf. De crux zit 'm in het comprimeren, omdat het uitvogelen welke pointer het beste kan worden gebruikt tijdsintensief en geheugenintensief is. Shortcuts daarin (zoals LZ4) leveren een minder goede compressie op met een betere snelheid.

De conclusie die je hebt onderstreep ik. Ik heb bij de aankondiging de specs van Brotli gelezen en ook ik was niet zo erg onder de indruk; simpel uitgelegd: er wordt met deze balans gespeeld en met seeds... Ik denk dat de 20% ook nog afhankelijk is van bijv. de taal van de website; vooral in het Engels zullen de seeds wel werken vermoed ik. Hoe dan ook denk ook ik niet dat je de snelheid gaat merken; if anything verwacht ik eerder dat het langzamer gaat als gevolg van extra latency dan sneller.

PS: Er zijn ook hele andere manieren om data te comprimeren. Om 1 voorbeeld te noemen (er zijn er vele): Arithmetic coding werkt bijv. niet met een dictionary. Wat je hier doet is dat je probeert 'de toekomstige tokens' te voorspellen en de verschillen tov. die tokens opslaat. Voor data die goed voorspelbaar is, comprimeert dit als een dolle.

[MadEgg]

Iets te kort door de bocht, zeker. Maar in het algemeen klopt het wel, bij alle populaire compressieformaten is decompressie-snelheid nagenoeg gelijk.

Ik zal eerlijk toegeven dat ik verre van een expert ben op het compressie-gebied, maar baseerde mijn uitspraak op de link die rvt1 hierboven gaf. Hierin wordt gesteld dat zowel gzip/deflate als Brotli gebaseerd zijn op een combinatie van huffman-codering en lz, met andere parameters. Hierbij is het meest significante verschil tussen de algoritmes in de samenstelling van de gebruikte dictionary, waarbij Brotli een pre-seeded dictionary gebruikt en bovendien een grotere window-size. Voor decompressie maakt dat allebei eigenlijk niet uit.

[atlaste]

Iets te kort door de bocht, zeker. Maar in het algemeen klopt het wel, bij alle populaire compressieformaten is decompressie-snelheid nagenoeg gelijk.

Nee juist dat punt is te kort door de bocht.

Artithmetic coding gaat met 1 GB/s. Ik heb een paar maanden geleden een variant op P/For geimplementeerd die met L2 speed (80 GB/s) decomprimeert. Varint coding gaat met een paar GB/s.

Dit zijn geen compressiealgoritmes die vrijwel niet gebruikt worden - integendeel, ik denk dat ze de dagelijks tegenkomt; je merkt het alleen niet. Dit zijn de compressie-algoritmes die in dingen als search engines en database systemen verstopt zitten "onder de motorkap" om te zorgen dat de hoeveelheid data niet explodeert.

De rest van het verhaal over dictionary-based compressie klopt wel. Vrijwel alle compressie algoritmes die op tekst en binary data werken gebruiken een dictionary based approach. De snelheid die je hiermee haalt is altijd een balans met geheugengebruik; memory lookups kosten het meeste tijd (dus als je een kleine buffer gebruikt die in je cache past, heb je hier minder last van en gaat het harder -- maar met een kleinere compressie ratio).

Andere compressie algoritmes:

- Tekst gebruikt meestal ook nog een simpele 'compressie' zoals UTF-8 of UTF-16, wat efficienter is dan gewoon alle unicode characters opslaan...
- ZIP files zijn containers. Het compressiealgoritme is standaard Deflate compressie (Huffman coding) - maar de files zijn eigenlijk een container voor verschillende compressie formaten. Bijv. images die al gecomprimeerd zijn (meestal met preprocessing + huffman coding), worden vaak uncompressed opgeslagen omdat dat efficienter is. Er moet bij worden opgemerkt dat praktisch altijd 'deflate' wordt gebruikt, ook vanuit historische redenen en de vele implementaties van ZIP.
- Een laatste noemenswaardige algorithme dat absoluut ook veel sneller is dan dictionary coding, is Run Length Encoding (RLE). Vroeger werd RLE gebruikt om BMP files te comprimeren. Op sommige plaatsen wordt dit nog steeds in JPEG gebruikt.

[Anoniem: 121170]

Andere interessante vernieuwende compressie is http://zstd.net van de maker van LZ4

[dmantione]

Zlib is niet alleen goed genoeg, het blijkt erg lastig om een algoritme te verzinnen dat het op alle punten overtreft. Op het gebied van de te behalen compressie zijn er meerdere doorbraken geweest, zoals bzip2 en lzma, alleen zetten die doorbraken enerzijds niet zoveel zodan aan dijk dat iedereen direct overstapt, anderzijds hebben ze ook nadelen t.o.v. zlib zoals snelheid en geheugengebruik. Alleen op plaatsen waar ruimte echt krap is worden ze ingezet.

In vergelijking met niet-exact omkeerbare compressies is bijv. H264 dusdanig veel beter dan MPEG2 dat het wel de moeite is erop over te stappen.

Brotli zou 20% kleinere bestanden opleveren dan zlib, en weinig nadelen t.o.v. snelheid. Anderszijs is er wel veel geheugen voor nodig en doet het i.v.m. het statische woordenboek aannames over de soorten gegevens die het efficiënt kan comprimeren. Misschien wetenschappelijk een flink doorbraak, maar t.ov.. lzma is de winst in bestandsgrootte waarschijnlijk peitlutterig, maar wel evenals lzma nadelen.

Conclusie: Zlib blijft de meest gebruikte compressienorm. Op het gebied van het serveren van webpagina's wordt zlib al weinig gebruikt, dus is al er helemaal weinig vraag naar betere algoritmen.

[elmuerte]

Dat is dus niet zo. Neem bijvoorbeeld LZO, ook een LZ compressie algoritme maar is in decompressie vele male beter dan DEFALTE want het is veel sneller. Dan is er LZ4, een verbetering van LZO in decompressie snelheid, maar heeft wel meer geheugen nodig.
Of een LZMA (wat door 7zip gebruikt wordt) heeft substantieel meer geheugen (en tijd) nodig voor compressie.

[RobIII]

Wat MadEgg zegt is dat de decompressie van algoritme X (vrijwel) altijd sneller zal zijn dan de compressie van datzelfde algoritme X. Dat decompressie van algoritme Y sneller/trager is t.o.v. dan decompressie van X, Q of Z is nogal wiedes.

[elmuerte]

Dat is helemaal niet relevant of decompressie van Y sneller is compressie van Y. Het gaat er om of decompressie van Y sneller is dan decompressie van X.

Verder is het niet altijd waar dat compressie langer duurt dan decompressie. Decompressie snelheid is niet altijd belangrijker dan compressie snelheid. Bij stream compressie moet je algoritme de data feed bij kunnen houden. Dat het dan langer duurt om te decompressen is minder belangrijk (wat dat gebeurt misschien op veel snellere hardware).

PPM algoritmes hebben vaak een (iets) slechte decompressie performance dan compressie performance.

[RobIII]

> Dat is helemaal niet relevant of decompressie van Y sneller is compressie van Y.

Dat heb ik ook niet gezegd (en MadEgg ook niet; sterker: dat geeft 'ie zelf ook aan )

> Verder is het niet altijd waar dat compressie langer duurt dan decompressie.

Daarom zeg ik ook "(vrijwel)"

[Reactie gewijzigd door RobIII op 27 juli 2024 14:15]

[Anoniem: 659271]

Helemaal in het begin had Chrome de belofte dat het supersnel was omdat de browser in tegenstelling tot IE vanaf de grond af opgebouwd was, geen poespas had en nog wat technische dingetjes.

Is van die belofte überhaupt nog wat over? Is Chrome net zo snel of zelfs sneller dan eerst? Iemand een idee?

[labmuisfrl]

Chrome lijkt bij mij vooral winst te halen als er veel javascript en jquery zaken worden geladen. Overall ook de snelste (mijn ervaring)

Maar in gebruik blijf ik het een gedrocht vinden. Ik houd het bij ff

[WoutervOorschot]

Chrome is iets stabieler dan Edge(of IE11) en firefox als je veel tabladen wilt openen bij launch, opstarten zonder dat soort fratsen duurt echter langer dan ieder ander. Javascript performance is soms sneller en soms langzamer dan Edge(chakra vs v8). Rendering is sneller op Edge, in de zin dat de pagina al kan worden gebruikt voordat deze volledig is gerenderd(vooral op mobiel zeer praktisch), qua pure laadtijd is chrome meestal iets sneller.

Chrome begint weer wat beter te worden, achtergrondtaken(notificaties zelf willen doen), eigen taakbeheer e.d. doen helaas erg af aan de performance en daarnaast ook aan de batterijduur van laptops/tablets.

[Anoniem: 145867]

Chrome is niet opgebouwd vanaf de grond. Laat dat naast je neer. Die bewering is fout. Ga eens kijken naar de geschiedenis van webkit bijvoorbeeld.

Tevens is Edge niet vanaf de grond af aan opgebouwd. Eigenlijk is dat gewoon IE11 zonder legacy code + heel veel development werk in de HTML engine.

[Reactie gewijzigd door Anoniem: 145867 op 27 juli 2024 14:15]

[Faeron]

Dit is weer de volgende stap van Google waarin het steeds meer en meer probeert te bepalen hoe het internet werkt. Over 10 jaar werkt het internet volledig volgens Google's voorschriften.

[Orthodroom]

Zolang dat open is zie ik daar niet direct een heel groot probleem in.

[dmantione]

Ik wel. Ik ben niet overtuigd van de noodzaak voor dit algoritme. Veranderen om te veranderen zorgt ervoor dat software onnodig verouderd. We zijn er net een beetje vanaf dat websites je vertellen dat je browser x.y.z. moet downloaden en verder dienst weigeren, ik heb geen behoefte dat dat terugkomt.

[Anoniem: 145867]

Ten eerste moet het populair worden. Ten tweede voordat het echt is ingeburgerd zal de rest van de browsers ook mee moeten gaan. Ik wil bijvoorbeeld graag web components gebruiken. Super gaaf, maar chrome is enigste die het helemaal ondersteund. De andere browsers maar mondjesmaat. Dan kun je het alsnog niet gebruiken.
Als het opensource is dan zal browser x.y.z. natuurlijk makkelijker deze zaken implementeren. En veel browser ontwikkelaars zoals het Chrome team, Firefox team en Edge team praten gewoon veel met elkaar en helpen elkaar. Het is geen echte vijandige sfeer hoor.

[RoestVrijStaal]

De openheid is geen probleem.

Het probleem is dat Google nu met een eigen "oplossing" komt. Als andere bedrijven als FaceBook, Apple, Amazon, Microsoft et al ook een inbreng willen brengen, betekent dat die snel moeten rennen om tijdig met hun inbreng te komen voordat Google's inbreng gemeengoed is.

Zoiets zie je nu al gebeuren met de css-vendor-prefixes van Chrome.

OpenXML is ook een open standaard. Maar wie heeft er in de praktijk het meeste profijt van?

[Reactie gewijzigd door RoestVrijStaal op 27 juli 2024 14:15]

[Tralapo]

Google's SPDY is ook grotendeels de basis voor de inmiddels nieuwe standaard HTTP/2. Wat is daar mis mee?

Zo lang een dergelijke partij als Google de resources en de drang heeft om dergelijke zaken te ontwikkelen en daarmee alle juiste partijen een duwtje in de goede richting geeft is dat toch eigenlijk alleen maar fijn?

[NTAuthority]

... als dit een Content-Encoding is (en dus een HTTP-feature, application-layer dus), waarom zou dit dan enkel over TLS (i.e. HTTPS) werken? Is dit deel van de opzettelijke sabotage van niet-authenticated HTTP door browsermakers zoals ook bedoeld door Mozilla?

[Gert]

Omdat https verkeer meestal ongestoord door eventuele tussenstations (zoals proxies) mag fietsen. Zolang client en server het ondersteunen en afstemmen zit het goed. Bij http moeten die proxies ook brotli ondersteunen anders gaat het niet goed. Het is dus puur een keuze om een succesvolle implementatie waarschijnlijker te maken.

[NTAuthority]

Ah, daar had ik niet aan gedacht - er zijn vast 'kapotte' proxies welke Accept-Encoding wel ongewijzigd doorsturen maar daarbij de teruggegeven encoding niet correct afhandelen.

[locke960]

Het is ook zinvol bij normale verbindingen voor de steeds groter wordende pagina's. Bijv. dit artikel:
Tekst, Artikel + comments : 7KB
HTML pagina: 55KB
Totale download (html, css, javascript, plaatjes): 670KB

En dan doet Tweakers het nog beschaaft.
Het meeste van die 670KB is ook zeer goed te compressen, in deze pagina zitten nauwelijks plaatjes, het is allemaal tekst.

edit: was een reaktie op Ventieldopje

[Reactie gewijzigd door locke960 op 27 juli 2024 14:15]

[MadEgg]

En dan even goed kijken... dan zie je dat Tweakers.net, natuurlijk, gewoon gzip gebruikt waardoor de totale omvang feitelijk maar 190,5 KB is.

[AmbroosV]

Good to know: Facebook heeft Google heel erg liggen pushen om experimentele Brotli-ondersteuning zo snel mogelijk in Chrome te steken zodat ze tests kunnen beginnen doen. Ik vermoed dat ze daar hun statische resources klaar hebben staan in Brotli voor een grootschalige test. (Bij HTTP/2 en SPDY waren ze er ook snel bij. Voor een bedrijf met zoveel traffic als Facebook kan iets als Brotli een significante hoeveelheid traffic besparen.)

[Anoniem: 145867]

Voor grote jongens zoals Facebook is elke procent winst gigantisch natuurlijk. Voor Google bijvoorbeeld bij Youtube video's beter comprimeren en opslaan bespaard natuurlijk ook gigantische data. Voor de gewone simpele wordpress pagina's en andere pagina's heeft dit soort zaken echt totaal geen nut. Dan is het ineens te verwaarlozen.

[gassie123]

Dit is nou waarom ik graag tweakers.net lees. Toch net even wat beter uitgelegd dan op die standaard nieuws sites.

[timmiej93]

Precies wat ik wou zeggen. Had het bij nu.nl ook al in de comments gelezen, maar vind het toch altijd wel zo fijn om het meteen uit betrouwbare bron te horen.

[Herko_ter_Horst]

Moet zeggen dat die andere sites dan ook niet heel diep hebben nagedacht. Het zou wel héél knap zijn als compressie aan de ontvangende kant iets zou doen met de laadsnelheid...

[Jogai]

Veel sites gebruiken in plaats van nginx Apache of IIS, die beide dus voorlopig geen ondersteuning voor Brotli lijken te krijgen.

Dat klopt, maar als je met brotli inpakt van te voren maakt dat niet uit. Dit kan als je een node pipeline voor je build gebruikt met: https://github.com/MayhemYDG/iltorb (via gulp: https://www.npmjs.com/package/gulp-brotli)

[Reactie gewijzigd door Jogai op 27 juli 2024 14:15]

[Ventieldopje]

Leuk, maar wederom zo'n techniek die mij alleen zinvol lijkt bij een trage (mobiele) verbinding waarbij de data overdracht zelf traag is (de request latency buiten beschouwing laten dus). Ik zie veel meer in HTTP/2 welke multiplexing ondersteund. Blocking van requests lijkt mij een veel groter probleem, zeker bij verbindingen met een hogere latency (zoals mobiele data verbindingen).

[Yggdrasil]

Dat dacht ik ook. Multiplexing, header-compressie, etc. hebben veel effect. Maar mogelijk is HTTP/2 voor partijen als Google en Facebook alweer gemeengoed. Zij ondersteunen dit immers al maanden op hun sites en kijken weer naar de verdere toekomst.

[Peter]

Op het moment dat een aantal grote partijen zoals CDNs, Facebook en Google's eigen sites dit oppakken zit je toch al redelijk snel op een significant percentage van het browsing-verkeer.

Daarnaast maakt statische content het meerendeel van veel pagina's uit— er is natuurlijk geen verplichting om alle content met een bepaald algorithme te comprimeren. Pick the best tool for the job.