Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can someone explain How is this killing the open web? Isn't this an open standard?


It's not the standard, it's what google does to amp sites: re-hosts them on their own site so your site is now (essentially) google.com/yoursite.com.

AMP as a standard is great: limit javascript to a known set of behaviors, ensure images/etc all have defined sizes so content doesn't jump around... but google's using the benefits of this standard as a trojan horse to route even more web traffic to their servers, enabling them to get better and better analytics and insights to your browsing behavior. (Now all the things users do on your site are visible to google too, even after they've "left" the search results).

The whole thing sets off alarm bells and indicates an overall strategy that's aimed towards moving the web into a google walled garden. There's all sorts of dystopian futures we could imagine here: promote search results that are AMP, while users appreciate the speed benefits, and become less likely to click any non-AMP links, and suddenly every web publisher has to get on the train or lose viewership... so that they can monitor yet more of what we do online, widening their competitive moat, etc.

It's scary stuff and there needs to be a CLEAR separation of the benefits of AMP as a standard, from what google's doing with it.


But it's entirely opt-in -- how is this controversial?


Because users seeing AMP links as faster will pressure more sites to do it.

Keep in mind, AMP pages on google aren't just fast because you're not using bloated javascript, they're fast because:

- The JS that is used is CDN cached and shared with all other AMP sites

- You're loading the content from the same origin (google.com) so no need to establish a new TLS connection, or look up DNS, etc

- Google's servers/networking/etc stack is very fast, faster than what is in reach of most sites

- The new content is loaded into the existing DOM of the search page, which can be much faster

And probably the most damning:

- Google will eagerly-load the contents of the first few results, making them not just fast but 100% instant.

What choice do sites have?


> What choice do sites have?

Offer better experiences on their websites and apps, the technology is available but publishers choose to shovel crap in with food and call it beef tenderloin. Now Google is offering something better.

What did you expect Google to do when Apple News Format and Facebook Instant Articles are creeping up? Both offer impressive experiences and this isn't even nearly as impossibly mind-boggling.

AMP is an open standard that any publisher and any search engine can implement and if all search engines get on board then users win so much -- pages load faster, they require much less network bandwidth, they're easier to read. Nobody, absolutely nobody, will have sympathy for publishers after all the bullshit we're being forced to experience both now and historically.


I can?

I'm running my own sites, no ads, mininal content.

How do I get the preferred treatment in the Google sesech that AMP pages get again?

(My pages are all tested on a Huawei Ideos X3 on 64kbps GPRS internet. They always load consistently faster than AMP pages)


If your argument is "other walled gardens are doing it too", it sounds like we have the same understanding of the problem. You just seem to think it's ok and I don't.


My argument is Google took an alternative road here, like they did with SPDY and HTTP/2 development -- they developed an open standard and threw their weight behind it. I don't see how AMP is a walled garden since any and all other search engines are free to implement the standard as well. Content aggregators like HN can cache and serve up AMP pages as well.

The only controversial thing here is this: publishers' content is being cached and re-hosted on a platform outside of their control. This is a non-issue because publishers are opting into this system.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: