It's worth pointing out Cloudflare has a competing AMP serving tool: https://www.cloudflare.com/website-optimization/accelerated-...

I haven't yet seen a non Google hosted AMP page in Google's carousel.

Does that happen? If not, it's somewhat telling.

No, it does not happen, nor will it ever because that's fundamentally not how AMP caching works. A site doesn't pick an amp cache like they pick a hosting provider, with some sites cached on cloudflare-amp while others are hosted on google-amp. All amp content is on all amp caches. Google search is one AMP client, and it uses google's AMP cache. If, for example, bing wanted to serve AMP pages, they would need to choose an AMP cache to serve them from, and cloudflare's offering would be an option. One of the problems that AMP is trying to solve is individual websites hosting on insufficient architecture. If each site was allowed to choose what AMP cache it was served from, that would defeat the purpose. It's up to the client to choose the cache it uses, to ensure a consistent speed.

That's pretty much the point I was making. The wording from Google to publishers doesn't make this clear.

It is the implementation they chose, and it does have speed benefits. But, an edge cache that allows the end user more control, their own domain, an no hijacking header is possible, and would provide a notable speed benefit. If there were a choice between the two, publishers would likely pick the latter.

Publishers had a choice, and they overwhelmingly chose to host their sites on infrastructure that was too slow. That's why the AMP project exists, to take choices like that away from publishers, because they consistently make the wrong choices when you give them one.

Seems to me the right approach would be for sites to embrace the HTML5 semantic tags (<nav>, <article> and so forth), and browsers to offer a way to view just that semantically-marked-up content - without scripts, with restricted CSS, and maybe with some kind of filtering out of third-party content. Something like Firefox's "reader view", but including more bits of the page.

So the browser would still be downloading the exact same HTML document (straight from the publisher's server, how you want it) - just then ignoring all the clutter. Compare to AMP, which AFAICT necessitates serving a whole separate version of the page with only the blessed markup... it reminds me of the bad old days, having a separate mobile site instead of a single responsive design for all devices. All seems rather antithetical to that grand ideal of separating structure and presentation.

An idea I've been floating for a while is to have two HTML profiles in the future. Call it HTML6 document and HTML6 app.

HTML6 document is a restricted subset, similar to what you suggest. I would still allow complete design flexibility, and I might even allow a subset of JS, but only for presentation purposes. Definitely not turing complete, and no ajax etc.. Probably I wouldn't allow cross-origin resources with credentials. So you could include an image or stylesheet, but the browser would not send along cookies. What I'm aiming for is a replacement for PDF, something you could read on an ebook, etc.. Just a plain document.

On the other hand, I'd have HTML6 app to be able to use the complete web platform.

This sounds good as a dream, but in reality it would actually achieve anything because everyone, including the publishers, would just use 'HTML6 app'.

You can make light web pages with current technologies but nobody wants a page without advertisement, popups, analytics and notifications.

HTML6 document is essentially epub, which is HTML and CSS under the hood.

Isn't that pretty much what AMP is? IIRC, you don't need a separate version of the page with only AMP on it - Google's cache just extracts only the AMP parts of your page when caching. Or has this changed since I saw it? (And if so, why - that would probably also be an argument against your solution :) )

Right. Here's the problem and confusion with Google AMP: it's actually two seperate products.

1. There's the HTML/CSS/JS library/subset that's a good framework for building pages that load quickly

2. There's the 'CDN' that integrates with Google Search to preload and 'iFrame' the site in. Google 'has' to host/'iFrame' the content in their own google.com/amp pages because that's the only way to preload a page to make it display instantly.

> I don't mind the idea of having a more standardised subset web page

We already had this two decades ago: WAP, its contemporaries (i-mode), and its immediate successors (XHTML Mobile Profile).

Sure, and those were good solutions for the time - nothing wrong with similar approaches in a modern context.

Big difference was that these had custom renderers. AMP renders in any web browser since they are just web pages.

Except mobile Web adoption in 2002 was poor because of form factor, among other things.

Oh sure. Though I'm not actually trying to criticise the idea of a subset, if anything I'd support it. I'm just pointing to potentially useful precedent. It's not a new idea.

>However, having Google load this structured content and host it on its own platform is a terrible idea.

Google isn't the only party running an AMP cache.

> Content should remain on the publisher's site.

It does. Its also cached by aggregators, and AMP is designed to take advantage of being accessed from a shared cache.

>

That exact caching has to end.

They can offer to do a CDN like CloudFlare, but make it optional.

I want to ensure that not a single bit of my data ever runs through Google's infrastructure, while still getting all the same benefits as if it did.

If Google treats sites different just for using an AMP Cache, then I'll have to send another complaint to the EU Antitrust committee.

My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)

I can't just massively increase load time for pages just for a better ranking in search results, this shouldn't even be a choice.

Google using their search monopoly to create a distribution monopoly is also extremely worrying.

Nah man, it's all good. I mean sure, we keep giving absurd amounts of power to an ad company but it's google, who doesn't love google.

