Google brengt Zopfli-compressiealgoritme voor statische webcontent uit

Google heeft een nieuwe compressiebibliotheek met de naam Zopfli geïntroduceerd. Het deflate-compatibele compressiealgoritme levert 3,7 tot 8 procent kleinere bestanden op en is vanwege de benodigde rekenkracht vooral geschikt voor statische webcontent.

De ontwikkelaars van Google hebben zich bij Zopfli, dat zijn naam dankt aan een Zwitsers vlechtbrood, laten inspireren door de compressieverbeteringen van de lossless mode van de webp-beeldcompressie van het bedrijf. Zopfli, geschreven in C, is compatibel met 'deflate' en daardoor ook gelijk met de zlib- en glib-bibliotheken.

Volgens Google resulteert het gebruik van de Zopfli-compressie in bestanden die 3,7 tot 8 procent kleiner zijn dan met andere deflate-compatibele algoritmes. Zopfli vergt wel meer van de processor: uit testen van Google met verschillende datasets was Zopfli bij de maximale compressieratio 81 keer langzamer dan het snelste algoritme in de test. Het uitpakken van met Zopfli gecomprimeerde bestanden nam daarentegen de kortste tijd in beslag.

Google denkt dat Zopfli interessant kan zijn voor statische webcontent, waarbij de compressietijd van ondergeschikt belang is. Zo levert het nieuwe compressie-algoritme bestanden op die minder opslagruimte innemen en sneller verstuurd kunnen worden. Bovendien kan de laadtijd van webpagina's gereduceerd worden. Voor mobiele toepassingen heeft Zopfli volgens Google als voordeel dat gebruikers minder snel door hun databundel heen zijn en dat ze langer met hun accu kunnen doen.

Reacties (28)

[GewoonWatSpulle]

Grappig dat iets veel langzamer inpakt als uitpakt, je zou toch verwachten dat die tijden altijd vrij dicht bij elkaar in de buurt blijven liggen?

Edit: Inderdaad nu een stuk logischer met de uitleg hier beneden.

[Reactie gewijzigd door GewoonWatSpulle op 25 juli 2024 09:25]

[Bob]

Nee, veel compressiealgoritmes bevatten brute force achtige stukken code die de beste instellingen proberen te vinden om een bepaald bestand te comprimeren. Tijdens het uitpakken moeten die instellingen gelezen en uitgevoerd worden, wat relatief eenvoudig is. Anders gezegd, tijdens compressie moet er naar een oplossing gezocht worden, tijdens decompressie hoeft dat niet meer en is het gewoon enkele stappen uitvoeren om je originele data terug te krijgen.

[Vaevictis_]

Het is niet voor niets een asymmetrisch compressie algorithme. Omdat er voor het compressen van een bestand verschillende technieken worden toegepast zoals woordenboeken (LZMA) en andere statistische algorithmes. Doordat dit NA elkaar worden toegepast is het compressen altijd langzamer dan het decompressen.

Het idee is ook dat een bestand maar 1x hoeft te worden gecompressed en heel veel gedecompressed dus belangrijk dat het laatste erg snel is.

zie http://en.wikipedia.org/w...iv-Markov_chain_algorithm

Door gebruik te maken van een cache (Reverse Proxy) zoals Varnish kun je zorgen dat de backend niet wordt belast door door het opvragen van statische content.

[Reactie gewijzigd door Vaevictis_ op 25 juli 2024 09:25]

[Schnoop]

Eerder logisch. Bij het inpakken moet er gekeken worden hoe een bestand het beste gecomprimeerd moet worden door bijvoorbeeld te kijken naar stukken van het bestand welke het zelfde zijn of lange 00000000 reeksen. Bij het uipakken wordt er gewoon verteld waar wat moet staan, iets wat minder rekenkracht kost.

[Dykam]

Niet persé. Een niet helemaal correct analogie is het inpakken van een garage. Als je veel tijd besteed aan zorgvuldig plannen tijdens het inpakken, kan je het heel snel uitpakken.

[EJlol]

Ik heb geen idee hoe Zopfli werkt, maar ik kan me voorstellen dat hij tijdens het inpakken moet analyseren op welke manier het op de meest efficienste ingepakt moet worden. Dit hoeft uiteraard niet tijdens het uitpakken.

[Snake]

Hoe kan het compatibel zijn met een bestaand algoritme? Die begrijpt toch niet de nieuwe dingen die toegepast worden op de content?

[mddd]

Er worden dus ook geen nieuwe dingen toegepast op de content. Alleen de manier waarop bedacht wordt welke dingen, in welke volgorde, worden toegepast, die is verbeterd.

Een simpel voorbeeld: stel dat je compressie-algoritme de mogelijkheid heeft dat hij herhalende stukjes kan verkorten. "aaaaaa" wordt bijvoorbeeld "6a". En stel dat je een bestand hebt met de inhoud "aaabbbcccdddaaabbbcccdddaaabbbcccddd" dan zou een minder efficiënte variant dat inpakken als "3a3b3c3d3a3b3c3d3a3b3c3d" maar een slimmere variant zou zeggen "3aaabbbcccddd". Het is dus prima mogelijk om op basis van dezelfde regels toch tot een slimmer resultaat te komen.

NB: Natuurlijk is dit versimpeld, het is dus niet mijn bedoeling om met dit voorbeeld een volledig sluitend compressie-algoritme weer te geven. Het gaat om het idee, niet om de details.

[Reactie gewijzigd door mddd op 25 juli 2024 09:25]

[ATS]

En deze maakt er dus waarschijnlijk meer iets van als "3(3a3b3c3d)"

[Qua Salébra]

