The original content is still on the website, Google hosts a cache server, rehosting the website's content around the world closer to the users for faster access, for free.

In theory, it's a win-win-win situation. Publisher gets free hosting (with analytics and ad money still coming to them obviously), users get a faster experience and Google is happier if the users browser more content.

In reality, AMP is obviously not perfect but they have been addressing common issues and improving. I may not be fully sold on it yet, but I don't understand the massive blind hatred.

Saying "people can just optimize their website" doesn't mean shit. They've had years and no one has been. Sites have been getting slower every year despite browsers getting faster. No one gave a single shit until AMP came around...

The main problems I have are that it breaks two really important web features: sharing links and trust. Users seeing google.com URLs means they trust them more, which has helped propaganda sites and phishers.

The other thing is that for me, AMP has not been faster many times. I know they're working on it but having to download and run 100KB of external JavaScript before rendering frequently meant that it was slower than the real page. It helps the stragglers but e.g. WaPo or NYT load just as fast and that should be enough.

Tap the link icon at the top of the page. Then long press the URL that appears. Or short press it then use your browser's share menu.

I'm aware of that but it's new – it took a year to add, giving many time to develop a negative association with the icon – and it's still clumsy compared to the standard web experience.

With real web pages, the native sharing UI just works as it does everywhere else.

With AMP, you have to know to tap a different unfamiliar icon and then know that the unstyled URL displayed is actually a link you can interact with. That means that sharing goes from one tap to 2-3 and that's after people learn that Google gives substandard results doing what they're familiar with and so you need to remember to do something else only for pages which you found on Google.

That's also not an alternative — Google can't be allowed to treat pages different in their results just for using Google's AMP Cache.

An AMP page served without cache has to be treated the same, or this becomed exactly the freedom issue that this entire discussion is about.

My pages are actually optimized a lot, and they actually get about 10x slower with AMP than without.

I don't want to have to choose between fast loading and good SEO, I want both. And Google only offering good SEO to those who let Google track all user interactions with their page is also not ideal (I specifically do not use any ads, analytics, or tracking, not even storing IPs in the server logs).

I doubt that CDN is really that important. Maybe if your site serves content overseas then there is a difference but what about a website in a relatively small country that is visited mostly by locals? The CDN doesn't make big difference here.

If your server supports HTTP/2 and has a connection with a good bandwith then static resources can be loaded really fast without any CDN because all the resources can be loaded in parallel without waiting in a queue.

The real motivation for publishers to implement AMP is that they hope to get better position in search results.

Google has, and should, downranked slow pages in favour of fast ones.

But instead of simply pushing that aspect harder, they're actively promoting their own tech.

> Google has, and should, downranked slow pages in favour of fast ones.

They do.

Yeah, one of the biggest problems with AMP is that it works very differently than how the documentation leads you to think it works.

It is interesting that AMP is about the only edge cache that doesn't let you use your own domain. Cloudflare is fairly good evidence that it's workable at scale. Of course, that would eliminate the hijacking header and Google control over the URL.

Edit: Disagree? What part isn't true?

Do you think Google wants to hijack the URL and add extra chrome? They don't. They want the absolute fastest performance which requires prerendering which requires hijacking the URL. (This seems like a bad tradeoff to everyone on HN.)

That extra chrome didn't even include a way to see the original URL until after much squealing. It did, however, include left/right swipe to other people's content. The MVP that rolled out fairly clearly shows who benefits.

An edge cache of an optimized page is plenty fast without preload. Images, in fact, can be preloaded cross domain if that is really needed.

You know it's a mess when the New York Times has to inject a "sorry this video doesn't work on AMP pages, visit our site" message on stories.