Vlákno názorů k článku AMP opravuje a zároveň rozbíjí World Wide Web od VM - Stačí si přečíst specifikaci na https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md : * jsou...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
VM (neregistrovaný)
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><noscript><style>body {opacity: 1}</style></noscript> - 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.
-
Tomáš2 (neregistrovaný)
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.
-
VM (neregistrovaný)
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í. -
Tomáš2 (neregistrovaný)
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é.
-
VM (neregistrovaný)
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.
-
Tomáš2 (neregistrovaný)
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.
-
VM (neregistrovaný)
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.
-
Tomáš2 (neregistrovaný)
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.
-
VM (neregistrovaný)
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í.