Interessant dat Google een deflate-compatible algoritme heeft ontwikkeld dat beter inpakt, terwijl het tegelijkertijd compatibel blijft. Minder interessant is echter dezelfde compatibiliteit. Er zijn veel algoritmes die beter inpakken met dezelfde of hogere snelheid dan 81x langzamer dan deflate.

Blijkbaar is het web zo ingericht, dat er alleen op een gemakkelijke manier gebruik gemaakt kan worden van deflate-compatible compressie. Anders hadden ze wel geprobeerd om LZMA2, of een soortgelijke library te gebruiken/optimaliseren.

[Mr_Light]

Net zo als bij Content negotiation is er ook voor encoding een header(Accept-Encoding) waarin de ondersteunde compressie algoritmes kunnen worden aangegeven door de client waarna de server kan kiezen tussen deze of terug te vallen naar niet encoden. In het kort is het protocol forward compatible. Deflate wordt z'n beetje iedereen ondersteund en dit nieuwe algoritme is hierdoor dus ook backwards compatible.

Waarom er niet ondersteuning for andere algoritmes zijn geïmplementeerd in browsers, eerlijk gezegd geen idee. Hier kan je zien dat in jan van 2007 al voorgesteld is om in firefox lzma(2) ondersteuning toe te voegen, gezien deze nog open is was er toen niet genoeg animo voor. (grappig genoeg is nu, door dit nieuwe algoritme, dit oude issue weer actief geworden.)

//edit spelling

[Reactie gewijzigd door Mr_Light op 25 juli 2024 09:25]

[hackerhater]

Het web op zich niet, maar als je een andere gebruikt heb je weer een probleem aan de kant van de browsers.

[biglia]

Moet er dan aan de client (browser update) ook iets veranderen zodat statische content uitgepakt kan worden met deze nieuwe compressiealgoritme? En wat als bepaalde browsers het niet gaan ondersteunen?

[jj71]

Nee, want het is compatibel met het Deflate algoritme, één van de standaard algoritmes die met ZIP compressie worden toegepast. Voor de client ziet het er dus uit als willekeurige andere ZIP data. Zopfli is alleen een nieuwe manier om het in te pakken zodat de data nog meer gecompressed wordt.

[Verwijderd]

De extra rekenkracht benodigd voor de compressesie van statische content kun je natuurlijk omzeilen door ze van te voren te compressen en gebruik te maken van bijvoorbeeld de HttpGzipStaticModule van Nginx. Of de content op te vangen in een reserve proxy als Varnish .

[jj71]

Dat is dan ook precies waarom dit vooral geschikt is voor statische webcontent - omdat je dat maar één keer hoeft in te pakken en dan ingepakt in een cache kunt laten staan.

Je moet dit niet gebruiken om voor elk request de responsedata in te pakken, dan ben je heel veel onnodig rekenwerk aan het doen.

[Pep7777]

Grappig hieruit kan je dus gelijk concluderen dat het verzenden/ontvangen van data meer batterij vreet dan rekenkracht. Of heb ik het mis?

[NasICT]

Zopfli zorg voor kleinere bestanden:

Volgens Google resulteert het gebruik van de Zopfli-compressie in bestanden die 3,7 tot 8 procent kleiner zijn dan met andere deflate-compatibele algoritmes.

EN is sneller uit te pakken:

Het uitpakken van met Zopfli gecomprimeerde bestanden nam daarentegen de kortste tijd in beslag.

[Verwijderd]

Volgens mij heb je het mis. Het onvangen gaat sneller omdat het kleiner is (dus minder verbruik) en het uitpakken gaat sneller (dus minder verbruik).

[Verwijderd]

Het uitpakken van met Zopfli gecomprimeerde bestanden nam daarentegen de kortste tijd in beslag.

Als het zwaarder zou zijn, zou het toch juist langer duren..?

[Reactie gewijzigd door Verwijderd op 25 juli 2024 09:25]

[Mr_Light]

Spraakverwarring hier:
Pep7777 heeft het over compressie vs geen compressie.
Nightspirit heeft het over huidige compressie techniek vs deze nieuwe.

Ja zenden kan best minder energie kosten - ook omdat de rest van de telefoon dan 'wakker' is om het boeltje te verwerken - dan het aan energie kost om het uit te pakken. Maar belangrijkste reden is dat de pagina sneller laad omdat over het algemeen de bandbreedte de beperkende factor is.(bij huidig mobiel verkeer)

Wanneer je in de cloud je servers draait kan het ook zo zijn dat je een premium betaald voor het bandbreedte verbruik en cpu tijd relatief weinig kost, zelfs in de situatie van on de fly comprimeren.

[ATS]

Nee, want de input data is kleiner dan van de competitie. Dat maakt het uitpakken sneller, omdat het algoritme voor het uitpakken verder hetzelfde is. Minder data lezen en zelfde hoeveelheid uitschrijven resulteert in sneller uitpakken.

[Zjosh]

Het dikgedrukte stuk text zette me in eerste instantie op het verkeerde been: Het deflate-compatibele compressiealgoritme levert 3,7 tot 8 procent kleinere bestanden..

Dat zou een behoorlijk brak compressie algortime zijn als je het mij vraagt. Blijkt dus dat het zoveel kleiner is dan de beste andere deflate compatible compresser, behoorlijk wat anders. Misschien handig om dat dikke stuk text wat aan te passen.

[Fuzzillogic]

Dit nieuwe algoritme is dan ook bruikbaar op png-afbeeldingen lijkt me? Toch weer een mooie winstpakker.

[Verwijderd]

Mooi dat nog mensen zijn die zich bezighouden met het verbeteren van algoritmes.

[ErwinMeulman]

Ik begrijp niet dat google voor video's (youtube) geen lossless video compressie gebruikt bij het gebruik van screencast. Hiermee zijn compressies van meer als 90% te behalen.