Az Accelerated Mobile Project (AMP) egy olyan nyílt forráskódú keretrendszer, melyben a weboldal egy olyan plusz réteggel van ellátva, melytől az oldal tartalmának betöltődése radikálisan felgyorsul.
Miért jó ez?
A Google informatikai mammut által erősen támogatott új weboldal szabvány célja az, hogy a weboldalakon levő tartalom minél kevesebb várakozási idő elteltével elérhetővé, fogyaszthatóvá váljon. A cél a gyorsabb web, azaz, hogy az okostelefonos böngészés, internetezés olyan érzetet (felhasználói élményt) nyújtson, mintha egy telepített appot használnánk.
Gyorsaság mindenek felett
A weboldal AMP-s verziója (ha van persze) az okostelefonos, tabletes Google keresés alkalmával válik elérhetővé. Jele a találati listában a találat mellett elhelyezett apró villám ikon. Eddigi megfigyeléseim alapján ezt az átlag user észre sem veszi, vagy nem tudja, hogy ez mire való, azonban ez nem zárja ki, hogy tudat alatt már keresi az AMP ikont, hiszen nem kell várnia az információra. Én például megfigyeltem magamon, hogy a gyorsaság kedvéért akár lejjebb is "gurulok" a találati listában egy-egy AMP-s, azaz gyors találatért.
20%-os konverzió növekedés
Az amerikai Forrester piackutató cég frissen kiadott (2017. nov.) tanulmányából kiderül, hogy hosszú távon megéri az új technológia használata.
A tanulmány röviden az alábbi előnyöket foglalja össze:
- A webshop üzemeltető interjúalanyok A/B tesztelések adataival támasztották alá, hogy az AMP-s oldalaikon átlagosan 20%-os konverzió növekedést tapasztaltak a nem AMP-s oldalaikról származó konverzió értékekhez képest.
- Három éves mérés alapján, minden évben 10%-al növekedett az AMP-s oldalak forgalma. Mind a webshop, mind a portál (blog, híroldalak) oldalak üzemeltetői egységesen alátámasztották ezt az eredményt.
- Számokkal nem alátámasztott, azonban közvetve mérhetően kimutatták, hogy az AMP-t használó oldalak nagy részénél javult a vásárlási és olvasási elköteleződés, az oldalon eltöltött idő pedig szignifikánsan megnövekedett.
- Az alacsony sávszélességű területekről mérhetően kevesebbek lett az oldal betöltése közben előforduló hibák száma. Átlagosan 80%-al csökkent az oldalbetöltődési idő az amphtml technológiája miatt.
- Egy interjúalany arról számolt be, hogy csökkenést tapasztalt a technikai jellegű ügyfélkapcsolati megkeresések előfordulási arányában. Ez ugyan egy elég kis minta (ha egyáltalán annak nevezhető), azonban elképzelhető, hogy mások is tapasztalták ezt, mindenesetre érdekes üzemeltetői adatnak látszik.
- Egy tartalomszolgáltató 20%-os CTR-t (átkattintási arányt) tapasztalt az AMP-s oldalakon elhelyezett hirdetések esetében.
A publikáció kiemeli, hogy a fejlesztési, bevezetési és analitikai költségek igen magasak lehetnek a hagyományosan használt modellekkel szemben, hiszen a technológiát egyelőre kevés fejlesztő ismeri. (Mi is folyamatosan tanuljuk.) Ez különösen igaz lehet egy bejáratott online orgánum, webshop számára, hiszen itt komoly átállási, fejlesztési költségekkel számolhatnak a beruházók. A dokumentum konklúziója azonban egyértelműen az, hogy hosszú távon megéri belevágni a AMP-be.
A tanulmány részletes adatokkal, grafikonokkal támasztja alá következtetéseit, erről a linkről lehet letölteni. Az amphtml blogján pedig egy rövidített összefoglalót lehet elolvasni róla.
Hogyan működik?
Ahhoz, hogy az AMP-s oldalak működési mechanizmusát megértsük, ismerjük meg a jelenleg elterjedt oldalbetöltődési mód működési elvét!
Nagyvonalúan, nevezzük hagyományos oldalbetöltődési módnak azt, amikor ennek a weboldalnak nem az AMP-s verzióját böngészi a kedves olvasó. (Ezt könnyen leellenőrizheti: ha az URL végén nincs az, hogy amp.html, akkor nem az AMP-s verziót olvassa.) Ebben az esetben a weboldal fájljait a böngészője egy helyről kapja meg.
Ilyen egyébként manapság már nem túl gyakori, ugyanis a legtöbb weboldal adatai nem csak egy kiszolgálótól érkeznek a gépe felé. Elegendő egy Google Analytics követőkód beágyazása és az eszköze máris fogadja az adatokat a Google szerverétől is.
A hagyományos oldalbetöltési módszernél, amikor beírja az URL-t vagy rákattint egy linkre, a kiszolgáló elküld egy csomagot a böngészőjének, melyet az feldolgoz. Ebben a csomagban benne van az oldal képi, szöveges tartalma és a weboldal megjelenítéséért felelős fájlok (js, css fájlok) is. A fenti példából kiindulva szintén ebben a csomagban van az az utasítás is, hogy az Analytics scriptjét kérje le a böngészője egy külső kiszolgálóról.
Minden weboldal más
Ideális esetben, minden weboldalon más tartalom található. Azonban nem csak a tartalom változik, hanem a weblap kinézetéért, viselkedéséért felelős kódsorok is eltérőek, hiszen minden weboldal másképp néz ki.
Egy 10 perces böngészés, keresés alkalmával rengeteg adatot tölt le a böngészőnk. Az egyszerűség kedvéért, ezalatt a 10 perc alatt nem fogyasztottunk videós, (pl. streaming) tartalmat. Ha megvizsgáljuk, hogy ténylegesen mennyi az az adat, ami számunkra hasznos volt (képek és szövegek), és mekkora mennyiségű azoknak a fájloknak a mennyisége, melyek a meglátogatott weblapok kinézetéért felelősek, egészen érdekes statisztikát kapunk.
Írtam korábban egy cikket a Signal chatprogramról. Ezen az oldalon a fent említett "csomagban" küldött adat kevesebb, mint 10%-a szöveg és kép, azaz a content. A csomag maradéka a Joomla template fájljai, illetve majdnem 25%-a csak a Google font. Az oldalunkat korábban alaposan kioptimalizáltuk, így ez a 10% hasznos adat elég jó aránynak számít.
Nem csak az adatmennyiség lassítja az oldalbetöltődési időt, sok más ok is akadályozhatja az oldal gyors megjelenítését. Erről korábban már írtam egy cikket, itt lehet elolvasni.
Az AMP elgondolás
Az AMP a hagyományos oldalbetöltődési módszerrel ellentétben jóformán az oldal egyetlen érdemi részére fókuszál, a tartalomra. Az elv egyszerű, azért keresek a Google-ben, mert információra vágyok. Ha ezt minél hamarabb megkapom, annál elégedettebb leszek, tehát a content az elsőrendű. Azt kell minél gyorsabban eljuttatni az érdeklődő felé. Az AMP-s oldalverzió csak az oldal tartalmát küldi át az okostelefonnak. Ezzel a módszerrel jelentős adatmennyiséget és weboldal-feldolgozási időt lehet megtakarítani a mobileszköz számára. A küldött csomagban elenyészőek az egyedi megjelenítésért felelős CSS és JS szabályok, mondhatjuk, hogy minden sablonizált.
Itt jön a trükk, ugyanis ezek a "sablonok" (fájlok) már előre, lokálisan vannak tárolva a böngészőjében. Ettől olyan gyors az AMP-s oldalmegjelenítés, na meg persze számos olyan szabványosítástól, melyek nem engedik meg, hogy a fejlesztő ne optimalizálja a kódját. Ez annyit jelent, hogyha egy követelményrendszeren nem megy át az AMP-s oldalverzió, akkor az nem kerül bele a Google AMP-s találatai közé.
Az AMP-t nem véletlenül "tolja" a Google. Ezzel a szabványosítással sokkal jobban meg tudja érteni a keresőmotor az adott oldal tartalmát. Például a fent linkelt AMP validátorban is utalnak a strukturált adatok helyességére a fejlesztők számára. Az AMP tökéletesen illik az évek óta meghirdetett Mobile First elvhez is, hiszen a legtöbb esetben először mobilon keresnek az emberek, és ezeket a találatokat érdemes kiszolgálni minél gördülékenyebben.
Egységesít és gyorsít
Az olvasóban joggal merülhet fel, hogy itt valamiről le kell mondani a sebességért cserébe. Akkor most minden AMP-s weboldal egyforma lesz? A gyorsaságért feláldozzuk az online arculatunkat? Nem teljesen. Valóban vannak kötöttségek, azonban a fejlesztők folyamatosan bővítik a lehetőségeket. Korábban még elképzelhetetlen volt egy webshopot AMP-s verzióra is bővíteni, mára vannak rá precedensek, minták. Ahhoz képest, hogy alig pár éves kezdeményezésről van szó, olyan AMPHTML oldalak vannak már, melyek teljesen egyediek, illetve nagy mértékben testre szabhatóak. Aki nem hiszi, nézze meg az amp.dev weboldalt. Innen le is lehet tölteni a sablonokat, lehet vele játszani, open source.
Standalone AMP oldalak
A cikk legelején írt rövid összegzés, hogy az AMP egy plusz réteg, nem teljesen állja meg a helyét. Létre lehet hozni kizárólag AMP verzióval rendelkező oldalakat is (ún. standalone AMP weboldal). Ebben az esetben az oldal elérhető lesz desktopról is. A weblap ekkor is megőrzi a gyorsaságát és a responsive webdizájn miatt ugyanolyan élvezhető lesz okostelefonról, mint egy 24" colos képernyőről. Ebben az esetben a canonical url az AMP-s oldal linkje lesz. Erre egyelőre kevés példa létezik, de megvalósítható, például ezen az oldalon.
Hirdetést is tud
Az, hogy komolyabb megkötések érvényesek az AMP-s weboldal verziókra, nem jelenti azt, hogy a hirdetési bevételekről le kellene mondanunk. A legtöbb hirdetési rendszer könnyedén beágyazható az amphtml-be. Itt található meg a jelenleg támogatott hirdetési platformok listája: link.
A hirdetési típusok mennyisége növekszik, így például ún. sticky hirdetést is tud már kezelni a rendszer.
Használjon AMP-t!
A Google folyamatosan veszi előrébb az AMP-s találatokat az indexében, így érdemes meglépni az AMP-s verzió bevezetését. Mi ebben tudunk segítséget nyújtani. Tapasztalataink alapján nem minden átállás zökkenőmentes, de szerencsére a Search Console-ban elég jól nyomon lehet követni, ha valamelyik oldallal baja van a Google-nek. Magunk mögött tudunk pár AMP-s átállást, ebből egy több ezer oldalas Joomla-ra épített portált is és jó néhány kisebb oldalt is.