A Google bejelentette, hogy jövő év elején indul az AMP, és már forgalmat is hoz a weboldalaknak. De mi is ez az egész?
Mi az az Accelerated Mobile Pages (AMP)?
A Google az elmúlt egy-két évben óriási hangsúlyt fektetett a mobil felhasználókra, és ennek új lépése az AMP. A probléma az, hogy a hagyományos weboldalak letöltése mobil eszközökkel igen lassú, és az akkumulátorokat is erősen igénybe veszi. A reszponzív design csak a megfelelő megjelenítést teszi lehetővé, de a letöltendő adatmennyiség ezzel nem változik.
Az AMP célja, hogy gyorsabbá tegye a weboldalakat és ezzel a hírfogyasztást megkönnyítse. A Googlehoz csatlakozott már a Twitter, az Economist, a Guardian, a Pinterest és sokan mások és szerencsére már a WordPress is.
Az Accelerated Mobile Pages lényege, hogy az eredeti megjelenítéshez képest egy lebutított, de jól olvasható, és rendkívül gyors megjelenítésű tartalmat biztosít.
A Google által indított HTML alapú keretrendszer nyílt forráskódú, és a Githubon bárki számára elérhető. Lényege, hogy bizonyos CSS, JS és HTML kódrészleteket tilt, így gyorsítja fel az oldalakat, de a lényegi tartalom, a szöveg, a képek továbbra is megmaradnak.
Az így előállított oldalakon bizonyos tartalmak tiltva vannak, így például egyes reklámformák is, de az egyszerűbb hirdetések megjelennek, és ez jó a hírt szolgáltató portálnak is.
Hirdetés
Miért fontos neked az AMP?
A szakértők szerint az AMP-vel előállított oldalak az organikus találati listán is megtalálhatóak lesznek, mégpedig a természetes találatok felett jelenhetnek meg. Az a megjelenítő, aki nem használja az AMP-t, emiatt azonnali forgalomvesztést könyvelhet majd el.
Azon hírpublikálók számára, akik alkalmazzák az AMP-t, vélhetően növekszik az organikus látogatók száma, hiszen a találati lista előkelő helyén bukkannak fel az ilyen weboldalak. Az egyelőre nem világos, hogy mely kereséseknél jönnek fel az AMP találatok, de vélhetően hasonlóan a Friss hírek blokkhoz a találati listán a nagy forgalmú kulcskifejezéseknél, és a hír jellegű kereséseknél bukkannak majd fel.
Hogy pontosan milyen arányban és milyen típusú oldalak kerülnek be a Google merítésébe az egyelőre nagy kérdés, de árulkodó a Google mostani nyilatkozata.
Mit mondott most a Google az AMP-ről?
A Google mostani bejelentésében azt közölte, hogy a jövő év elején elindítják az AMP-t, és az már meg fog jelenni a találati listán. Ennél is fontosabb, hogy a fejlesztők úgy nyilatkoztak, hogy ekkortól az AMP oldalak forgalmat is hoznak majd a résztvevő weboldalak számára. Az ígéretek szerint hamarosan a Google pontosabb időpontokkal is szolgál majd az indulásról. Ide tartozó hír, hogy a Google december 2-án Hangout-ot is tart a Google News-ban résztvevő oldalak számára.
Ideje tehát felkészülni az átállásra. Az egyelőre nem világos, hogy az AMP csak a nagy hírszolgáltatók, vagy a kisebb weboldalak számára is hozhat-e plusz forgalmat.
Hogyan térhetek át az AMP-re?
Az egyszerűség kedvéért itt a WordPress oldalak átállását mutatjuk be, hiszen ez a legnépszerűbb tartalomkezelő rendszer idehaza is.
Szerencsére a WordPress is komolyan vette a Google Mobile Accelerated Pages programját, és el is kezdték fejleszteni, az ezt kiszolgáló bővítményt, amely a Github oldaláról letölthető.
Nincs más teendőnk, mint letölteni a bővítményt, és más WordPress Pluginokhoz hasonlóan telepíteni azt Weboldalunkra.
A bővítmény bekapcsolása után, navigálunk el a WordPress beállítások Közvetlen hivatkozások Menüpontra és mindenféle módosítás nélkül kattintsunk a Save Changes menüpontra. Ezzel élesednek a módosítások.
Ha lekérjük ezután oldalaink forráskódját, akkor a fejrészben találunk majd egy plus kódsort:
<link rel="amphtml" href="https://ite.hu/uj-hir-a-pingvin-algoritmusrol-nem-lesz-adatfrissites/amp/" />
Ha a fent látott linket megnyitjuk, akkor láthatjuk az oldal AMP-s verzióját. Sajnos a bővítmény még fejlesztés alatt áll, egyelőre a 0.1-es verziója létezik, és nem működik tökéletesen minden sablonnal együtt, így például az ite.hu esetén egyelőre hibás a megjelenítés (más oldalaink esetén hibátlan).
A template.php módosításával lehetőség van a megjelenítést valamennyire weboldalunkhoz szabni, ami márkaépítési szempontból fontos.
Az oldalunk AMP verziója egyelőre egy canonical taggal hivatkozza meg az eredeti oldalt, így vélhetően duplikációs problémák sem lépnek fel az oldallal, de egyelőre még sok a homályos pont az AMP-vel kapcsolatban.
Mindenesetre érdemes róla tudni, és felkészülten várni rá, hogy ha valóban számottevő hatása lesz a mobile találati listára, akkor ki tudjuk használni annak előnyeit.
A Google már egy tesztoldalt is létrehozott, ami a jövőbeli AMP kinézete és jellemzői megtekinthetőek (mobilkészülékről).
Hát, én roppant szomorú vagyok, és gyakorlatilag mindjárt sírok.
Azok, akik a 90-es évek közepén kezdtek el webezni, és fejleszteni, emlékeznek még a fehér alapon fekete szöveg, kék link párosításra. Úgy látszik, a google gyakorlatilag feltalálta a kereket, de mindezt úgy, hogy fából csinál vaskarikát.
Miért nem mondja azt, hogy használj h1-h6, paragrafusok, linkek, ul / ol, és kész van a gyors oldalad. Az ráadásul reszponzív is.
Ez a wordpress plugin meg nevetséges. WordPress???? Lol, egy hulladék szemét, lassú, 20mp response, ha nem raksz fel valami cachet, ami több tízezer bejegyzés után elhasal, és akkor még egy plugint berakunk, hogy legyen szuper gyors az oldal mobilon?
Ez az egész csak valami vicc lehet.
Szia,
Köszi a hozzászólást, sok az igazság benne, de én azért a WordPresst nem temetném, olcsó, látványos, sok bővítmény van hozzá, és ismerek nem egy WP oldalt ami napi több tízezer felhasználót is vidáman kiszolgál. Lehet kicsit lassú, de azért nem vészes.
Mezei weboldaltulajdonosnak tökéletes, mégha a programozók ezzel nem is értenének egyet.
Nem teljesen értem a kezdeményezés lényegét.
A weboldalak többsége most sem tartalmaz túl sok féle html taget. A css sem egy kardinális dolog. A javascriptek és a nagy méretű képet lassítanak hatalmasat. Nos, ha tiltod a js betöltését, akkor bünti van, ha ő tiltja akkor ügyes volt mindenki. Nem értem benne a logikát.
De tovább megyek. A google kb 7 éve kiadott egy PHP osztályt, amivel nagyon pontosan be lehet azonosítani a weboldalunkat böngésző eszközöket (telefon, tablet, asztali gép, vagy laptop), szóval ezzel máris meg tudjuk oldani, hogy ezeket az eszközöket elve más méretű képekkel szolgáljuk ki.
És aki élt ezzel a lehetőséggel még sem kapott (eddig) kitüntetést.
Amennyire értem a dolog mögött az áll, hogy a Facebook és az Apple is indított hasonló, és emiatt pörgött fel ez a dolog a Googlenál.
Kedves barátom ajánlotta ezt a cikket szíves figyelmembe. Évek óta mellőzöm a weblapkészítés és üzemeltetés igen széles témakörében megjelenő hasonló típusú cikkek tanulmányozását. A miértre nem térek ki, mert ez a cikk nem erről szól. Viszont, ha a barátom javasol egyet, azt mindenképpen elolvasom, így tettem ezzel is.
Jómagam évek óta Joomla oldalak készítésével foglalkozom. Mikor nagy dirrel-durral bejött a responsiv design, nagyon örültünk neki, mert ezzel lehetővé vált a mobil eszközökre optimalizált vizuális megjelenítés megvalósítása 1 azaz egyetlen sablonnal. Ám már akkor és azóta is többször elmondtam – az érdeklődőknek, ügyfeleknek – hogy ez csak részmegoldás. Miért? – kérdezték. Mert, még minden adat betöltődik a háttérben, még akkor is amikor Te nem látod az adott modult, mert én elrejtem egy „css utasítással”. A „kis” eszközödet az elrejtett modulok adatainak betöltődése pedig feleslegesen terheli. Akkor mi a megoldás? – kérdezték. Egy külön sablont kell készíteni a mobilra, amit „lebutítunk” és így az adatok amik nem kellenek a mobileszközökre, nem töltődnek be, nem terhelik az eszköz erőforrásait feleslegesen. Persze ez a megoldás drágább hiszen külön tervet és sablont készítünk, még akár más modulokat és pluginokat is kell használnunk a mobileszközökön, de kifizetődőbb és rákényszerít arra, hogy az oldalon minden leendő fejlesztést megvizsgáljunk a mobilon történő megjelenés szempontjából is.
Nyilván különbözik a Google megoldása attól amit leírtam, de a lényege és a célja ugyanaz az én szememben.
Joomlához évek óta léteznek olyan ingyenes pluginok, amikkel ki tudom választani, hogy milyen eszközre melyik sablont használjam stb. Én ezt a megoldást használom jelenleg és valószínű sok víz le fog folyni a Dunán ahhoz, hogy hanyatt vágjam magam egy ilyen fejlesztéstől.
Vaso megjegyzéséhez reagálnék még: igaz, a nyílt forráskódú CMS rendszerek erőteljes térnyerése miatt a funkcionális fejlesztéseket, és pl. a weboldal gyorsítást is különböző fejlesztők bővítményeivel tudjuk „megvalósítani” az ügyfél oldalán. Ezek gyakran nem a legoptimálisabb megoldások és előfordul, hogy pont nem tudjuk elérni a kitűzött célt az éppen meglévő és működőképes oldal keretében. Ám jelenleg ez az út a leggazdaságosabb a vevőnek. A mi feladatunk felhívni a figyelmét az ügyfélnek arra, hogy egy adott igényére fellelhető megoldások alkalmazása, milyen típusú kompromisszumra kényszeríthetik őt. Vagy marad a jóval drágább egyedi fejlesztés. Sajnos ez van.
Még valami: a WordPress nem egy hulladék szemét, ám az válhat belőle – mint bármelyik CMS rendszerből – egy adott oldalon, ha azt nem megfelelően alkalmazzák. Ehhez pedig ismerni és elfogadni kellene a korlátait és a lehetőségeit. Plusz, ami ugye nagyon fontos az a „a tárhely a vas minősége”, amihez az ügyfelek úgy állnak, hogy a lehetőleg a legolcsóbb legyen. Úgy állnak, ha hagyjuk! Tehát mi, akik weboldalakat készítünk, a mi felelősségünk is, hogy az elkészült oldal hogyan működik. Tudom az ügyfél sokszor kemény dió, és nem mindig hallgat ránk. De ez a lényegen sajnos mit sem változtat.
Szia!
Köszönöm a hozzászólást és megtisztelsz vele, különösen, ha így hogy nem szoktál hasonló oldalakat olvasni. A programozói részhez érdemben nem tudok hozzászólni, bár rendelkezem némi ismerettel ph, css, stb, téren, de nem olyan szinten, hogy a véleményemnek súlya legyen.
Abban alapvetően egyetértek, hogy az ideális megoldás egy külön mobil oldal. Egyszerűen azért is mert funkcionálisan, a felhasználó szempontjait szem előtt tartva másképp kellene egy mobil oldalt kialakítani, mint egy asztalit. És erre a reszponzív oldal tényleg csak öszvérmegoldást nyújt.
Sajnos azonban van egy weboldaltulajdonosi szemüvegem is, ami azt mondja, hogy nem érdemes annyi időt pénzt és energiát belefektetnem egy külön mobil oldalba, amennyit ez igényelne, nem is beszélve arról, hogy kéthavonta jön egy újabb ötlet, hogy min lehetne, kellene javítani. Ha ez mind programozói időt igényel, ráadásul két oldaltípus esetén, az már nem éri meg.
Nyilván van az a projekt ahol ebbe bőven beleéri belefektetni, de azt gondolom a hazai weboldalak 98%-ánál nem ez a helyzet. Ehhez már más szinten kell gondolkodni, és más erőforrásokkal kell rendelkezni, hogy ez a munka anyagilag is megtérüljön