The example page for amp-html, as well as the few amp-html sites available right now, contain the following code:
<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>
Why is this? Setting the opacity to 0 for Javascript-capable clients seems like a bad idea if time is of the essence. The JavaScript that takes care of setting the opacity to 1 may not be cached and download slowly, or may not load at all (China tends to block Google servers, for example, so Google CDN may be problematic).
Wouldn't it be better to simply not change the opacity at all, and only use JavaScript for improving the page? What is the improvement of using amp-html over simply not using Javascript at all?
AMP uses custom elements from Web components. For example, the component amp-img replaces each tag <img>:
These components can […] Replace HTML5 elements that are not directly permitted in the specification such as amp-img and amp-video. [source]
Like with a JavaScript application, it's better to hide the page during the initial DOM manipulations.
AMP manages to load the resources lazily and in the best order. It is designed for rich content on big pages:
But how do we get from good to, let’s say, instant? We’ll cheat :) AMP documents are from the ground up designed to be efficiently pre-renderable. Browsers have long supported pre-rendering through the
<link rel=prerender>tag, but they need to be conservative about this mechanism because prerendering can be expensive. With AMP HTML we added the ability to tell a document: render yourself, but only as far as what is visible above the fold and only elements which are not CPU intensive to minimize the cost of pre-rendering. With this mechanism in place, referrers of AMP document can initiate rendering of docs before the user acts much more aggressively, so that in many cases the document will be done rendering by the time the user clicks. [source]