The pages load fast, they are just styled to not be visible until after 8 seconds.
For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock:
scientias.nl##body:style(animation: none !important;)
When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay.
The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.
They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start.
> Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched.
It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?