Ny komprimeringsalgoritme gør Chrome-browseren endnu hurtigere

Google har udviklet en ny algoritme til at komprimere web-data kaldet Brotli, som sandsynligvis bliver lanceret i næste Chrome-opdatering. Den er op til 26 pct. mere effektiv end forgængeren.

Vores tålmodighed med at indlæse websider er dalende - ikke mindst på mobilen - og derfor arbejder browserproducenterne løbende med at tweake hastigheden.

Et af de centrale elementer her er de algoritmer, der blandt andet komprimerer billeder og forbehandler web-indhold, så det kan indlæses hurtigere i browseren.

Google har netop annonceret, at selskabets nyudviklede komprimeringsalgoritme Brotli er på vej til Chrome - sandsynligvis i næste opdatering af browseren ifølge tech-mediet Engadget. Algoritmen er desuden open source.

Brotli er 20 til 26 pct. mere effektiv end forgængeren Zopfli, som Google lancerede for tre år siden. Algoritmerne er især brugbare til hjemmesider med særlige web-fonte, der kan være tunge at downloade. Hvor stor betydning det får for hastigheden i Chrome, har Google ikke beskrevet.

Brotli er ifølge Google et helt nyt dataformat, der gør det muligt at pakke mere data sammen end andre komprimeringsformater og i nogenlunde samme hastighed. Således skulle Brotli være nogenlunde lige så hurtig som zlib’s deflate-implementering, samtidig med at den komprimerer en anelse tættere end LZMA og bzip2.

Resultatet skulle ifølge Google være, at de komprimerede filer fylder mindre. På mobiler vil det reducere data- og batteriforbruget.

Brotli er i øvrigt - som sin forgænger Zopfli - navngivet efter schweizisk bagværk. Brötli betyder ‘lille brød’.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Kommentarer (9)

Brian Hansen

Og hvis man slår JavaScript fra, så er internettet pludselig en helt anden oplevelse.
Det er faktisk det største problem på min Windows Phone :/

Stig Johansen

Jeg tror ikke rigtig jeg forstår det her.
Det er fint nok at udvikle en ny slags komprimering, men komprimering foregår jo serverside, så det forudsætter implementering på serverne før det er relevant.

Dekomprimering, f.eks. deflate (som er gzip uden header og trailer) koster næsten ingen ressourcer i forhold til komprimering (serverside).

Man kan med fordel indføre en cache, der håndterer 'for-zippede' data, eksempelvis Varnish.

Rune Jensen

men komprimering foregår jo serverside, så det forudsætter implementering på serverne før det er relevant.

Det har du da sådan set ret i. Det ville jeg også godt vide. Er de ikke nødt til at lave aftaler med Microsoft, som vel står bag en del Windows servere? Og i så fald, er de vel også nødt til at have W3C med på råd, ellers kan man vel ikke kalde det en standard...

Carit Benike

Hvis webserveren kan se at klienten browser med Chrome aktiveres komprimeringen, er mit gæt.
Muligheden for at benytte algoritmen på MS web-server platform, afhænger vel af hvilken licens koden er underlagt.

Johnnie Hougaard Nielsen

Dekomprimering, f.eks. deflate (som er gzip uden header og trailer) koster næsten ingen ressourcer i forhold til komprimering (serverside).

Når Brotli giver væsentligt bedre komprimering end deflate, er der en pointe i at sende færre data til mobiltelefonen. Altså bedre hastighed og mindre forbrug af data. At den endda typisk er lidt hurtigere end deflate, er så blot en ekstra fordel.

Da serveren typisk ud fra headere kan se se hvad browseren supporter af komprimerings metoder, er det ikke noget problem for dem som ønsker den bedre effektivitet for både server og klient at bruge Brotli. Og det kunne jo føre til at server administratorer efterspørger at deres web server kan give den bedste service.

Konkret ser det ud til at Google bruger MIT licensen, så det skulle ikke være noget problem for andre http server / browser leverandører at implementere komprimeringen, med mindre det er noget politisk.

Jeppe Toustrup

Browsere sender en Accept-Encoding header med hver request, der indeholder en liste af de forskellige komprimeringsalgoritmer som browseren understøtter. Det kan serveren så bruge til at vælge en algoritme som den selv understøtter, og sende dataen komprimeret eller ej.

Dermed behøver der ikke være en bred understøttelse for nye komprimeringsalgoritmer før de kan tages i brug, da det blot kræver at browser og server er enige.

Michael Zedeler

Det er ikke nogen god overskrift, denne artikel har. Google har foreslået en ny, fælles komprimeringsalgoritme, som først for alvor bliver noget værd, hvis mange leverandører vælger at bruge den.

I udgangspunktet gør den absolut ikke Chrome hurtigere.

Ivo Santos

Vores tålmodighed med at indlæse websider er dalende - ikke mindst på mobilen - og derfor arbejder browserproducenterne løbende med at tweake hastigheden.

Hvis nu hjemmesiderne bestod af f.eks. 1 procent javascript kode og resten ren html, og ikke som f.eks. Facebot som består af ca. 90 procent javascript og 10 procent html så havde det ikke været nødvendigt at vente i op til et halv minut på at en side bliver indlæst. derudover er der alle de der tracker og reklame javascripts som også kan tage en del tid at indlæse, og til sidst kan man også slanke selve siderne, og her er danske medier, som f.eks. berlingske tidende, et godt eksempel på at siderne indholder alt for meget som ligeledes ikke er nødvendigt.

Jeg må tilstå at det er indenfor de sidste ca. 5 år at jeg er begyndt at slå javascript fra som standard.
For ti år siden var det at gå ind på en hjemmeside ikke noget problem, og man kunne nøjes med at have alt aktiveret, men sådan er det tilsyneladende ikke længere.

Johnnie Hougaard Nielsen

Google har foreslået en ny, fælles komprimeringsalgoritme, som først for alvor bliver noget værd, hvis mange leverandører vælger at bruge den.

Selv om alene Google brugte den (Firefox er allerede også med på vognen), står Google for så meget af Internet trafikken at det allerede her giver en ikke uvæsentlig gevinst for både Google og brugerne af Chrome browseren.

Når udgangspunktet altså er at Chrome browseren bliver en tand hurtigere er der ikke noget galt med overskriften.

Og jeg er overbevist om at andre store indholdsleverandører, som fx Facebook, ser med interesse på muligheden for at reducere hvor mange terabyte de skal pumpe ud på fibrene.

Log ind eller opret en konto for at skrive kommentarer