Miben különbözik mind a két programnyelv? Melyik drágább? Melyik gyorsabb a munkaidő? Melyiket jobban beválna az ügyfelek viselkedési stratégia? Mik az előnyei és mik a hátrányai?
Természetesen kizárólag minden ami csak a sebességekről, illetve Google elvárásairól írok, mint alapilag.
Mi a megoldás, ha szeretne minél hamarabb elsajátítani ez a új gyorsított technológiát?
Csináltam egy alap, egyszerű, könnyen megérthető AMP HTML specifikáció forráskódjája nézetét (AMP HTML dokumentum minta - alapszabályok szerint), ahol részletesebb információkért nyújthat és mindegyik alá kommenteltem, hogy mi jelent és mire valóak.
Tovább információkért klikkeld ide!
Projektek árak, költségek kezelési különbségek
Szokásos HTML esetén:
- CSS fájl mérete limitet betartása esetén olcsóbb, különben drágább
- JS fejlesztés és a bármi pluginok deklárása esetén drágább
- Normál, megértő ügyfélnél esetén olcsóbb, különben drágább
AMP HTML esetén:
- CSS fájl mérete limitet betartása esetén olcsóbb
- JavaScript fejlesztés és a bármi pluginok deklárása nélkül esetén olcsóbb
- Normál, megértő ügyfélnél esetén olcsóbb, különben drágább
Projektek munkaidői különbségek
Szokásos HTML esetén:
- CSS fájl mérete limitet betartása esetén rövidebb, különben hosszabb
- JavaScript fejlesztés és a bármi pluginok deklárása esetén hosszabb
- Normál, megértő ügyfélnél esetén rövidebb, különben hosszabb
AMP HTML esetén:
- CSS fájl mérete limitet betartása esetén rövidebb
- JavaScript fejlesztés és a bármi pluginok deklárása nélkül esetén rövidebb a saját CDN használata miatt
- Normál, megértő ügyfélnél esetén rövidebb, különben hosszabb
Technikai különbségek
Szokásos HTML esetén:
Nagyjából bármelyiket támogatják a technikai, nincs ellene kifogások. Viszont annyi hátránya, hogy érdemes megvizsgálni, hogy megfeleljenek a Google elvárásai szerint, mert nehogy előjöjjenek a gondok/meglepetések miatt.
AMP HTML esetén:
Kizárólag csak ezeket lehet használni, mást NEM: Komponensek katalógusok és működése
AMP “szigorai” (CSS, JS, platformok, támogatott termékek), mint korlátozások miatt mást NEM lehet, kizárólag csak amiben van az amp.dev honlapon.
Támogatások különbségek
Szokásos HTML esetén:
Nagyjából bármelyiket támogatják a platformok, nincs ellene kifogások. Viszont annyi hátránya, hogy érdemes megvizsgálni, hogy a validátor vagy a sebesség idő esetén nehogy előjöjjenek a gondok/meglepetések miatt.
AMP HTML esetén:
Az utóbbi időben nagyon sokat változtak, folyamatosan fejlődtek és bővültek a platformok támogatásait.
Itt megtekinthető, ha szeretné tudni, hogy amivel foglalkozik, azt támogat-e az AMP technológia szerint:
https://amp.dev/community/platform-and-vendor-partners
Ügyfelek viselkedési stratégia hasonlítása
Szokásos HTML esetén:
Annyira változó, vegyes, nehéz megjósolni.
De annyi biztos, hogy ha fontos, hogy jól szerepeljen a PageSpeed pontok száma és esetleg macerás az ügyfél, akkor természetesen nehéz lesz egyeztetni, és persze hozzá is kell jobban kidolgozni jó stratégiát, hogy legyen olcsóbb költség és kevesebb munkaidő.
AMP HTML esetén:
Ha esetleg macerás ügyfél nem érti meg, vagyis nem fog fel amiket mond tanácsadók/szakértők az AMP “szigorai”, mint korlátozások miatt, akkor könnyen lefújhat a projektet miatt sok pénzt és időt veszíthetnék vele.
Ezért jobban kell dolgozni egy nagyon jó stratégiát, hogy legyen olcsóbb költség és kevesebb munkaidő.
Mik az előnyei?
Szokásos HTML esetén:
Ha egyedi fejlesztés, design tervezés / implementálás, akkor:
- Javul az átkattintási és a visszafordulási arány
- Több látogatókat szerezhet, mert rövidebb betöltési időnek köszönhetően nem fogják elveszíteni a türelmet és sem elhagyják a weboldalt
- Akár mobilon, akár tableten, akár desktopon felhasználó száma növeli
AMP HTML esetén:
- Javul az átkattintási és a visszafordulási arány
- Több látogatókat szerezhet, mert rövidebb betöltési időnek köszönhetően nem fogják elveszíteni a türelmet és sem elhagyják a weboldalt
- Itt egyelőre csak a mobil felhasználó száma növeli, viszont a desktop számára nem igazán, mert ez a technológia kizárólag csak mobilnak szól
- Előny, ha hírközlő weboldalt szeretne készíteni, mert nekik készülnek inkább ez a technológia és legelőnyösebb
Mik a hátrányai?
Szokásos HTML esetén:
Hogy gyorsabb legyen a weboldal:
- Pluginok felhasználása (+deklarálása) helyett natív javascriptet (gyorsabban tölti be) kell írni, aminek hátránya, hogy több munkaidő és több költség
- Jobban kell figyelni a CSS fájl méretét, hogyha esetleg több pluginokhoz használ, ami kell a desigszabáshoz, azaz optimalizálni kell, hogy csak olyan legyenek a fájlban ami szerepel és szükséges, pedig lehetőleg ne legyen teljes verzió, amikor bármelyik plugin honlapjáról letölti a fájlt.
Nyugodtan írhat natív javascriptet, testreszabható bármi pluginokat - > de annál többet használ a pluginokat, annál lassabb lesz az oldal sebessége.
Design beszabásnál nincs limitje - > de annál több, annál lassabb lesz az oldal sebessége. Bár érdemes mindig vizsgálni, hogy a validátor szerint rendben van-e, ne legyen 1db apró hiba sem, de szerintem az én véleményem szerint nem baj, ha pár darab apró hiba, ettől függetlenül még mindig müködhet az oldal és tud indexelni rendesen a Google, stb.
AMP HTML esetén:
Sajnos itt létezik 3 fontos szabályok, amiket érdemes megtartani, különben érvénytelen lesz a Google AMP weboldal:
- Kizárólag saját AMP javascript pluginok / fájlok használhatják, mást nem.
- Design beszabásot úgy kell figyelni a CSS fájl méretre, hogy ne lépjen át a 50 kbtye határt.
- Érdemes mindig vizsgálni, hogy a validátor szerint rendben van-e, ne legyen 1db apró hiba sem.
- CDN-t használni kell, ami hátránya, hogy bárminál fogva a szerver leáll, akkor bizonyos elemek nem fognak működni jól az amp-os weboldal.
- Gyakrabban egyeztetni kell, hogy megoldható-e a szigorú szabályok miatt.
Mindkettőnek léteznek a technikai megfeleléséhez vizsgálati eszközök
Szerencsére mindkettőnél lehet ellenőrizni, tesztelni, megmérni, létrehozni és beállítani. Csak annyi különbség, hogy sajátját szerint szükséges elvégezni a funkció dolgokat, pluszban a karakterkódolás ellenőrzésekor más-más urlben lehet vizsgálni, illetve az AMP-nál a Chrome böngészőben F12 használatával az url végére beletenni az alábbi vizsgálati kódot: #development=1.
- Karakterkódolás ellenőrzése (Validator)
- Mobilbarát teszt (Mobile-Friendly test)
- Weboldal betöltési idő, sebesség vizsgálata és optimalizálása (PageSpeed és GTmetrix)
- Google Analytics és Google Tag Manager
- Google Search Console
Összefoglalás
Mint ahogy látjátok, hogy szépen leírtam a fontos tudnivalókat, mert segíteni akartam az ügyfeleknek, hogy érdemes átgondolni, mielőtt belevágnak megrendelni a kétféle típusú weboldalt.
AMP-nál alap készítésekor nem fog megtörténni legalább 90 pont felett a mobilon, mert ahhoz nem elég, természetesen tovább optimalizálni kell, hogy meglegyen. Persze csak akkor, ha magas felhasználói élményi blokkok száma. (Mobilon tavaly 90 pont volt, most 70 pont körül lett, mert megváltoznak dolgok miatt ki fogok majd deríteni és optimalizálni. Majd ha lesz időm rá, rá fogok nézni)
Aki szeretne megrendelni szokásos HTML (akár statikus, akár dinamikus) vagy Google AMP-es (akár statikus, akár dinamikus) weboldalt, előtte érdemes megvizsgálni:
- az üzleti ágazatot,
- tartalom minőségit,
- design arculatot,
- technikait,
- statisztikai méréseket,
- stratégiait,
- pénzt/időt
alapján, hogy melyiket érdemes kiválasztani.
0 Megjegyzések