Google AMP: csupasz web a gyorsaság érdekében

A mobilweb lassú - ebben ma már minden szereplő megegyezik, a tech-óriásoktól a kiadókig és a felhasználókig. Arról azonban mindenkinek megoszlik a véleménye, hogy a status quo kinek a felelőssége, és kinek kellene a problémát megoldania. Most a Google is sorompóba száll a gyorsabb mobilweb érdekében, kezdeményezését Accelerated Mobile Pages (AMP) néven érdemes figyelni.

Mi az AMP és hogyan fog működni?

A Google híres az új webes szabványok bevezetéséről (legalábbis rendszeresen próbálkozik ezzel), az AMP-hoz azonban semmilyen új alaptechnológia nem társul, az a már létező és elterjedt webes megoldásokon nyugszik - ígéri a vállalat. Új technológia azért van, az AMP HTML egy új webes framework, amelyet kimondottan gyors betöltődéshez és közel-azonnali megjelenítéshez optimalizált a Google.

Az új szabványok helyett az AMP inkább önkorlátozó magatartást követ, vagyis kidobálja az olyan technológiákat, amelyek lassítják az oldalakat. Mielőtt továbbmennénk, érdemes leszögezni, hogy az AMP kimondottan statikus tartalom, cikkoldalak, videós oldalak kiszolgálására született, komplex webes alkalmazások, webes játékok, m-kereskedelmi megoldások megvalósítására gyakorlatilag alkalmatlan.

Miket dobál ki az AMP? Az első áldozat a JavaScript. A fejlesztőcsapat szerint nem önmagával a JavaScripttel van probléma, léteznek takarékos, szerény scriptek, amelyek érdemben nem lassítják az oldalakat. De a mai, korlátlan JavaScript-használat gyakorlatilag lehetetlenné tette a gyors mobilwebet, így első körben ennek használatát kell korlátozni: az AMP sem a "házi főzésű", sem a külső scripteket nem engedi használni. Ez nem olyan kemény korlátozás, mint amilyennek elsőre hangzik - ígérik a fejlesztők, ráadásul van kibúvó is. A jelenleg JavaScripttel megoldott, valóban hasznos funkciók túlnyomó többsége kiváltható egyedi elemekkel (custom element) és webes komponensekkel. Ezek saját hatáskörben futtathatnak JS-t, ez pedig már kompatibilis az AMP céljaival és szellemiségével.

A JavaScripthez hasonlítva a CSS még viszonylag jól járt, bizonyos korlátozások mellett használható marad. Ilyen korlátozás, hogy a CSS mérete nem lehet nagyobb 50 000 bájtnál, illetve a behavior és -moz-binding tulajdonságok használata tilos. Egyelőre szintén tilos a transitioin, animation és filter tulajdonságok használata, ezt a tiltás azonban nem végleges, később elképzelhető, hogy feloldják.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Az AMP veszélye, hogy a tartalmi oldalak hasonlóan fognak kinézni a különböző kiadványok között, a Google szerint azonban az AMP szűkített eszköztárában is van épp elég eszköz arra, hogy a weboldalak formailag is meg tudják különböztetni magukat. A CSS mellett az egyedi betűtípusok is támogatottak, és természetesen képek, videók, szövegek tetszőleges mennyiségben és elrendezésben jöhetnek.

A JavaScript elvesztése a hirdetéskiszolgálókat és különböző analitikai rendszereket érzékenyen érinti majd, a Google pontosan érzi ezt, ezért vigaszként kínál egy alternatív megoldást, a "követőpixelt". Ez egy láthatatlan (jellemzően fehér) pixel, amelynek betöltését az audit szerver regisztrálni tudja, ennél komplexebb analitikát azonban az AMP nem támogat egyelőre. A fejlesztők víziójában szerepel egy egységes, auditálható, nagy sebességű, nyílt forrású analitikai alrendszer, amely illeszkedne az AMP szellemiségéhez és összeköthető lenne a létező analitikai megoldásokkal - ez egyelőre még fejlesztés alatt van.

A reklámok szerves részei az AMP víziójának, ezt azonban a jelenlegitől gyökeresen eltérő módon valósítaná meg a Google kezdeményezése. A széles körben használt beágyazó kódok helyett a reklámok sandboxolt iframe-ben jelennek meg, ami egy csapásra megoldja a reklámokkal kapcsolatos legnagyobb problémákat, ráadásul elveszi annak lehetőségét is, hogy az (esetleg rosszindulatú) hirdető saját JavaScriptet injektálhasson az oldalba. Az AMP a tulajdonképpeni reklámokra vonatkozóan semmilyen megkötést nem tartalmaz, így a jelenlegi, "túlsúlyos" reklámok megjelenítését sem akadályozza majd meg. Annyi könnyebbség viszont van, hogy a betöltődés során a tartalom kap prioritást, az oldal hirdetési felületei telnek meg legutoljára.

Van ennek értelme? A fejlesztők saját mérése szerint szimulált 3G kapcsolaton mintegy 15-85 százalékos gyorsulás érhető el az AMP használatával egy Nexus 5-ön. Van azonban még két trükk, amellyel a betöltődés még tovább gyorsítható, az előrenderelés és gyorsítótárazás. Az AMP formátumot az első perctől a jó gyorsítótárazhatósághoz fejlesztették, így az előrenderelés (prerender) roppant hatékonnyá válik: az AMP formátumú dokumentumok látható, komoly CPU-terhelést nem jelentő része háttérben elkészíthető, így amikor a felhasználó az adott linkre kattint, a weboldal már készen várja. Szintén jelentős segítség a gyorsítótárazás, az AMP statikus tartalmai könnyen betárolhatóak a különböző CDN-rendszerekben.

Van ennek jövője?

Fontos szempont lesz, hogy az AMP egyáltalán nem Google-specifikus (legalábbis az eddig rendelkezésre álló információk szerint). Vagyis ugyanúgy működik majd iOS-en Safari alól, mint Androidon Chrome-ból. Ez jelentős különbség a Facebook és az Apple megközelítéséhez viszonyítva, amelyek a gyorsabb web ígéretét a saját platform pozíciójának erősítésére használja fel. Azon túl, hogy a Google megoldása ebből a szempontból szimpatikusabb, ez a platformsemlegesség segíthet meggyőzni a független szereplőket (jellemzően a kiadókat) az AMP támogatásáról.

Az AMP mögött már több kiadó is felsorakozott, de náluk is fontosabb lehet, hogy a különböző CMS-fejlesztők is beállhatnak a projekt mögé. A Google reményei szerint a népszerűbb CMS-ekhez készül majd olyan integrált megoldás, amely AMP-os oldalakat is tud generálni. A WordPress már be is jelentette, hogy integrálni fogja az AMP-et, a piacvezetőt pedig hamarosan követheti a többi versenytársa is. A terjedő reklámblokkolással küzdő kiadók számára az AMP lehet a várva-várt mentőöv, amely a webes tartalmakhoz hatékony hozzáférést nyújt, úgy, hogy a jelenlegi monetizációs platformok működőképesek maradnak (a reklámok mellett a fizetőkapukat is támogatja a rendszer).

Az AMP projekt október 7-én indult, ekkor tette közzé az előzetes műszaki specifikációkat a Google, és ekkortól érhető el az első demó is. A következő hetekben-hónapokban fokozatosan egyre több képesség és funkció kerül be, a projekt fejlődése az AMP GitHub oldalán követhető.