Google's (AMP) Accelerated Mobile Pages Project Starts Early 2016

[engine]

Google's AMP (Accelerated Mobile Pages) is due to appear early 2016, according to a blog post on the topic.
Since it was announced it seems there's been a rapid increase in interest, and a number of companies and systems getting involved, including AdSense, Outbrain, AOL, OpenX, DoubleClick, and for analytics, comScore, Adobe Analytics, Parse.ly and Chartbeat have said they intend to provide analytics for AMP pages within their tools, with Nielsen, ClickTale and Google Analytics joining in.

Google will begin sending traffic to your AMP pages in Google Search early next year, and we plan to share more concrete specifics on timing very soon. Google's (AMP) Accelerated Mobile Pages Project Starts Early 2016 [amphtml.wordpress.com]

Previous story Google Announces Accelerated Mobile Pages for Faster, Open Mobile Web [webmasterworld.com]

[netmeg]

Supposedly the ad networks (including AdSense) are jumping on board too. My dev is reading up on all this stuff at the moment, as most of our event traffic is mobile.

[Andy Langton]

From my initial (limited) reading about this, I have to say, I'm not a fan. if the idea is to restrict HTML, then surely that's a job for mobile browsers, and not a new spec. Seems like Google are forking HTML itself, which I am struggling to find a justification for, other than a desire for control.

[nomis5]

Well, here's what I'm going to do. Nothing for the moment, no way am I going to get sucked into this at this stage and spend valuable research time at the moment.

I'm going to let others do the research and see how it pans out.

What I see is a project that calls itself one thing, but in reality is totally G-centric with their profit margins being the sole reason behind it. Nothing wrong with that, however be grown up and, don't think for even a millisecond that there is any other reason behind it.

The techies on this forum will do what they are good at very soon, and explain in more detail what is behind this initiative.

[FranticFish]

From my initial reading I think the value could be for those who don't do web development or device testing. Instead of considering your use of resources with an eye to average 4G or 3G connection speeds and checking your site on devices and sims, you use a sort of framework where potentially risky decisions are eliminated.

Reasons I'm not interested (most of these would be deal breakers on their own). The Spec is here: [github.com...]
If I understand it correctly then...

1) No forms
<form> and all <input> <select> etc fields are prohibited.

2) No custom Javascript
Javascript is available only via a CDN but only from a pre-approved, pre-written set of functions.

3) No HTML comments
The demo page here [ampproject.org...] is actually invalid by their own standard because it has comments explaining how it works :)

4) No onClick events.

5) HTML and CSS restricted.

6) Viewport has to set width="device-width"
This, together with other code, is to support a hardware acceleration feature that as far as I can see only works in browsers based on Chromium.

Last, it seems to be 'mobile only', not 'mobile upwards' and that in itself seems like a huge step backwards.

Because of the (massive) restrictions, I can't see anyone wanting this functionality set for a laptop or desktop user on a good connection and mobile connections are getting better - at least in the UK they are.

Here in the UK, Ofcom in the UK reported in April that average connection speed in built up areas on 4G was 14.7 megabits per second. That's 1881K and I consider that HUGE.
[media.ofcom.org.uk...]

[edited by: FranticFish at 7:48 am (utc) on Nov 27, 2015]

[Andy Langton]

After checking the spec, samples and making a page, I'm really not a fan of this. So there's <amp-video> but also <amp-youtube>. What makes sense about that? How many proprietary tags will be allowed?

Their homepage doesn't meet Google's own guidelines for page speed:

[developers.google.com...]

And I find it a little off that Google is hiding their involvement in this. Google own, host and maintain ampproject.org, but they post announcements on Wordpress? There's no reference to Google on any of these sites. I'm hoping this doesn't gain enough traction.

[ergophobe]

I'm with nomis5 and for the same reasons....

Well, here's what I'm going to do. Nothing for the moment

Always a sound strategy. Until it isn't anyway. But I mean that you can burn a lot of energy chasing specs that never get adopted. Remember when everyone adopted XHTML and 0.0001% of pages were actually being served as XHTML? How much work was wasted implementing something a way that was never intended for no clear benefit because it was "the future"? I converted for a while until I realized it was stupid, but even years later I would read "best practice" articles about converting to XHTML.


That said....

if the idea is to restrict HTML, then surely that's a job for mobile browsers,

But if your goal is speed, you have to make those decisions server-side before sending all that data down the pipe.

