Google to start sending search traffic to fast-loading AMP articles in Feb 2016 | Hacker News Reader

Google to start sending search traffic to fast-loading AMP articles in Feb 2016

venturebeat.com

59 pointskevindeasis16 comments

ok, lets take a look at https://www.ampproject.org/ which is a valid amp document.

  page speed insights
  https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.ampproject.org%2F
  mobile 68/100
  desktop 59/100

  webpagetest.org 
  https://www.webpagetest.org/result/151214_DW_X81/ 
  first byte: 0.225s
  start render: 0.816s
  speed index: 3396

compare it to one of my sites where we did some speed optimization (wordpress based / responsive design)

  page speed insights
  https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.veganblatt.com%2Fnatuerliche-antibiotika
  mobile 71/100 (mostly thx to jquery)
  desktop 90/100

  page speed insights
  https://www.webpagetest.org/result/151214_4T_X91/
  first byte:0.145s
  start render: 0.712s
  speed index: 797

Amp is not per-se fast(er). But for this, they crippled HTML5, basically want us to forgo responsive design (responsive is not (only) about mobile), oh, and buy into another google dependency.

and why? just because publishers are too lazy to make sites fast, and too dependent on third party crap (ads & an unbelievable amount of other crap).

As a publisher and user, I hope Amp succeeds in disrupting the way publishers publish mobile.

As a developer: OMFG, they throw the baby out with the bathwater. (they = Google, baby = html5, bathwater = internet)

Seems a fairly pointless tech to risk upsetting regulators over. What's the deal? "Use our <silly tech> or lose your ranking!"

I'm surprised you're getting downvoted, because this seems like a valid criticism and was the first to pop into my head as well.

How is this not anti-competitive? Google is favoring the ranking of sites that use its own tech. According to the AMP docs on third-party components [0], only 5 ad networks are supported, most of them Google-owned.

[0] https://www.ampproject.org/docs/guides/third_party_component...

>AMP supports loading the bootstrap iframe that is used to load ads from a custom domain such as your own domain.

according to https://www.ampproject.org/docs/reference/amp-ad.html

No TLS requirement (that I can find). That's a shame. If they're going to be forcing publishers to get their shit together, you would think they would at least add basic TLS (if not full http/2.0 or something). I suppose since it's going through their CDN it's encrypted when it reaches the end user, but there's still the connection from their CDN to the publisher

Don't publishers themselves have control over their own page? Between this and Facebook's Instant Articles, should it be clear to publishers that their 2 largest source of referral traffic is telling them their site is too slow. What am I missing here, why aren't publishers seeing the light?

Previous discussion on AMP: https://news.ycombinator.com/item?id=10507902

If nothing else, this seems to be making publishers rethink the cost of adding extra stuff on to content, which will hopefully be good for users.

Interesting that they do this via partnerships with news outlets etc.

Last year they adapted search rankings to get everyone producing mobile-friendly pages. They could have done the same here. Great for getting the web forward, but it's a bit mafia like. "Nice 1st search result you have there, would be a shame if something happened to it...". I would like if it they used this again to get other things on everyone's prio list: IPv6, HTTP/2.0, page load time. It's a bit of a nuclear weapon, but it gets things moving.

More on topic: I have the strange feeling that AMP will somehow help them to "inline" the search results like they currently do with wikipedia etc.. That way your site becomes just a data source for Google, they're not actually driving traffic to it.

This is where my questions drift to as well. What is the strategic play here? With FB's Instant Articles it is obvious they want to keep users on the FB platform and eventually tighten the noose on publishers while avoiding any ad blockers. Can't say I blame them.

Not totally clear on what the end game is with Google here. They make a substantial portion of their revenue from the display inventory these publishers provide.

--EDIT--

Just found an article that does a great job answering some of these questions.

http://highscalability.com/blog/2015/12/14/does-amp-counter-...

WAP 4.0

(at least AMP reminds me of WML and WAP, that we had on Nokia/Siemens/Ericson cell phones 15 years ago)

more like cHTML 2.0 https://en.wikipedia.org/wiki/C-HTML

Just curious, I've been through the documentation a few times. Is there any kind of special sitemap we are going to have to do for each page. For instance lets say we have:

http://www.example.com/normal-page.html

and AMP enabled:

htpp://www.example.com/normal-page.html?ampenabled=1

I realize a lot of people are going to do this with dynamic URLs or plugins, will Google just crawl these on their own?

Also does anyone have any ideas for menus in AMP pages? SO far all the solutions I've seen don't have menus. I'd hate to see all this extra traffic and no way for visitors to browse other pages.

AMP versions have their own meta tag.

It's not very well documented.

Does this differ significantly in principle from the proxy-compression that Opera Mini has been doing since ~2006?

https://en.wikipedia.org/wiki/Opera_Mini#Functionality

Or is it primarily a new/better/alternative implementation of the same idea [probably it was also done by someone else before OperaMini...]

Is it ironic that the AMP build is currently claiming to be broken?

https://github.com/ampproject/amphtml

Or that it makes pages faster to load by adding a Javascript library?

If publishers behaved themselves then adding Javascript for optimization would be odd, but they don't behave: http://www.nytimes.com/interactive/2015/10/01/business/cost-... ...but overall I agree it does feel strange to have worked to hard to have highly capable browsers and then only use a tiny subset of functionality.

From: https://www.ampproject.org/docs/get_started/about-amp.html

  AMP JS

  The AMP JS library implements all of AMP’s best performance practices, manages resource loading and gives you the custom tags mentioned above, all to ensure a fast rendering of your page.

  Among the biggest optimizations is the fact that it makes everything that comes from external resources asynchronous, so nothing in the page can block anything from rendering.

  Other performance techniques include the sandboxing of all iframes, the pre-calculation of the layout of every element on page before resources are loaded and the disabling of slow CSS selectors.

  To learn more about not just the optimizations but the limitations, read the AMP HTML specification.

Reply on news.ycombinator.com