Názory k článku AMP opravuje a zároveň rozbíjí World Wide Web

vidíš to jak hurvínek válku, co pak z indexací pro vyhledávače? Proč se takhle střílet do nohy? K čemu si budeš od sebe načítat JS, který pak načte stránky z googlu, když si je můžeš načíst rovnou??

Blabol neprestane byt blabolem jen proto, ze je starej a rika se mu prislovi...

Uz jsem videl spoustu skutecne dobreho zbozi ktere naprosto propadlo, treba kvuli spatnemu/nedos­tatecnemu marketingu a jeho vyroba byla ukoncena.

A pak zasáhne adblock a další... a zbytečně ses namáhal. Hoši zlatí, (zatím ještě boubelatí), buďte si jisti, že nikdy nebude existovat způsob, jak reklamu vnutit těm, co ji nechtějí. Můžete to zkoušet do alelujá, ale po pár hodinách, max. dnech se objeví plugin do prohlížeče, nebo adblocku, ublocku , či jiných, který vaše úsilí smete ze stolu.

jseš směšnej, naprosto nerozumíš tvorbě webu...

velká část bodů je v issues, commitech a specifikacích popsána a odůvodněna, běžně je při vývoji portálů také řešíme podobně.

Krátce. CSS selektory ne kvůli výkonnosti, skript v0.js zajišťuje hlavní logiku. opacity: 0 v noscript je kvůli probliknutí fontů při načítání.

amp-img je odůvodněn, aby AMP měl kontrolu, kdy se obrázek začne načítat, jinak je prohlížeč načte všechny rovnou a ne až jsou vidět. Problém s indexací a vyhledávačemi je znám a zatím nevím, jak to chtějí řešit.

Jo, já web dělám pro obsah a ne kvůli ujetým efektům, ale také jsem potkal pár lidí, kteří vyloženě míří na co nejvýraznější efekty. Takže jsem trochu skeptický, jak to dopadne v praxi. Rychlý web šel přece bez problémů napsat s jakoukoliv verzí HTML - stačí to udělat stručné, bez zbytečných efektů, s málo obrázky atd.

BTW, jestli nativní zpracování CSS selektorů je o 2 řády pomalejší než jeho emulace přes javascript, tak mi to přijde spíše jako chyba v prohlížeči; k tomu by snad neměl být důvod.

Nestacilo by vam treba mit AMP katalog ale objednavkove flow, ktere neni kriticke na rychlost mit jako normalni HTML stranky?

novinky.cz na to nikdy nepřejdou :), řada portálů si ale uvědomuje, že primárně musí doručit informace a reklama již není tak výnosná jako dříve. To ale jen odhaduji, proč do toho jdou.

To je utopie, vyladit JS není snadné a většina programátorů takové znalosti napříč prohlížeči nemá. Stahovat data je špatné kvůli indexaci a problémům na síti vč. množství requestů přes mobil.

V ničem, jen kromě obrázků chce přes ní hnát i celou stránku. Však mrkni jak se rychle načítají současní velikáni, NYtimes html 2s, bbc.com html 2.5s atd.

PS: google představí každý měsíc nějaký open source projekt, obvykle se o něm tolik nemluví, někdo to používá, někdo si to ze zajímavosti projde, někdo to ignoruje.

PPS: do AMP již několik týdnů přispívám, proto o něm mám přehled.

Díky za věcnou odpověď, ale stejně:
* CSS selektory jsou už navrženy s ohledem na výkonnost - jsou zásadně dopředné, a měly by jít detekovat jednoduchým konečným automatem. Jak pomůže nutnost obcházet chybějící selektory obskurnějšími konstrukcemi? Navíc kdo řeší zatížení klientského CPU v dnešních webech plných skriptů a animací?
* To s těmi obrázky považuji za naprostý úlet - rozbije se standard, klient musí načíst velký (byť kešovatelný) JS soubor navíc, a při jeho nenačtení se žádné obrázky nezobrazí. Jde to úplně proti logice jiného pokusu Google, kdy se naopak obrázky mají stahovat v jednom requestu s HTML. Každopádně to je něco, co by měl dělat prohlížeč dle preferencí uživatele - často je nenačítání nežádoucí.