In the WebmasterWorld announcement that engine linked to above, Robert Charlton said of the BBC demo AMP page ( [bbc.co.uk...] )

which is clearly a version of the article stripped down for responsive display on smart phones

Actually it is not. The AMP version is not responsive at all, which is why it looks that way on your desktop. In fact, it is a super lean version of the page that inlines all the CSS so that whole page makes on a couple of HTTP requests.

If I run it through GTMetrix, the AMP page has 5 requests and 225KB total payload. The original BBC page has 101 requests and a megabyte of payload.

Responsive design has a big problem - a responsive page is *heavier* than a standard desktop page. So to get responsive, you are actually send *more* not less down the pipeline. It all gets delivered and then the user agent decides what to show and how. This makes responsive pages super slow on mobile unless you carefully design them to be low-bandwidth, but that means you can't have the same rich experience on high-speed connections (and that is also a problem - responsive design is based entirely on screen size and doesn't take speed into account).

There have been many schemes to solve this responsive problem, usually going under the titles Adaptive or RESS. But they just aren't picked up widely because they're generally hard to implement.

Last, it seems to be 'mobile only', not 'mobile upwards' and that in itself seems like a huge step backwards.

Yes. But I would not say that it's a huge step backwards. In some ways, responsive was a huge step backwards. It solved one problem - maintaining two sites (and I actually still have to do this on one site and it is misery and we are finally converting it to responsive). But as I mention, it created another problem - delivering extra large payloads.

Now that the img srcset and the picture element are gaining adoption, responsive is a little better, but it doesn't solve the CSS and Javascript problem.

If you follow what's been happening with Drupal 8, you see that one of the big buzzwords is "decoupling." More and more people are looking at using Drupal to run the back end and maybe one version of the front end (usually not, but possibly the std desktop display), but other versions (native app, mobile website, AMP website) are "decoupled," that is, served by something other than Drupal. So, for example, Drupal might actually output JSON and it's up to your front end (still server side here) to decide what to do with it. You can build one responsive front end or a front end for every smartphone on the market. Your choice.

Dries Buytaert lays out the whys and hows of decoupling nicely
[buytaert.net...]

Anyway, to me AMP looks like it's essentially a decoupled architecture or, specifically, what Dries would call "progressive decoupling." Meaning your content management is unified, your content theming is mostly shared and the backend sends the same data to the front end layer, but the front end layer sends different things through the pipe depending on what the target is.

[FranticFish]

I think responsive is only a step backwards if people forget why they're doing it - so that everyone has the best experience possible.

You can build one responsive front end or a front end for every smartphone on the market. Your choice.

If I was going to go to that much trouble then I'd rather device-sniff than adopt a different coding standard. Work off one code base, serve different stylesheets and assets, less assets overall, omit certain parts of the page etc.

The BBC site is an interesting example but I don't think it's a representative example because it's a media site funded by an offline subscription - the TV licence. Hence no ad banners, ad tracking, remarketing etc. The main thing that slows my browsing experience down even on a 60 megabit connection is a site choked with ads and tracking: people serving huge animated ad files, lots of them, and the tracking script(s) that goes with that, and serving the ads at the same time as everything else. Popups in your face asking you to like or subscribe before you can even make that decision because you haven't seen what it is that you might want to like or subscribe to. I don't have an ad-blocker (I don't agree with them - you want the content then accept the ads) but I wish people would be less greedy.

The irony with this proposed standard to me seems to be that a lot of functionality is being thrown out the window so that the space saved can be used to serve ads.

In any case, to my mind the key issue isn't really the size of the screen - it's the speed of the connection. An initiative to enable a device to communicate that to a website so that it can tailor the user experience accordingly would be a real step forward IMO.

[ergophobe]

If I was going to go to that much trouble then I'd rather device-sniff than adopt a different coding standard. Work off one code base, serve different stylesheets and assets, less assets overall, omit certain parts of the page etc.

Right. That's the exact idea that decoupling allows you.

The BBC site is an interesting example but I don't think it's a representative example

Perhaps not, but it shows the potential for a super rapid loading mobile page.

[MrSavage]

I cannot comprehend this subject. It's greek to me. Can anyone expand on this in simple terms? Like what this really means? I thought it was essentially splitting off the web, or am I wrong on that. Making a controlled, limited environment that is a route to circumvent the ad blockers. Is this a glorified ad blocker workaround and is there a way that an average webmaster can participate and make money in this? #completelyconfused

[Andy Langton]