If it was microsoft they already would have shut this down because of the backlash. Google does it and people are fine with it.

Isn't that an antitrust move by google?

> Google using their search monopoly to create a distribution monopoly is also extremely worrying.

Google is using any means possible to keep the web (html, js, css) relevant in the age of native apps (that includes Facebook app running on Android). If the web stays relevant, the same goes for Google search.

In contrast, I think google is making every effort possible to direct people away from the web and into the Google ecosystem. Searching for maps? Google. Searching for flights? Google. Searching for information? Google. The list goes on, and the technical means for delivery is essentially irrelevant.

Rich snippets is the catch all for everything else.

You can see a preview for what that means by checking out Wikipedia's traffic decline over the last 3 years or so.

To be fair, at least in wikipedia's case, that's potentially a good thing. Wikipedia isn't ad-supported, so having their data hosted elsewhere isn't actually a problem (as long as credit is given and so donations continue), because it becomes less expensive for them to host.

Definitely trying, but overreaching. The public is starting to cut out Google/the middleman and it's really just forcing shoppers into Amazon's ecosystem, those searching for flights to Skyscanner etc.

> Putting too much content in one place is dangerous for competition

Considering we're on the precipice of a global authoritarian-populist cycle, there are non-market consequences to such concentration, too.

What is an authoritarian-populist cycle?

Brexit, Trump, FN, Erdogan, etc.

What makes you think we're on this precipice?

I'm surprised if you think otherwise.

WE are on the mercy of few SV companies and whatever they decide or push is our fate.

> Putting too much content in one place is dangerous for competition.

Only in this weird world of third-party-served-js-ads.

In an ideal world, I wouldn't care about where my content is served from. I just care 1) that many people see it, and if it is commercial 2) that I get money for it. I could just add some ads as inline to my article, served in the same way as my article's illustrations are. Not sure google allows that, though. Wouldn't surprize me if not.

I didn't realize AMP content was hosted by Google.

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.

Ever heard about RSS? ;)

>Content should remain on the publisher's site.

Publishers are free to implement their own cache and host their own content. AMP is open source and they can modify it however they like.

I mean that when you click a search result in Google you should go to the publisher's site, not to Google's cache of the content. It may have changed since, but that's how it was implemented originally by Google:

https://www.wired.com/2016/02/googles-amp-speeding-web-chang...

"…but there’s a big catch: if readers decide to share a link to an AMP page they’ve clicked on through a Google search, the link points to Google.com (for example, google.com/amp/yoursite.com/yourpage/amp), not to your site. A Google spokesperson confirms that there isn’t a way to both have your AMP-optimized appear in Google’s prioritized search listings without having that content hosted on Google’s AMP Cache servers."

I was under the impression that the publisher could elect to use their own servers for their AMP content. Is this not possible anymore?

There's a lot of doublespeak around this.

1. You can (and must) host AMP content on servers of your own choosing.

2. Google's crawlers ingest your AMP content, validate it, and re-host it in Google's AMP Cache. Bing and other folks run similar crawlers and caches.

3. Google search results will only link to AMP content on Google's own cache.

So yes, you can host your content on your own servers. And you can give people direct URLs to that content. But Google users will only ever see links to the copy of your content that Google hosts; your servers never see that traffic.

There is no way to opt-out and still be considered a valid AMP page.

Publishers already host their own AMP content. Google caches that content, but anyone can go to the publisher's URL and get it directly.

Disclaimer: I work for Google and have some involvement with AMP.

If by "anyone" you mean "my tech savvy friends at google" then yes. I've seen many friends end up on a google-hosted AMP version of a webpage, unable to complete whatever ticket purchase etc they needed because whatever autoAMPifyer the origin site uses produced half broken pages. These users have no idea what AMP is or why the page doesn't work (or that they could have reached the origin site directly if they click around on several unlabeled half-invisible icons in the fake-address-bar on top). In fact, they don't even realize they aren't browsing the origin site. They just give up.

Conceptually this isn't all that different from having a website that works in browser A but not B due to insufficient testing. Why did they not fix it?

Because how many website operators continuously google their own web site on mobile devices to click through to experience their google-hosted AMP editions? I would wager it's a fairly small % of the number of websites running an auto-AMP-ifying wordpress plugin, for example.

I've seen plenty of badly designed mobile websites over the years and these sites seems to have turned out okay - most mobile browsers keep the option of "Request Desktop site" very accessible for a good reason.

The worse case I've seen is a site in which every page crashed Mobile Safari without fail regardless of which version you ask for. It was eventually fixed but I never figured out why. If the sites are just running some script without checking then the admins have failed their line of duty.

Well, I suggest you start giving AMP content that isn't in Google's cache the same preferred treatment in search results that you give cached content.

I'm just going to file another complaint to the EU Antitrust committee otherwise, as this is a simple and clear violation. (Although I doubt my own complaint would be very relevant — all large publishers already have filed such complaints, and Google will be fined for it).

My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)

I have the choice between a massively worse user experience, or worse search ranking. And that's a choice that's just not acceptable to me.