Díky za věcnou odpověď, ale stejně:
* CSS selektory jsou už navrženy s ohledem na výkonnost - jsou zásadně dopředné, a měly by jít detekovat jednoduchým konečným automatem. Jak pomůže nutnost obcházet chybějící selektory obskurnějšími konstrukcemi? Navíc kdo řeší zatížení klientského CPU v dnešních webech plných skriptů a animací?
* To s těmi obrázky považuji za naprostý úlet - rozbije se standard, klient musí načíst velký (byť kešovatelný) JS soubor navíc, a při jeho nenačtení se žádné obrázky nezobrazí. Jde to úplně proti logice jiného pokusu o zrychlení od W3C, kdy se naopak obrázky mají stahovat v jednom requestu s HTML. Každopádně to je něco, co by měl dělat prohlížeč dle preferencí uživatele - často je nenačítání nežádoucí.

CSS selektory dokáží občas pěkně potrápit prohlížeč, navržené pro výkonnost nejsou, jádra prohlížečů se snaží udělat co je v jejich silách, rozdíly mezi některými jsou ale obrovské. CSS selektory se musí totiž znovu vykonávat při každé změně DOMu. Nemám ale k ruce konkrétní čísla jejich rychlostí, ale v odborných kruzích se o tom hodně mluví a při uživatelských testech aplikací mám několik bodů na subjektivní rychlost pohybu na stránce.

Právě mraky skriptů a animací je důvod proč google udělal AMP. Není to uzavřená knihovna, je to pouze ukázková implementace, kdokoliv si jí může upravit a používat dle libosti. Řada věcí tam je komentovaných a vysvětlených, tj. ideální místo pro nastudování, jaké problémy existují v současné tvorbě mobilního webu.

Ten JS má 40kb, tj. třetinovou velikost než jQuery a je kešovaný napříč weby, stáhne se pouze jednou.

Pokud jsou na webu obrázky, prohlížeč je stahuje okamžitě. AMP chce obrázky stahovat až mají být vidět na obrazovce mobilu, ve velikosti, která odpovídá rozližení obrazovky (pro iphone třeba s vyšším rozlišením) a nebo je v případě slabého signálu nestahovat automaticky vůbec. Dnešní prohlížeče tohle neumí, souhlas, že by to dělat měli. Netuším ale, proč nenechají obrázky v img a nepřevedou si je při spuštění svého JS, technicky to je možné.

Rozdíl v rychlosti zpracování selektorů se liší i o dva řády, u větších obsahových webů to je nutné testovat. Pracné animace a moc cool selektory způsobují takové to tahavé posouvání stránky, na mobilech to je ještě výraznější. Nejde o obcházení, web snad děláš pro obsah, ne pro design? AMP je primárně určeno na silně obsahové weby.

Samozřejmě se dá jít od W3C, na tohle jsou již pracovní skupiny, ale proces bude trvat několik let a nebude zpětně aplikovaný, tohle funguje dneska. Každopádně třeba se najde i řešení s použitím img tagu, pevně v tom doufám, v zkušebních projektech určitou testovací implementaci máme.

a to bude i skvělý externí zdroj, článek si pro svou aplikaci stáhnete od Googlu ve statické formě, osekáte o stávající formát a vybavíte svým. Tak do své stránky elegantně, automatizovaně a rychle začleníte cizí obsah :-)))

v Americe na ten způsob už přišli, říká se mu zponzorované články. Prosadit tam nějaký produkt aniž bych musel zaplatit několika redakcím, aby na můj produkt napsali recenzi defacto nelze, automaticky to ale neznamená, že mě budou chválit, často to vypadá tak, že si platím jejich čas...

No spíš nechápete kde je rychlost AMP, ta je v automatickém cachování na výkonných serverech Googlu zdarma. Jinak AMP nepotřebujete. Rychlou stránku vytvoříte i bez něj. A můj postup výše je návod, jak toho využít a nebýt tolik omezen.

Ta omezení jsou potřebná pro efektivní cachování na serverech googlu, aby mohly sémanticky rozpoznávat obsah, s ohledem na potřeby cachování.

Takže se z toho stane spíše než formát stránek, formát pro cachování a to třeba i v eshopech.

Stačí si přečíst specifikaci na https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md :
* jsou zakázené skoro všechny CSS selektory včetně selektoru na potomka, souseda atd., takže celý dokument nabobtná přidáním spousty zbytečných tříd navíc
* povinný odkaz na kanonickou verzi stránky, i když žádná kanonická verze neexistuje
* povinně vložený skript https://cdn.ampproject.org/v0.js i pro weby, které ho nepotřebují nebo nechtějí
* přes povinně vložený soubor to nutí autora ještě vložit docela krkolomnou konstrukci <style>body {opacity: 0}</style><nos­cript><style>bo­dy {opacity: 1}</style></nos­cript> - proč?
* tyhle zbytečné povinné konstrukce načítání spíše zpomalí, zejména u krátkých stránek
* tag img je nahrazen nestandardním tagem amp-img s velmi podobnou syntaxí - asi aby to bylo za každou cenu nekompatibilní a delší
* atd.

Takže asi - děkuji, nechci, tudy cesta nevede.

No nejdříve se natáhne javascriptový neAMP zavaděč, ten natáhne cachovanou AMP stránku z jiné url a tu si přidá do DOMu. Na serveru jen AMP stránky dovolí indexaci robotům.

Nebo se natáhne neAMP kostra a pomocí AJAXu se do ní natahají AMP komponenty z url Googlem zaindexovaných a cachovaných jako AMP.

Vlk se nažere a koza zůstane celá.

Takže to znamená nový level šmírování od Googlu...

Jedno z omezení je nemožnost použít formuláře a input elementy.

Není tedy, jak předat stránce vlastní vstup (doručovací adresa, typ platby a pod). Data navíc můžou k uživateli jít rovnou z nějaké proxy / cache a nikdy se nedostat k cílovému serveru (založit objednávku).

+1 Navic kdyz Google tlaci HTTPS?

to už lze udělat i teď a mohu ti říct, že mraky lidí to takhle dělá, jen aby měli obsah na svoje affil reklamy...

Návštěvnost se bude měřit pomocí amp-pixel tagu - trackovacího pixelu. U cachování bych předpokládal praktiky běžné pro normální stránky (HTTP Cache Headers).

Ano, CSS selektory nejsou optimalizované na _časté změny_ DOM, ale tam si člověk nepomůže - změněný podstrom a rodiče se musí přepočítat stejně, a CSS selektory typu a+b nebo :first-child vynutí maximálně přepočítat navíc nějakého toho souseda, typicky pro efekt co to stejně vyžaduje (např. insert prvního elementu do seznamu způsobí změnu stylu původně prvního elementu). Co s tím udělá jejich obcházení jinými konstrukcemi? Nic, stejně se to všechno bude muset přepočítat, jen přidá režii na dosažení stejného efektu.

S obrázky mi přijde nejlepší přidat nový atribut do img tagu - bylo by to jednoduché, zpětně kompatibilní, a Google by si to rovnou mohl přidat do Chromu. Prohlížeč by to mohl dle uživatelských preferencí buď respektovat, nebo dělat i tam kde atribut není, nebo nedělat nikde. Se standardizací u W3C bych si taky nedělal starosti.

aby se využilo cachování a zbytek si dotáhnete dodatečně.

