Hacker News new | ask | show | jobs
by lern_too_spel 2327 days ago
AMP is faster by design, and it is impossible to get a generic HTML page to load as fast from a SERP (even a non-Google SERP), so your .NET analogy doesn't fit. Is it an antitrust violation that other search engines (Bing, Baidu, and Yahoo! Japan) also prefer AMP results?
2 comments

It's not "faster" if I have to wait for the AMP site to load, then figure out where to tap in Google's UI to get the page I actually wanted to go to, then wait for it to load. Especially the case if I want to share the url (the real one, not the AMP one).

I don't need an intermediary popup page between me and the destination I seek.

If the AMP page doesn't have the content you want and the non-AMP page does, that is the publisher's problem and the search engine's problem for displaying an inferior page. It is not a problem with AMP, which usually has the information I need. Similarly, if a mobile-optimized page does not have the same content as a desktop page, that is also a problem with the publisher and the search engine. The same for if an RSS entry does not have the full content of an article or if a transit feed does not match the data that is on a transit provider's web page.

> the real one, not the AMP one

Is that the mobile URL or the desktop URL? This problem has existed for ages. It's the user agent's problem to give a UI to share the canonical URL if that's what the user wants.

> If the AMP page doesn't have the content you want and the non-AMP page does, that is the publisher's problem and the search engine's problem for displaying an inferior page.

Actually it ends up being my problem. I don't want multiple versions of the same thing. AMP is yet another format and it's one that is outside of normal web browsing workflow.

> Actually it ends up being my problem. I don't want multiple versions of the same thing.

Then don't make AMP, mobile-optimized web pages, RSS, Apple News, Facebook Instant Articles, etc.

If you want wide distribution, you have to support multiple formats. At least AMP, like RSS and mobile-optimized pages, is open, meaning that anybody can (and many link aggregators do) consume it.

Publish open specs for lightweight sites and grant them preferential placement in search results.
These companies have already published specs and tooling for making lightweight sites. Lightweight sites are slower to load from the SERP than AMP, so the search engines would continue to favor AMP results.
Just because other search engines jump on the bandwagon of caching sites so they can track EVERYTHING a user does (oh yeah it's speedy too) doesn't mean it doesn't break the open web. Centralizing the way everyone browses the web is how censorship happens. Now governments just have to put pressure on the 1 or 2 dominant players on mobile search and then no one will ever be able to access unapproved information ever again.

It's also convenient Google is trying to delete the url bar and take away the only means for other sites to become a destination on mobile. Controlling all the apps and getting their 30% cut wasn't enough, they have to make it so you have no idea where you are anymore on the web so you forever stay in Google's walled garden.

> Just because other search engines jump on the bandwagon of caching sites so they can track EVERYTHING a user does

Do you have the same complaint about RSS aggregators? About transit feeds? About microdata? About showing page summaries in search results? Why not? All of these keep users on the search engine just like AMP, but they give a better experience to the user. If one search engine didn't prerender AMP, it would lose users to the other search engines that do.

> Centralizing the way everyone browses the web is how censorship happens.

I can see how this applies to Apple News, which requires direct integration with Apple, but anybody can ingest AMP and the other formats I listed above, and many companies do.

> It's also convenient Google is trying to delete the url bar and take away the only means for other sites to become a destination on mobile.

This is separate from AMP, but if a user doesn't like it or anything else a particular browser does, they can easily switch to another one (as long as they're not on iOS).

The issue is that AMP forces companies to use a lightweight site instead of just letting them know how to build a good lightweight site. When you can't include a bunch of bad legacy code and a bunch of off-site resources, the page speeds up dramatically regardless of if it's amp or not. Unfortunately the only thing that made this push happen was Google prioritizing AMP.
> When you can't include a bunch of bad legacy code and a bunch of off-site resources, the page speeds up dramatically regardless of if it's amp or not.

This is true, but my point was that just doing that will still leave it slower than AMP, so the search engines will still prefer AMP results.

AMP pages can be safely prerendered, which is what makes all other options slower. If you defined your own HTML subset that allowed safe prerendering, you will have simply reinvented AMP, and you might as well contribute to the AMP project instead to get all the existing search engines to use it.