Szerző: Gálffy Csaba

2015. április 27. 14:24

Képeken spórol a mobilos Chrome tömörítője

Nem mobilra optimalizált a legtöbb webes tartalom - kezdi a Google mérnökei által publikált kutatási beszámoló. A Flywheel fejlesztése kapcsán gyűjtött tapasztalatokat összefoglaló dokumentum érdekes felhasználási statisztikákat is tartalmaz, ebből szemezgettünk.

Érdekes kutatási beszámolóban tette közzé adattömörítési szolgáltatásához kapcsolódó felhasználási adatokat a Google. A Flywheel a mobilos (iOS és Android) Chrome beépített képessége, (kérésre) képes a weboldalakat előre tömöríttetni a Google szervereivel, így csökkentve a mobilhálózatos forgalmat. Ez logikus, mivel világszerte elterjedt az adatforgalmi limit a mobilos kapcsolatok esetében, így van értelme a megtakarításnak.

Képek adják a megtakarítás nagy részét

A statisztikák szerint a forgalom csökkentésében a képek újratömörítése viszi a pálmát, ez az egy fogás önmagában felel a megtakarítások 85 százalékáért. Ezt a Google úgy éri el, hogy a különböző képformátumokat egységesen WebP-re konvertálja, veszteséges tömörítéssel. A dokumentum szerint a tömörítés szintjét saját kutatások alapján lőtték be a fejlesztők, de elsőre kicsit túlságosan erős lett, a képeken tömörítési hibák (artifacts) jelentek meg, a felhasználói panaszok alapján így a végső implementáció kevésbé agresszív a méretcsökkentésben.

Érdekes, hogy a Flywheel alapfilozófiája expliciten előírja az opt-in, vagy alapértelmezetten kikapcsolt működést, és a Google (legalábbis egyelőre) ezen nem is akar változtatni. Ennek eredménye, hogy jelenleg a mobilos Chrome-felhasználóknak mindössze 9 százaléka használja a tömörítést. A Flywheel-alapú elérés ugyanakkor nem csak mobilhálózaton, hanem Wi-Fi-n is aktív, az oldalletöltések 78 százaléka az utóbbit használja, 11 százalék zajlik 3G-n, 9 százaléka 4G-n és mindössze 1 százaléka valamelyik 2G-s szabványt.

A használati adatokból még szaftosabb részletek is kiderülnek. A Flywheel ugyanis nem aktív a HTTPS-t használó oldalaknál és az inkognitó módban megnyitott oldalakon (ez a Google önként vállalt korlátozása), a letöltött adatmennyiségnek pedig egészen meglepő aránya ebbe a két csoportba tartozik: HTTPS-en a letöltött bájtok 37 százaléka utazik, és további 13 százalékot tesz ki a "pornómód", vagyis mindössze 50 százalék (forgalom szerint) a Flywheelen átfutó adatmennyiség aránya.

Miért nem beszélni AI tökéletesen magyart?

Milyen kihívásokat tartogat egy magyar nyelvi modell, például a PuliGPT fejlesztése?

Miért nem beszélni AI tökéletesen magyart? Milyen kihívásokat tartogat egy magyar nyelvi modell, például a PuliGPT fejlesztése?

A tömörítéssel elvben csökkenthető lassú adathálózaton az oldalak betöltési ideje is, az eddigi használati statisztikák szerint azonban nem ez a helyzet, a Flywheel átlagosan 6 százalékkal növeli a betöltődéshez szükséges időt. Ennek az az oka, hogy a szerver közbeiktatása jelentősen megnöveli a késleltetést, miközben az átviteli sebesség az esetek túlnyomó többségében nem szűk keresztmetszet (lásd feljebb a Wi-Fi használati arányát).

Szintén az izgalmas műszaki részletek közé tartozik, és jól illusztrálja, hogy a webet nem adatkorlátos csomagokhoz tervezték, a 404-es válaszok problémája. A Flywheel-adatok szerint a 404-es válaszok a teljes lekérések 0,07 százalékához érkeznek, mégis ezek teszik ki a teljes adatforgalom 2 (!) százalékát. Ennek oka, hogy az oldalak 404-es válaszai hatalmasak, átlagosan 3,3 kilobájtosak, ilyent generálnak például a favicon és apple-touch-icon lekérések is, ha nincs az oldalon a megfelelő erőforrás. A Flywheel ezeket a hibaüzeneteket kondenzálja, a fent említett esetben mindössze 68 bájtos választ küld le a böngészőnek. Hasonló trükkök százait veti be a rendszer ezen felül is, mint a JavaScript és HTML minifikáció, stb.

A Flywheel képességeinek kiterjesztésén természetesen továbbra is aktívan dolgoznak a mérnökök, az egyik legnagyobb áttörésnek a videók áttömörítése ígérkezik, így egyelőre ez kapja az egyik legnagyobb prioritást. A kutatás közben már talált a csapat zsákutcákat is, például a redundáns letöltések kezelése - kiderült, hogy ez valós probléma, a böngészők (a pesszimista gyorsítótárazás miatt) rengeteg erőforrást töltenek le többször egymás után, az így megspórolható sávszélesség azonban marginális, nem éri meg ebbe energiát ölni, legalábbis addig, amíg az ennél nagyobb labdákat nem csapta le a Google.

A Flywheel nem a Google találmánya, emlékezetes módon az Opera Mini vezette be a koncepciót széles körben. A megközelítés lényege, hogy a böngésző nem közvetlenül a webszerverrel van kapcsolatban, hanem a forgalom előbb átfut egy közbeiktatott szerveren is, amely a webes tartalmat több szempontból is emészthetőbbé teszi a mobil számára. Az Opera Mini esetében a tömörítés mellett ebbe beletartozott a nagyon alapos átformálás is, a Turbo azonban már a Flywheelhez nagyon hasonló módon működött. A Google ezeket egyébként be is vizsgálta és azt találta, hogy a Turbo nagyon hasonló teljesítményt ér el tömörítésben.

A viszonylag rövid, de információban gazdag kutatási beszámoló innen érhető el.

Nagyon széles az a skála, amin a állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról

fab

5

Chipgyártó nagyhatalommá válna India

2024. március 18. 12:39

A helyi politikai vezetés szerint van rá esély, hogy a következő néhány évben az ország bekerüljön az öt vezető ország közé.