co je na eshopu tak výjimečného, že by nešel napsat v amp? Hry a aplikace chápu, dokonce i v eshopu si umím představit nějakou složitější logiku, ale že by vůbec nešel? To pochybuji.

Stačí se podívat, kdo je autorem. Dalších komentářů netřeba. A předpokládám, že adblock a další budou fungovat i na tomto protokolu.

Dost by me zajimalo, jak na AMP strance vubec budu merit navstevnost. Toplisty, GoogleAnalitics pouzit nepujdou. Jelikoz to bude nakesovane u Google, tak nepujdou ani zadne pozadavky na server, tedy ani z logu nepujde nic vycist. A co kdyz budu chtit takovouto nakesovanou stranku aktualizovat? Smula. Nadhera...

Stačí se zamyslet, proč jsou zpravodajské weby takové molochy. Z mého pohledu jsou dvě příčiny
- obsah v reklamní prostoru
- sociální features, včetně fór

ani jedné z těch věcí s zpravodajské servery zbavit chtít nebudou dokud budou při smyslech a AMP to moc neřeší, nebo to řeší nevyhovujícím způsobem.

Z mého pohledu cesta, kterou jít, je poladěný javascript, který dopočítá potřebnou část DOMu na straně klienta, tj klient si stáhne jen strukturovaná data a potřebné knihovny, které se pro další použití nacachují a zbytek webu dopočítá bez nutnosti stahování hlady kódu navíc.

Btw v čem je distribuční síť Googlu lepší než jiné CDN, které již nyní velké zpravodajské portály jistě využívají?

Je někde popsáno, jak uvedené cachování bude spolupracovat se AMP stránkami dostupnými přes https? Nebo se tiše předpokládá, že všechny AMP stránky musí být dostupné pouze přes http?

Stránky budou kešované na googlích serverech. Z vyhledávání tedy dostanete https link na jiný, než cílový (váš) server. třeba https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/07/us/politics/hillary-clintons-proposed-changes-to-health-law-zero-in-on-affordability.amp.html?amp_js_v=0

Google stahne vaší stránku z vašeho https, uloží ji k sobě a uživateli naservíruje pod svou doménou a svým ssl certifikátem. Nedělá MITM proxy v klasickém smyslu a nevstupuje transparentně do komunikace. Poskytne váš obsah ze svého serveru.

Detaily třeba zde.

Nemyslím si...

pro velké služby (GA, twitter atd.) budou nachystané pluginy, viz citace z dokumentace:

"A number of AMP components supporting features like ads, analytics, and embeds, may rely on third-party JavaScript provided by a specific service. For example: an analytics component from Google Analytics might need to run logic specific to the GA service, or a Twitter embed may need to run Twitter-specific code..."

https://github.com/ampproject/amphtml/blob/0ada6bc79b97112d12e97dabe625f2350f2140ba/spec/amp-html-components.md#service-specific-components

Ten hype je kolem toho neskutečnej :), nejedná se o revoluci a ani vlastní svět. Kdokoliv si můžeš AMP vzít, přidat tam svoje věci a mít web podle sebe. Podobných knihoven existuje celá řada, jen google to umí protlačit. Googlu udělal specifikaci, nabídl ukázkovou implementaci, řekl, že dá zdarma CDN, tj. zminimalizovat vstupní náklady.

V první řadě to chce chápat jako upozornění na problém a nabídnutí řešení, nic víc. V druhé řadě to je další díleček do skládačky "jak oddělit obsah od prezentace", kterým před pár měsící ve velkém začal facebook a teď konečně to má hezčí obrysy.

V zásadě problém existuje, protože technologie postupně dozrávají a programátoři nestačí nabírat zkušenosti a znalosti, klienti naopak nechtějí tohle vzdělávání platit a nevidí v tom přínos, cena a čas je důležitější. Vy, kdo se živíte webem, kolik klientů vám řeklo, že chce max. 100 kb fotky na webu? Kolik klientů dalo do zadání, že se web má načíst do 100ms? Berou to jako samozřejmost a nerozumí tomu, google nabídl něco, co snižuje možnosti, kde mohou vývojáři udělat chybu a dává budoucím webu jasné mantinely pro klienty.

