Přejít k navigační liště

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

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

Články Webdesign

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.

Obrázek: Tři rychlostní mimoni: grafik, marketér a vývojář

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:

Obrázek: Nahoře Bella Rose a jejich původní článek na blogu, pak jeho umístění v Google hledání a nakonec AMP verze téhož, řešená WordPress pluginem. Totéž dole u pana Cuketky.

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
Tabulka: Srování Speed Indexů různých verzí detailů článků. Běžný web, pak AMP verze na hostingu u běžného webu, AMP na hostingu u Google. To poslední je měřeno s dostatečným časem na přednačtení. V odkazech na číslech jsou zdrojové testy z WebpageTest.org

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.

Komentáře

Subscribe
Upozornit na
guest
8 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Pan

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…

Lukáš Brzák

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.

Mlocik97

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ť.

Jarda

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áší?

Mlocik97

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….

Mlocik97

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.