
Google to start sending search traffic to fast-loading AMP articles in Feb 2016 - kevindeasis
http://venturebeat.com/2015/12/09/google-will-start-sending-search-traffic-to-fast-loading-amp-news-articles-in-february-2016/
======
franze
ok, lets take a look at
[https://www.ampproject.org/](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)

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

~~~
chatmasta
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...](https://www.ampproject.org/docs/guides/third_party_components.html)

~~~
finnn
>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](https://www.ampproject.org/docs/reference/amp-ad.html)

------
finnn
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

------
wiffleballmike
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?

------
nattaylor
Previous discussion on AMP:
[https://news.ycombinator.com/item?id=10507902](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.

------
jtwaleson
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.

~~~
shostack
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-...](http://highscalability.com/blog/2015/12/14/does-amp-counter-an-
existential-threat-to-google.html)

------
frik
WAP 4.0

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

~~~
franze
more like cHTML 2.0
[https://en.wikipedia.org/wiki/C-HTML](https://en.wikipedia.org/wiki/C-HTML)

------
patrickfl
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](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.

~~~
cbowal
AMP versions have their own meta tag.

<link rel="amphtml" href="AMP-URL">

It's not very well documented.

------
blackkettle
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](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...]

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

[https://github.com/ampproject/amphtml](https://github.com/ampproject/amphtml)

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

~~~
nattaylor
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-...](http://www.nytimes.com/interactive/2015/10/01/business/cost-
of-mobile-ads.html?_r=0) ...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](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.