Tady nejsme v USSA. (zatím a doufám, že to tak ještě dlouho zůstane). A je jedno staré české přísloví a sice, že dobré zboží se chválí samo.

No načíst rovnou je nemůžete, protože Google bude jistě časem AMP zvýhodňovat ve vyhledávání, logické je, že musí hledat odpověď na hrozby, které představují snahy uživate uzavřít v bublině facebboku, či apple, a tedy vytvořit si vlastní bublinu. AMP se k tomu hodí.

Indexovat se bude AMP a obsah, který neprozradí, že umíte v AMP stránkách javascript. Kdybyste to tam měl přímo, Google by přestal vaše AMP cachovat. A cachování od Google potřebujete, protože bude rychlé, rychlejší než vaše vlastní.

uhf, třetí článek o AMP na lupě za poslední týden? Trochu moc informací, ne? :)

Eshop na tom lze napsat, ne všechny stránky musí být na AMP. Pro firmy, které mají dostatečné vývojové kapacity není tohle velký přínos a sami si podobné řešení stejně už postavili.

Jako první vznikne javascriptová knihovna, která v mobilu stránku převede na AMP aby si využila cachování od Google. Tím se web zrychlí a nebude třeba používat AMP při návrhu. Možná půjde cachování AMP využít k uložení vlastních javascriptových knihoven, jako obsahu a teprve po načtení se spustí.

Trh si svou cestu najde.

> Jako první vznikne javascriptová knihovna, která v mobilu stránku převede na AMP aby si využila cachování od Google

Takže mobil stáhne plnotučnou html stránku, stáhne ono magickou js knihovnu a převede stránku na AMP. Jak to využije cachování od google nebo cokoliv zrychlí?

> Možná půjde cachování AMP využít k uložení vlastních javascriptových knihoven

Na takové věci se už dávno používají CDN. Netřeba se zaobírat AMP.

Jak se dotáhne onen 'zbytek' dodatečně, když nebude možné v rámci AMP spustit vlastní scripty?

AMP je pouze jinej ksicht k již existujícímu webu, tak aby byla na mobilních zařízeních zaručena určitá použitelnost.

Ano, lze to napsat s jakoukoliv verzí html/js, ale bohužel takových malých jednoduchých webů není moc :). AMP je pouze kompilace ověřených postupů, tak aby bylo zaručeno, že to nikdo nedokáže naprasit. Mnohokrát jsem musel klienta přesvědčovat, že stíny a oblé rohy mu opravdu na mobilní web nedám.

Sledoval jsi někdy při dělání webů kolikrát při které akci proběhl recalc stylů? Kolik času zabere přístup na DOM? Že $(window).width() je šíleně drahá věc? Netvrdím, že amp je boží a musí se používat, tvrdím, že současní vývojáři neumí optimalizovat a psát weby, taky podle toho to vypadá.

Ve FF selector a:after dokáže pěkně potrápit CPU. IE9 má obrovské problémy s [class^="item"], takhle člověk může pokračovat dál a dál. Na malém webu to je jedno, ale najednou příjde web s 10tis elementy na stránce a již se nedá používat a na mobilu to sežere baterku. Nejde o žádnou emulaci, jde o zakázání selectorů, které nejsou vůbec vhodné pro mobilní zařízení.

Spíše bych doporučil si projít zdrojáky amp a pročíst si komentáře a spec, kde je hromada věcí zdůvodněna a popsána. Do tohohle projektu se zapojilo několik velkých vydavatelů, kteří si uvědomují, že současný stav není ok, jestli tohle je ta cesta, ukáže to čas.