Így gyorsítja az AMP-oldalakat a Google
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.
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
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
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.