Yes, AMP is rather slow: https://timkadlec.com/remembers/2018-03-19-how-fast-is-amp-r...
and looks fast mainly because Google preloads it: https://ferdychristant.com/amp-the-missing-controversy-3b424...
and looks fast mainly because Google preloads it: https://ferdychristant.com/amp-the-missing-controversy-3b424...
Nowadays, the landscape is way different. There are just so many "normal folk" on the internet now that content is being consumed at an alarming rate. There is so much stuff on the internet now, that even Youtube videos have become disposable. Most of the stuff that people read and watch now is consumed once and then never visited again because there's just not enough time to revisit the insane amount of content we're exposed to.
Nowadays, why does it matter if a website is made "brittle" if the content isn't going to matter in a few months anyways? And if you do want to archive something for later, shouldn't the words on the page matter more than the code behind it? After all, if a user 12 years from now wants to read your article, all they're going to want is your words and pictures. Code is always brittle because new technology makes everything obsolete.
One reason is brand perception. If your website is significantly slower and/or brokener than a competitor's then eventually people will stop coming back. Presumably you want your brand to last more than a few months.
AMP is also a worse experience than that was because in the 90s you were usually waiting on images to render and progressive display was usually possible so you could start seeing that fuzzy JPEG fairly quickly and read the rest of an article, whereas AMP by design prevents anything from displaying until it’s loaded and executed correctly so you often have to reload the page to see anything at all when it fails.
This matters because most of where AMP was marketed to are competitive fields and that means it’s training users that they’ll get what they want faster and more reliably somewhere else.
When comparing AMP pages to their associated canonical pages, the most striking difference is that AMP pages are significantly lighter (905 KB vs. 2,762 KB) and load significantly fewer assets (61 vs. 318 requests). (All numbers are median values from testing 50 pages.)
Many people have slow phones and expensive internet, and for them this difference enables them to browse news sites, literally.
See http://text.npr.org or http://lite.cnn.io for example
For example, AMP provides an ad component that is probably the by far most performant way to display ads on the web. Without AMP, the site has to use alternative ad solutions, which probably perform worse and load more JS.
The only way for the site to reduce JS would be to find an ad solution that is similar to AMP in terms of performance, and I fear such a solution just doesn’t exist.
Simple ads can be served statically without JS.
(Disclosure: I work on ads at Google, but I don't know much about how our spam detection works and I couldn't talk about it if I did.)
And if you think a whitelist would work, all it takes is one look at how rapidly new JS libraries come and go to render that unfeasible