Technologie Accelerated Mobile Pages (AMP) je tady hlavně proto, aby vylepšila uživatelský prožitek lidí s obsahovými weby. Dělá to i tak, že webařským týmům přistřihla křídla. Na druhé straně ale přidala nové možnosti ke zefektivnění práce.
V minulém článku jsme si ukazovali, jak AMP funguje a také jak nám pomůže. Dneska se pojďme zamyslet nad důvody jejího vzniku a prodiskutovat časté výtky k ní.
Proč to vzniklo?
Protože rychlé weby se lépe používají… a vydělají více peněz
Autor kromě jiného pomáhá zrychlovat weby českých firem, takže vás asi nepřekvapí, že vysype pár čísel z rukávu:
- Wallmart spočítal, že každé zrychlení načtení stránky o vteřinu zvýší konverze webu o dva procentní body.
- Jednoduché zrychlení českého webu Srovname.cz zvýšilo mobilní konverze o čtvrtinu.
Dobře, rychlost je důležitá. Ale proč do toho motat AMP? Proč prostě nezrychlíme současné weby? Je to snadné – protože to často neumíme, nechceme nebo nemůžeme.
Webařské týmy jsou plné mimoňů
Nedávno jsem si dělal nehezkou legraci z designérů (kteří do stránky vkládají desítky řezů písma a obrovské animované prvky), vývojářů (kteří přidávají desítky jQuery knihoven) a marketérů (kteří weby dorazí svými skripty pro A/B testování a analytiku). Nazval jsem je rychlostními mimoni.
To, že jsou weby pomalé, je totiž důsledkem práce lidí, jejich komunikace a pracovních postupů.
Co jsou ale tito tři smyšlení hrdinové proti velké části obchodníků, kteří prodávají reklamu na webu? Většina zpravodajských portálů je na mobilech hotové peklo, co se rychlosti a použitelnosti týká. Z počítačů to není zase tak o moc lepší.
Že o tom nevíte, protože používáte AdBlock? Dobře, ale z čeho pak mají ti lidé žít?
Není náhoda, že první verze AMP vzešla z diskuze s poskytovateli obsahu zastřešené Googlem v News Initiative. Novináři a jejich firmy jsou totiž segmentem nejvíce postižený nástupem Webu a moderních technologií. Samozřejmě také zčásti vlastní vinou. Prostě nemohou nebo neumějí dělat weby a reklamu na nich dost dobře.
Myšlenka AMP ohledně reklamy je prostá: Bannerová reklama může být v pořádku. Jen musí být nevtíravá, rychlá a bezpečná. Prostě nesmí jít proti uživatelskému prožitku z celého webu.
A tak to autoři Accelerated Mobile Pages udělali se vším. Prostě vzali komponenty, které weby používají, a snaží se je vymyslet znovu a lépe. Uživatelsky přívětivě. Aby je nezkazili designéři, vývojáři, marketéři – ani prodejci bannerové reklamy.
Webové technologie mají úžasné možnosti. Až moc
Tím se dostáváme k dalšímu problému. HTML, ale hlavně CSS a JavaScript za dvacet let vyrostly z nástrojů pro tvorbu dokumentů do technologií neuvěřitelného záběru: od dokumentů přes webové aplikace až směrem k nativním aplikacím, které komunikují přímo s operačním systémem. I obyčejné rozvržení stránky v CSS je dnes možné udělat asi pěti způsoby od floatů přes flexbox až po grid.
Nerozšířily se jen možnosti jazyků, ale také nástrojů nad nimi postavených. Webový vývojář, který dělá unikátní projekty, si nemůže dovolit pro každý z nich vybírat ten nejvhodnější z padesáti a více karuselů, jež jsou k dispozici. Prostě si najde jeden, který má hodně funkcí, aby je využil na všech projektech. Naprosto logicky šetří svůj čas. Jenže více funkcí knihovny znamená zvýšenou datovou zátěž pro stahování webů do prohlížeče.
Designéři zase chtějí inovovat, marketéři měřit, majitelé prodávat reklamu… A stránka bobtná a bobtná. Ne nadarmo se mluví o epidemii webové obezity, vždyť průměrná webová stránka stahovala už před dvěma lety 2,3 MB, což je více než instalace kultovní hry Doom.
Ale zase – nemohou za to technologie, ale jen lidé a jejich komunikace či pracovní postupy. Jen v málo firmách se rychlost měří a považuje za důležitý parametr webu. I když to Google ví a leccos pro vzdělávání webařů dělá, prostě nemůže čekat donekonečna. Myslím, že i proto je zde AMP.
Já osobně jsem stále drobně nejistý, jestli je AMP pro Web po všech směrech správná cesta, ale pragmaticky vzato si jistý jsem: Některým webům a jejich uživatelům velmi pomáhá, takže u určitých typů projektů klientům tuhle technologii vřele doporučuji.
Pojďme se teď ale podívat na nejsilnější body kritiky Accelerated Mobile Pages. Ta je totiž nebývale silná.
Kritika AMPu
Proprietární technologie Googlu
Závislost na Googlu a jeho vrtoších. Tohle vyvolává velký rozruch, jako u každé proprietární technologie s velkým vlivem a od velké firmy.
Google vzal existující W3C standardy a pro potřeby specifikace AMP si je „ohnul“. Specifikace je sice open source, jenže hlavním dodavatelem lidí, znalostí a technologií je Google.
Google na druhou stranu tvrdí, že technologie používané v AMP chce postupně standardizovat a v mnoha případech už to dělá. Vezměme například práci na standardu pro Web Packaging, který by měl umožnit jednotný způsob stahování stránek offline nebo jejich distribuci po CDN ve standardně zabalených souborech.
Autor se na argument „obejití W3C“ dívá pohledem člověka, který Google „věří“: Očekává práci na otevřených a společných standardech, které tuto sadu technologií dostanou všude. Druhý autorův pohled je skrze konkurenční technologie. Facebook ani Apple se ve formátech Instant Articles nebo Apple News něčím jako webové standardy nezdržovaly. Rovnou prostě navrhly a implementovaly proprietární formáty, které jsou navíc z pohledu potenciálního budoucího vkladu do webových standardů málo použitelné.
Umístění na serverech Googlu
…a s tím související URL ve formátu google.cz/amp/nazev-stranky. To je samozřejmě nepříjemné, hlavně třeba pro sdílení stránky a jakoukoliv další práci s ní. Nebo pro vnímání značky.
Ale troufnu si tvrdit, že bychom si na to měli zvyknout. Distribuci obsahu typu zpráv budou prostě z velké části zajišťovat platformy. U konkurence – formátů Apple News nebo Facebook Instant Articles – to je stejné.
Jen tak totiž platformy mohou obsah uložit do vlastní distribuční sítě a vylepšit uživatelský prožitek způsobený mimo jiné také rychlým načtením.
Myslím si navíc, že běžné uživatele přesné znění URL zase tak moc nezajímá. Ale dobře: Z pohledu webu, jak jej známe dnes, a uživatelského prožitku na něm to samozřejmě ideální není.
Už nějakou dobu platí, že CDN pro běh AMP stránek si může založit každý, kdo technologii nějak využije. Ale běžní webaři se s cizí adresou holt musejí smířit.
Ztráta suverenity
S problémem URL u Google souvisí i tento argument, zmiňovaný v jednom z kritických článků:
This means less direct traffic on your origin, and more time spent at Google. Less traffic on your origin could mean less monetization opportunities.
Tomu vlastně moc nerozumím, protože AMP verze by měla být spuštěná právě pro ty případy, kdy zvýšení rychlosti zobrazení vede k lepšímu plnění cílů webu. Měly by to být časté vstupní stránky, jako jsou články blogu nebo třeba detaily produktů v e-shopech.
Suverenitu ztrácíme pobytem stránky na adrese CDN, tedy skoro vždy u Google: Ano, ale bez něj by ta stránka nebyla rychlejší. Bez něj to není AMP, ale obyčejný web.
AMP stránky jsou si navzájem velmi podobné
I tady bych kritice oponoval: Některé AMP stránky vypadají podobně, protože jsou odfláklé. Většina AMP stránek je vytvořená nějakým jednoduchým způsobem – například zapnutím generovacího pluginu ve WordPressu.
To rozhodně ideální stav není. AMP by měla být co nejpodobnější hlavnímu responzivnímu webu a v důležitých prvcích rozvržení stránky být totožná. Možné to je i technicky – drtivá většina CSS vlastností je totožná s použitím na běžném webu.
Určitá míra podobnosti mezi weby – hlavně v ovládání složitějších komponent – je navíc pro uživatele výhodná. Nevím jak vás, ale mě zase tak moc nebaví, když se na každém webu znovu učím ovládat komponentu pro výběr data. Na „AMPech“ ten problém mít nebudu.
Náklady na vývoj
Občas zaslechnu, jak je pitomé, že musíme dělat další verzi webu. Jak už jste určitě z předchozích vět pochopili, chyba úvahy je v té „další verzi webu“. AMP a ne-AMP verze mají být totožná věc s občasnými výjimkami v kódu ve prospěch AMP.
Pokud byste začínali stavět nový statický nebo obsahový web a byli mými klienty, doporučoval bych vám stavět jej jako „AMP-first“, tedy s maximálním využitím designérských a technických komponent frameworku. Pokud byste chtěli takový web zkoumat, mrkněte se do zdrojového kódu stránek AMP by example.
Proč Google nepřednačítá běžné weby?
Tohle se v diskuzích mezi webaři objevuje docela často: Pokud umíme udělat rychlý web, proč Google neumístí na své CDN kopii našeho rychlého webu? Proč vynucuje AMP?
TIP: Přehledného průvodce návrhem a implementací responzivních uživatelských rozhraní najdete v knize Martina Michálka Vzhůru do (responzivního) webdesignu.
Z jedné části souhlasím. Google má totiž data o rychlostních metrikách jednotlivých webů. Pokud tedy ví, které weby splňují jeho podmínky, může na své servery umístit jejich běžné verze a nevyžadovat AMP.
Zní to hezky. Jenže přemýšlejme o JavaScriptu. Jak jsem psal, do AMP není možné žádný vlastní vkládat. To je pro Google velká výhoda, protože kromě jiného může předvyrobené javascriptové knihovny skladovat na vlastních serverech a sdílet mezi AMP stránkami.
V případě, že by na serverech umístil naše běžné weby, musel by naše javascripty analyzovat z pohledu přísných rychlostních norem (což si neumím představit) a pak je všechny ukládal na svých serverech. To si představit umím, ale být Google, nechtělo by se mi do toho.
Ne nadarmo je největší omezení AMP právě v oblasti JavaScriptu. JavaScript na obsahových webech představuje interaktivní uživatelské komponenty: Pokaždé používané jiným způsobem, pokaždé s jinou datovou zátěží. Pokud by Google kešoval běžné stránky, není jisté, že by zásadní vylepšení rychlosti přišlo.
Abychom byli úplně konkrétní, zeptal jsem se Robina Pokorného, javascriptového vývojáře, co by se mohlo povolením „skriptování“ na AMP stránkách pokazit:
Obecně, když se povolí JS, prolomí se všechna omezení (na jejichž přítomnosti AMP závisí). Nic by pak nezabránilo synchronnímu nahrávání (např. pomocí document.write). Je také až příliš snadné napsat jiný blokující kód (např. animace). Jsem si jist, že by to vývojáři ihned použili k synchronním reklamním systémům a tím zničili uživatelský zážitek.
Pak jde ještě o bezpečnostní problémy:
Kdyby měl nějaký prohlížeč chybu v izolaci iframe nebo by ten problém byl v AMP vieweru, měl by útočník přístup na obsah na google.com (cookies nebo localStorage). Ochrana soukromí by mohla být problém, protože AMP stránka je ve výsledcích vyhledávání načtená, i když se na ni neklikne.
JavaScript není ale zakázaný úplně. Některý typ javascriptové funkčnosti je možné vkládat do <amp-iframe>, kde je možné vložit už plnohodnotnou stránku s tímto kódem.
Výhodou AMPu je totiž kešování, umístění na CDN a zároveň omezení webařských technologií. Ani jedna část receptu nesmí chybět.
V dalším článku se zaměříme na nové oblasti využití AMPu a také konkurenční technologie – Facebook Instant Articles a Apple News.
ČLÁNKY DO MAILU