Jak AMP chrání rychlost před webaři. A co je jeho největší přínos?

Za pomalé weby nemohou technologie, ale zase jenom lidé.
Tento text vyšel původně na autorově webu.
Někteří webaři jsou totiž rychlostní mimoni
Představím vám tři z nich:
Mimoňský designér
Nečetl články o rychlosti načítání, takže v návrhu použije osmnáct řezů písma, do pozadí stránky vloží pětiminutové video, stránka bude samý obrázek a vše se animuje. A hlavně se vůbec nebude bavit se zbytkem týmu. Rychlost je přece věcí vývojáře. Prostě to nadizajnuje.
Mimoňský vývojář
Neškolí se, nečte. Ostatně – nic vědět nepotřebuje. Psát kód umí, tak kam by chodil a co by četl…? Podklady od designéra vezme tak, jak jsou. Proč by se s designérem bavil? Optimalizaci neřeší, rychlost netestuje. Do stránky vloží dvacet tři jQuery knihoven, na které je zvyklý.
Mimoňský markeťák
Rychlost neřeší. Proč by měl? To je přece úkol vývojáře. Do stránky vloží čtyři monitorovací a A/B testovací skripty. Poběží pořád a na všech stránkách. I když se zrovna nic netestuje. Přidá chatovací lištu a vývojáře poprosí o plugin pro marketingový splash screen, který viděl na Alze.
Je asi jasné, že tihle tři rychlost webu společnými silami zabijí. Problémy se kupí, až se nakupí.
Ale zároveň je jasné, že jsem si vybral sice reálné, ale poněkud extrémní hrdiny. V normálních webařských týmech nejsou všichni takoví, že?
Dobře, ale vysvětlete mi, proč má většina českých webů, které jsem testoval, Speed Index na hodnotách přes dvacet tisíc bodů? I když za nimi stojí často jednotlivci, jejichž práce si vážím.
Je to prostě proto, že většina týmů nemá rychlost v procesech. Nenavrhují, nevyvíjejí a nedělají marketing s ohledem na cílové rychlostní metriky.
Milí čtenáři, rychlost má vliv na úspěšnost webu, takže si nastavte rychlostní limity, ty kontrolujte a na jejich dodržování vyčleňujte peníze a lidi.
Takhle jednoduché to je.
Jenže – než se to všichni naučíme, bude to trvat dlouhá léta. Google ale dobře ví, jak by náhlý pokrok v rychlosti načítání vylepšil uživatelský prožitek webů. A myslím, že už to s námi nemohl vydržet.
I proto Google přišel s AMP
AMP neslibuje jen rychlejší zobrazení. On slibuje zobrazení okamžité. Proto je potřeba být velmi přísný, a AMP přísný je. Jen namátkou:
- Žádné vlastní UI komponenty
- Žádný vlastní JavaScript
- Žádné vlastní měřící skripty
- Žádné vlastní reklamy
- Velikost CSS maximálně 50 kB
…a taky AMP přidal několik vychytávek navíc:
- Hostování u Google
- Přednačtení od Google
Výsledek není vůbec marný. Takový nějaký efekt to má:
Hlavní kouzlo? Přednačtení
Zatímco totiž koukáte na výsledky vyhledávání Google, prohlížeč nelení a stahuje AMP stránky ve výsledcích zobrazené.
Zkoušel jsem otestovat dva z českých AMP webů – blog váženého klienta Bella Rose a recepty na Cuketka.cz:

A teď pár čísel:
Bella Rose | Cuketka | |
---|---|---|
Web | 22 885 | 12 971 |
AMP | 9 467 | 15 722 |
AMP na Google | 6 951 | 11 660 |
AMP na Google preload | 274 | 163 |
Když jsem poprvé viděl Speed Indexy přednačtených AMP stránek, spadla mi čelist.
Je sice pravda, že ne vždy se musí AMP stránka stihnout přednačíst. Speed Index se bude pohybovat vždycky mezi hodnotami na předposledním a posledním řádku.
A na hodnoty s přednačtením se s běžným webem nemáte šanci dostat.
Mimochodem – všimněte si, že u pana Cuketky je Speed Index AMP stránky vyšší než u běžného webu. Není to optimální, ale v kontextu preloadované AMP stránky je to vlastně úplně jedno.
Web je pomalý kvůli možnostem. AMP je rychlý díky omezením
Co tedy AMP vyřešil oproti běžnému webu?
Web | AMP | |
---|---|---|
HTML, CSS, JS | – | – |
Rychlý server | – | – |
Přednačtení | – | ✔ |
Webaři | – | ✔ |
Tabulka je trochu zjednodušená, ale takhle to vidím:
Nevyřešil: HTML/CSS/JS a webové technologie
I na „normálním“ webu můžete použít lazyloading obrázků, zakázat si vymýšlet vlastní UI komponenty a přidávat desítky JS knihoven.
Nevyřešil: Rychlý server
AMP vám jej nabídne (stránky se hostují přímo na googlím CDN), ale není důvod si podobně skvěle zoptimalizovat servírování vašeho „normálního webu“.
Vyřešil: Přednačtení
Prostě proto, že Google vám jej ve výsledcích vyledávání nabídne jen u AMP stránek. Filozoficky vzato, je fakt škoda, že vám totéž nenabídne u rychlých běžných webů. Ale to by bylo na dlouhou diskuzi, takže snad jindy.
Vyřešil: Mimoňské webaře
Jejich kreativita je omezená a zlozvykům je zabráněno. Procesy vylepšovat netřeba. S AMPem jde udělat pomalou stránku, ale ne zas tak šíleně hlemýždí jako u „normálních webů“. Tim Kadlec ukázal, že AMP stránka je obvykle rychlejší než normální stránka od stejného týmu.
„AMP je rychlý web pro blbý“
Tohle mi napsal Pavel Ungr, když se koukal na můj materiál pro jeho SEOloger. A je to tak.
Ano, je nutné se bavit i o jeho nevýhodách. Namátkou:
- jak proprietární technologie škodí otevřenému Webu,
- jak nehezké je, že Google neumožní přednačtení i rychlým běžným webům,
- jak se zatím těžko hledá hranice, kde AMP nasadit a kde ne…
Jedno je ale jisté. S AMPem udělají rychlou stránku úplně všichni.
Amp se vyhybam, jak jen to jde. Na telefonu se mi zobrazuje u amo stranek prouzek s jmenem webu, ktery zmizi jen pri scrollu dolu a teb mi tam strasne prekazi… mohl by googl treba nacitat jen jeden radek textu priste… to by byla rychlost…
Trochu se obávám, že rychlost je hodně málo argumentů na to, aby lidé začali používat AMP, které přináší spíše extrémní množství nevýhod.
Súhlas, avšak ono to bude závisieť skôr od situácie,… bude vlastne záležať že čo bude chcieť vývojár vytvoriť za webovú aplikáciu… pokiaľ to bude niečo zložitejšie alebo pokročilejšie, tak hold AMP sa tam neuplatní… u jednoduchých rýchlych projektoch by ale nejaký význam mohol mať.
Nemám s AMP žádné zkušenosti, v článku to Martin vychválil docela dobře. Proto bych opravdu rád věděl jaké nevýhody vidíš. Píšeš, že množství nevýhod je extrémní. Mohl bys být prosím konkrétní a vyjmenovat jaké nevýhody tato technologie přináší?
Rychlost je obecně poměrně silný argument: https://www.vzhurudolu.cz/prirucka/rychlost-nacitani-proc
Nevýhody určitě jsou. Zejména to je pracné. Někdo to musí vyrobit a pak jsou tu problémy se sladěním UX s aktuálními weby, protože uživatel dříve či později z AMP verze přejde na běžný web.
Jinak čísla z pohledu provozovatele jsou hodně zajímavé: https://www.slideshare.net/PavelUngr/amp-ano-i-ne-ppadov-studie-seologer-naivo
No ja mám jednu webovú aplikaci (s AngularJS frameworkom), jej úplný load trvá do 400ms pri 10Mbps download.. skusil som ukážku http://kod.djpw.cz/gwqb-#development=1, omnoho menej obsahu, omnoho jednoduchší web, načítanie trvalo 3x tolik pri rovnakom downloade….
a podobne o tom sa píšte aj tu: https://webdesign.tutsplus.com/articles/amp-project-will-it-make-your-sites-faster–cms-25853
Díky za komentář. Mám dvě poznámky:
1) Událost
Load
neodpovídá reálnému uživatelského prožitku. Je potřeba dívat se na celý postup vykreslování: https://www.vzhurudolu.cz/prirucka/metriky-rychlosti2) Hlavní výhodou AMP je přednačtení, jak píšu v článku. S tím se moc nedá porovnávat. Některé AMP stránku mohou jistě být pomalejší, i to píšu v článku. Ale díky přednačtení to vlastně jedno.