Google are proposing that there should be a limited set of HTML served to mobile browsers, which will then allow for better speed optimisations that can be 'built in' for those using the system. For instance, you can't use forms or custom javascript. You would need to serve this as a separate mobile site. It's basically a "quick fix" for making a fast mobile site, with most of the technical expertise offloaded to a central system.

There's no immediately obvious benefit in the sense that the tech-savvy can build fast mobile sites already. But most could probably build a faster mobile site more quickly using these proposals. There are concerns about the proprietary nature of the system, and that this "forks" HTML by making a new set of tags which do not have the openness of the web in general.

[ergophobe]

limited set of HTML served to mobile browsers

But that's only part of the story. The AMP spec does limit HTML, but the important part are the custom elements. For example, the spec for amp-img says

The runtime may choose to delay or prioritize resource loading based on the viewport position, system resources, connection bandwidth, or other factors. The amp-img components allows the runtime to effectively manage image resources this way.

[github.com...]

As Andy says, savvy developers can pull this off and you do see this - Medium for example shows blurry placeholder images until the image comes into the viewport. There are a lot of techniques for doing this. AMP is meant to offer a standard that will make this available for people who do not have a top-end front-end developer.

Currently optimizations based on such factors are a bit difficult (viewport) or quite hard or unreliable (bandwidth). Making this reliable will help a lot and having a standard will also help accelerate that work. Think back to the tag soup that existed when browsers didn't have solid standards to build to. It slows down development and makes life hard for site builders.

So yes, AMP disallows a lot of tags and in some cases (not forms) it replaces them with custom elements (like replacing <img> with <amp-img> ). This opens up some interesting possibilities.

A traditional RESS/Adaptive solution is a "full stack" custom solution, meaning it ends up custom and tightly integrated from front end JS/CSS through your server architecture. If RESS were easy, lots more people would have implemented it since Luke Wroblewski showed everyone how four years ago. [lukew.com...]

AMP offers a spec that lets you do this based on markup so that the optimizations can evolve over time. In other words, because the AMP elements are merely markup and depend on an AMP engine (parser, validator), it means that engine can improve over time without having to update your code. The rendering optimizations engine could, in fact, be integrated into browsers if it became popular enough.

So, how fast is AMP HTML? Pretty fast. In a sample of pages our early partners created we are seeing performance improvements measured through Speed Index between 15% and 85%. This was measured with a simulated 3G connection and a simulated Nexus 5 device. The best part is you don't need to be a performance expert to get this; best practices are baked right in. And as we optimize AMP HTML in the future, all pages benefit.

[ampproject.org...]

Also it's inaccurate to say this forks the HTML spec. The current spec allows for and expects custom elements. The W3C explains the rationale thus:

1. Provide a way for Web developers to build their own, fully-featured DOM elements. Though it was long possible to create DOM elements with any tag names in HTML, these elements weren't very functional. By giving Web developers the means to both inform the parser on how to properly construct an element and to react to lifecycle changes of an element, the specification eliminates the need for DOM-as-a-render-view scaffolding that has to exist today in most web frameworks or libraries.

2. Rationalize the platform. The specification ensures that all of its new features and abilities are in concert with how the relevant bits of the Web platform work today, so that these new features could be used to explain the functionality of existing Web platform features, such as HTML elements.

[w3c.github.io...]

Is AMP all about ads? Yes, it is. If it weren't, adoption by major properties would be out of the question. Google is utterly dependent on a web that is 1) usable and 2) ad-supported. No secret there. So are most publishers. But we are reaching a point where #1 is not true, so #2 will become not true as well. Therefore AMP is, yes, designed to be ad-friendly:

Ads and analytics – while critical for publishers – are a big part of the performance problem and so they must be a big part of the solution.... Embedding an ad or analytics often implies giving up control of what eventually happens to a site because they can typically inject any JavaScript they want into pages. AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.

AMP HTML is taking the following approach to analytics: so-called “tracking pixels” can be embedded into AMP documents as long as they don’t use JavaScript.

[ampproject.org...]

I personally don't care that much about the survival of an ad-supported web. I don't earn money by selling ads (though I do purchase a lot of them) and I pay for a lot of the content that I get online (and in fact, I consume no ad-supported television or radio offline; the only thing I consume offline that's ad-supported are print magazines).

So I generally don't have a strong vested personal interest in the survival of ad-supported content, online or off, but if it is going to survive, it will be things like AMP that roll back that madness in the current advertising world. Either way, I think a day of reckoning for ad-supported online content is coming, much as it already has in the print world.