Not continuously. The signed content includes an expiration date, which the publisher controls.
This expiration can also never be set more than 7 days in the future.
1,271 karma · joined September 17, 2010
This expiration can also never be set more than 7 days in the future.
On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache.
However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results.
https://github.com/ampproject/amphtml/issues/25873
* There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spe...
Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.
> Can a third-party other than Google deliver an AMP page?
Yes. Examples: Bing runs their own AMP cache and also delivers AMP pages. LinkedIn and Twitter also link to AMP pages, but they don't currently run a cache. IIRC, Twitter links to the Google AMP cache and LinkedIn links directly to the AMP variant on the publisher origin. They could run an AMP Cache. Cloudflare ran one for some time, but shut theirs down recently.
The AMP Project maintains a list of known AMP Caches here: https://github.com/ampproject/amphtml/blob/master/build-syst...
And provides some guidelines for running one here: https://github.com/ampproject/amphtml/blob/master/spec/amp-c...
It's non-trivial, but absolutely supported.
> Can a third-party other than Google deliver a Signed-Exchange?
Yes. Cloudflare generates them for their customers who opt-in via their "AMP Real URL" product. "Generates" in this context implies delivering them. To date, I'm unaware of any large scale implementation that is delivering Signed Exchanges for third-party origins other than the Google Cache though this may change. The tech stack absolutely supports this.
If a signed exchange includes a URL, that URL must be signed for the browser to respect the field.
An AMP page can be identified by examining only the first few bytes of the HTML. The `<html>` tag will contain either the `amp` or lighting-bolt emoji attribute, ie: `<html amp>`.
Technically an AMP document must pass AMP Validation to be truly AMP, so there are documents that match the above condition which aren't valid AMP. There are multiple ways to validate. A starting place is https://validator.amp.dev/
If you click the browser share icon, or trigger the browser native share intent, the origin URL will be shared, not the AMP Cache URL. Only if you explicitly copy the URL bar will the AMP Cache URL be shared.
The Signed Exchange spec that AMP has offered sites for a year now allows them to have their own URLs displayed in browsers that support it. In that case, the google.com URL will never be displayed and thus can't be accidentally shared.
All AMP documents on the AMP Cache contain `<link rel=canonical href={origin url}>` and Google recommends that social media prefers the canonical URL. This is useful outside of AMP as there are often multiple URL variants for any article. The sharer and sharee may not ideally get the same version. As an example, a mobile vs. desktop article.
At the same time, the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.
Signed Exchanges mean the publisher signs the content using their private key. A third party can provide delivery like a CDN, but they cannot modify the content, or the signature would no longer match. The useragent (browser) enforces this. This gives the secure control of the content back to the publisher, unlike the trust model of CDNs or the AMP Cache.
The publisher server must support it, but this results in the document being signed with the publisher's certificate. This won't "date" the signature, but combined with a blockchain solution like this could prove that a web server delivered content X at date Y.
Until the javascript has loaded (a single cacheable javascript file: https://cdn.ampproject.org/v0.js ), the browser can't lay out the resources on the page (images for example).
If the browser rendered the page before layout, it would likely look pretty bad. Then when the javascript arrived, the document would layout again moving elements around. This is typically referred to as the "Flash of Unstyled Content" (https://en.wikipedia.org/wiki/Flash_of_unstyled_content) and is considered by some to be a negative user experience. Many web pages outside AMP take a similar approach to hiding the content until the layout has completed.
The 8 second CSS animation is only present as an "escape hatch" in case the javascript never loads. The specific value was chosen as a time that probably indicates the javascript will never load. Note that if javascript is disabled entirely, the page is rendered immediately via the <noscript> tag. There has been a discussion around changing the 8 second time to something shorter ( https://github.com/ampproject/amphtml/issues/22543 ), though it could probably be renewed.
JavaScript and Web Components are part of the HTML5 standard. This is simply the Extensible Web (https://www.w3.org/community/nextweb/2013/06/11/the-extensib...)
My profile discloses that I work on AMP.
Certainly an ad blocker can be used to block any URL, but I don't know of any that block this one by default. If there are any, let me know and I'm happy to file issues to get that fixed!
If a user chooses to block this particular resource which the page needs to load, then the page still loads after 8s.
Similarly, if the site owner chooses, they can run the AMP Toolbox optimizer (https://www.npmjs.com/package/@ampproject/toolbox-optimizer) which lays out the page server-side and removes this CSS flash for most documents. Some documents can't be laid out until the viewport size is known.
The AMP viewer iframe share button (and share intents) all share this canonical URL, not the AMP url. Google's implementation is trying it's best to get you to that version as well when sharing links.
Link Rel Canonical is an old (2012) standard: https://tools.ietf.org/html/rfc6596
There are about 200 in that list and any network can submit a config to be added, it's just a pull request away.
- Mobify found that decreasing their homepage's load time by 100 milliseconds resulted in a 1.11% uptick in session-based conversion
- Retailer AutoAnything experienced a 12-13% increase in sales after cutting page load time in half
- Walmart discovered that improving page load time by one second increased conversions by 2%
<style>
body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
</style>
<noscript>
<style amp-boilerplate>
body{animation:none}
</style>
</noscript>
The only two cases where the 8s is relevant are: the network connection is so bad that the javascript file fails to load within 8s and the useragent has explicitly blocked the one javascript file on the page, without blocking javascript overall.
a) the origin sharing the resource must place a .well_known/static_resource file in place.
b) The presence of .well_known/static_resource prevents any request on this origin to send cookies, and any set-cookie header is ignored.
c) The document that includes the resource on this sharing origin must use subresource integrity attributes when loading the shared resource.
d) the resource cannot be cached unless the cache-control header is public and has a lifetime of at least 1 hour.
This guarantees that the resource is always requested cookieless, and that the resource can't vary per request, otherwise the subresource integrity check would fail.