AMP web bez js

kajak21:
„Ahoj, k čemu je dobrý AMP?“
To bych taky rád věděl. Zatím se mi nezdá že by tato technologie byla nějak široce implementovaná. Osobně to zatím považuji za pokus googlu, který snad časem vymizí.

Keeehi:
Na AMP chodí lidi z google, bingu, pinterestu, twitteru, ...
AMP je v podstatě framework na základní komponenty webu. Primárně jej ale některé vyhledávače (google a bing) cachují na své straně, takže se načítá opravdu rychle (+jej třeba google začne načítat ještě než uživatel na tvůj web přejde, takže je to fakt rychlost).
Zatím bych asi nedělal kompletně celý web v AMP, ale i když to taky jde :) Primárně jde o landing pages, přes které návštěvník přijde na tvůj web. Ty zobrazíš v AMPu, přednačteš si potřebné věci pro ostatní stránky a pokud z té stránky uživatel jde dále, zobrazuješ mu už normální verzi webu.
Pokud má uživatel vyplý js a přijde na tvou amp stránku (odkud ale?), zobrazí se mu prakticky jen text, protože ostatní elementy prohlížeč nezná. Toto ale můžeš vyřešit přes noscript, který muže obsahovat i některé ne-ampové tagy (img, video, audio).

AMP je podľa mňa blbosť, síce by sa so mňou v tomto Martin Michálek hádal, ale má to mnoho mnoho nevýhod:

nemáš vlastnú URL
nutnosť udržovať 2 verzie webstránky (neco jako v časoch starších IE)
mnoho omedzení, závislosť na komponentách, ktoré si nevieš úplne prispôsobiť
chýbajúce komponenty a funkcionality
náročnejší vývoj

výhody sú len prednačitávanie, všeobecne ale načitávanie nemusí byť rýchlejšie než kdyby si písal obyčajnú HTML stránku. Ja bych do AMP nešel.

Mlocik97:
"všeobecne ale načitávanie nemusí byť rýchlejšie než kdyby si písal obyčajnú HTML stránku"
Pokud je stránka nacachovaná u daného providera, tak si dovolím tvrdit, že rychlejší bude vždy.

Na vlastní URL se pracuje, ale protože uživatel na amp přichází skrze vyhledávač, moc to nevadí.

Komponent je už docela dost, přizpůsobit jdou taky dobře, viz třeba www.google.com/amp/s/www.lekarna.cz/amp/brufen-400-10x400mg-potahovane-tablety-4 ale jo, člověk tím výběrem může být omezen.

Náročnější vývoj je jasný - u většiny webů musíš udržovat dvě verze frontendu.

blaaablaaa:
"Pokud je stránka nacachovaná u daného providera, tak si dovolím tvrdit, že rychlejší bude vždy."

skutočne? ja si dovolím tvrdiť opak... moje PWA v Angulari sa načíta a vykreslí do 20-30ms (Full Load, resource ~150kB, nacashovaná priamo v prehliadači) pri EDGE sieti (ak nenastali zmeny, tak sa často vymení len 1 paket [ETag / SHA1], a web sa vykresluje už pred kontaktovaním servera). Teraz mi niečo povedz o AMP. Až ma prekonáš s AMP, uznám ti pravdu.

Teda len pri prvom načítaní bude AMP "možno" o trocha rýchlejší, i když ne, lebo načitávanie začne skorej, ak počítame od štartu načitávania, a nie od štartu kliknutia uživatela, tak je AMP hodne často pomalší, minimálne o načitávanie AMP javascriptu, ale ak to rátame od kliku uživateľa, tak AMP len díky prednačitávania sa zobrazí o pár milisekúnd rýchlejšie, ale i tak to nemá zmysel riešiť. Jestli kvôli pár ms len pri prvom načítaní obetuješ všetko ostatné, tak je to fakt blbosť.

Áno pracuje sa na vlastnom URL, ale bude to len klamanie prehliadača. Inak pozor, rozdiel je AMP framework a AMP distribuce. Ak hovoríme o frameworku, tak ten sám o sobe nerieši prednačitávanie. Takže je to total sračka a len AMP distribuce je niečo čo má nejaký zmysel, a vieš že AMP distribuce sa plánuje premeniť tak, že aj bežné stránky budú využívať podobných princípov (preload), ak bude stránka splňovať podmienky ako responzivita, rýchlosť načitávania, a pár ďalších).

To pak už AMP uhyne...

Mlocik97:

AMP se aktuálně používá primárně právě na první načtení - tedy přechod z vyhledávače na web.

Rychlost EDGE je většinou kolem 20kB/s, takže 150kB stahuje cca 7 vteřin, gratuluji, že tvůj web to zvládne za 20-30ms. Reálnou rychlost si zkus třeba u té lékárny, kde mají AMP nasazený na detail produktu.
A jde právě o to co nejrychleji dostat uživatele na web. Jinak AMP skripty se načítají z cdn, takže je pravděpodobné, že ho má browser nacachovaný. Uživateli je jedno, odkdy chceš měřit rychlost webu, ho zajímá, jak rychle se mu stránka načte a je mu fuk, jestli je to AMP nebo cokoliv jiného.

Uživateli je jedno, co je na pozadí a většina uživatelů neví, co to je url.

A bůh ví, co bude s AMPem.

blaaablaaa:
zhodnem se na tom že se nezhodnem.

kajak21:
práve preto že je na CDN tak je tam URL CDN serveru a nie tvoje. typicky: https://google.com/amp/s/tvojaurl.com/podstranka/ namiesto prostého https://tvojaurl.com/podstranka/

kajak21:
je to www.google.com/amp/s/tasty.co
ono jde o to že tá webstránka má 2 verzie, a cez kanonickú adresu sa odkajuze AMP na regulárny web a naopak. Ak na PC v prehliadači otvoríš tasty,co a to máš v adresnom riadku, tak sa ti nenačítala v skutočnosti amp verze z CDN, ale zo servera kde je web hostený, ten ale není distribuovaný AMP spôsobom (preload, cashovanie atd) Inak ak si všimneš tak na desktope máš u tej stránky no AMP verzi s touto URL, a na mobile máš AMP verzi s URL googlu. Alebo si zadaj tasty.co do vyhladávača jak je to indexované, uvidíš niečo takéto:
ctrlv.cz/d1HU a po kliknutí na prvý odkaz ti otvorí:
ctrlv.cz/5dHG

To že webstránka má v zdrojáku znak AMP automaticky neznamená že je distribuovaná z AMP CDNka, preloadnutá, cashovaná ani nič. Môže aj nemusí. Prečítaj si vzhurudolu.cz kde je to pekne vysvetlené. Ak by si tvoril len jednu verziu, čisto AMP tak bys mal len google.com/amp/s/tvojaurl.com/
skutočne,... preto sa to plánuje riešiť novým protokolom signed-exchange amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange to ale ešte nefunguje (plnohodnotne, čiastočne áno, ale ešte to navyše predstavuje bezpečnostné riziko, preto to i mozilla označila ako harmful: mozilla.github.io/standards-positions.
wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html



"
Description
This document specifies how a server can send an HTTP request/ response pair, known as an exchange, with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks.
Mozilla's Position
Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed.
"


tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08

kajak21:
Normální a AMP stránku provážeš skrze canoninacal/amphtml metatag. Takže novou stránku google zaindexuje stejně jako klasickou html a většinou i převede a uloží na své cdn. Pokud AMP stránku poskytuješ přímo mimo cloudfare/google/bing cdn, chová se vlastně jako obyčejný html/js framework.