Mellékleteink: HUP | Gamekapocs
Keres
Felhőből visszaköltözéstől egészen egy banki malware evolúciójáig. Üzemeltetői és IT-biztonsági meetupokkal érkezünk!

Így gyorsítja az AMP-oldalakat a Google

Gálffy Csaba, 2017. január 16. 14:32
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

Extrém tömörítéssel küzd az adatforgalom-zabáló képek ellen a Google. Kevés RAM és lassú net mögött még ennél is komolyabb lépések kellenek.

hirdetés

Különböző optimalizációval és tömörítéssel mintegy 45 százalékkal tudja zsugorítani a letöltött adatokat a Google AMP Cache - mondja a keresőcég friss blogbejegyzése, amely részletezi is, hogy milyen kompromisszumokat köt ennek érdekében. Ahogy a cég korábbi próbálkozásainál, most is a tömörítés (veszteséges és veszteségmentes) áll a fókuszban.

"Képoptimalizálás" AMP Cache-ben

A Google AMP kiadói platformjának egyik legfontosabb (bár opcionális) eleme az AMP Cache, amely nevéből adódóan az előre legenerált oldalakat gyorsítótárazza. A megközelítés előnye, hogy a több, különböző késleltetéssel rendelkező forrást a cache egy szintre hozza és közös, gyors platformról szolgálja azokat ki.

Az AMP Cache azonban nem csak CDN-ként működik, saját hatáskörben a gyorsítótárazott objektumokon sokrétű optimalizálást is végez, ennek elsődleges pontja a képek agresszív tömörítése. A cég szerint ugyanis a weben átlagosan a képek teszik ki az oldalak 64 százalékát, így adja magát, hogy ezekkel érdemes először kezdeni valamit - ehhez a Google a PageSpeed moduloknál és a Chrome Data Compression esetében már ismert és bevált technikákat alkalmazza.

A képek lefogyasztásához első lépés a nem látható információk kigyomlálása  - mennie kell a beágyazott bélyegképek (thumbnail) és metaadatok (például geolokáció) eltávolítása. Ezt követi a már veszteséges minőségigazítás, a rendszer a képeket újrakódolja, egységesen 85-ös JPEG minőségre és 4:2:0 színmintára. A Google álláspontja szerint mobilweben (és az AMP ugye azt célozza) ennél többre egyszerűen nincs értelme ennél magasabb minőségnek. A kapott képet pedig alapos (immár veszteségmentes) tömörítés követi, együtt 40 százaléknál is jobb zsugorítás érhető el.

Optimalizálás előtt - és után - 241 kB vs 26 kB

A kompatibilis böngészőknek a rendszer egyébként nem JPEG-t, hanem WebP-t szolgál ki, ez a Google saját fejlesztésű formátuma és további 25 százaléknyi megtakarítás érhető el vele. Jelenleg azonban csak a Chromium-alapú böngészők (Chrome, Opera) támogatják ezt, a Firefox és a (mobilon nagyon releváns) Safari nem, így oda marad az optimalizált JPEG.

Következő titkos fogás az srcset attribútum automatikus hozzáadása a HTML-kódhoz. Ez lehetővé teszi, hogy a böngésző kliensoldalon alternatív képméretek között válogasson és ha nincs szükség a nagy felbontású képre, akkor kisebbet töltsön le. Ez elsősorban a kis kijelzős, kis felbontású mobilokon hoz jelentős spórlást.

Az utolsó lépés pedig a képek szélsőséges tömörítése - olyan esetekre, amikor a felhasználó ezt kéri vagy nagyon lassú internetes kapcsolat mögött ül. Ezekhez a forgatókönyvekhez 50-es JPEG minőséget használ az AMP Cache, ami további 40 százalékos megtakarítás a fentiekhez képest. A tömörítésnek ára is van, ezek a képek már szemmel is jól megkülönböztethetőek az eredetitől, legalábbis nagy méretben.

AMP Lite - oda, ahol csak EDGE van

A fenti, utolsó lépést akkor használja a Google, ha a böngészőn be van kapcsolva a Chrome Data Saver opció, vagy ha nagyon lassú a mobilnetes kapcsolat. Ilyenkor egyébként nem csak a képkiszolgálás vált takarékos módra, hanem az egész Cache átvált az AMP Lite módra. Ilyenkor a fenti négy optimalizáción túl a külső betűtípusokat az amp-font taggel optimalizálja, és egyáltalán nem vár azok betöltődésére - vagyis a letöltött dokumentumot azonnal megjeleníti, akár készen áll az egyedi betűkészlet, akár nem. Ezt az üzemmódot néhány, gyenge lefedettségű országban indítja be a cég (Vietnám, Malajzia), de a kevés RAM-mal szerelt telefonokon globálisan aktív lesz.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.
4-4 klassz téma a HWSW júniusi üzemeltetői és IT-biztonsági meetupjain. Nézz meg a programot!