Photo: Nasa
By the end of February, Google will deploy at full scale its Accelerated Mobile Pages project by sending search results to amp-html pages. Because it integrates all monetization instruments —advertising, analytics and now subscription systems— Google’s AMP is likely to rally scores of publishers. [This post had been updated.]
Over 5000 developers registered to the Github repository of Google’s Accelerated Mobile Pages (AMP) program. Some are just sniffing around, others actually work for large or small organizations and are truly committed to build something.
In a few weeks, Google will open the floodgates connecting AMP to its search engine. Twitter and Pinterest will follow. A request from a mobile phone will call a AMP-coded page (when available) that will load at blazing speed. That’s the plan. For a glimpse of what it will look like, try the demo version from your mobile, or add “/amp” at the end of any Guardian page’s URL. Tested from a poor mobile connection, the result is compelling.
[Update: Thanks to the Wordpress plugin, the Monday Note comes with a amp-html version; just add “/amp” at the end of the URL.]
How does Google pull this off? AMP redesigns core components of the Internet’s historic Hypertext Markup Language, now re-christened “amp-html”, and supports it with a massive distributed caching system in which Google hosts pages for a few seconds or hours, in multiple caches spread around the world to be closest to the user. All publishers have to do is provide two versions of their pages, one for direct access from a well-connected desktop, and an AMP version for mobile. It goes like this:
When a page is called from a mobile through search, Twitter or other, the user is directed to the super-fast page. Et Voilà. (More about the whole concept in this previous Monday Note and on AMP official blog, written in plain English.)
As of today, Google is reluctant to speculate about the number of publishers that will be on board when the AMP program launches late February. Expect several hundreds in Europe and in the United States. All the big players are working on AMP, from the New York Times to Vox Media; it will spread quickly as specifications cover more web components. As the number of publishers rises, the system will become more visible in Google search pages thanks to a larger corpus of news elements coded in AMP. Among the distributors of news, Twitter, Pinterest are on board. Even Nuzzel, the 6 persons startup who built an amazing social recommendation app will support AMP (more on Nuzzel next week.)
A positive effect of page ranking
The snowball effect will also apply for another simple reason: AMP-HTML coded items will show better in Google SERPs (Search Engine Results Pages.) If Google product managers adamantly insist on the absolute neutrality of Search, it is a known fact that rendering speed is a key contributor to better rankings. In itself, this factor should act as a powerful stimulus to create AMP pages.
Other incentives center on the monetization side of the program. On the advertising side, most ad servers (not just Google-owned DFP) will be able to send ads in AMP pages. Some work remains to be done on the formats that will be deemed acceptable in AMP pages.
Privately, Google people make no mystery of their intention to clean the advertising mess. They want to get rid of the invasive formats that, by ruining the user experience, contributed to the explosion of ad blockers and threatened a large segment of the digital economy. To that end, the AMP ecosystem is their weapon of choice
Between Google’s AMP engineering team and the advertising community, interests collide. The former are focused on accelerating the rendering of mobile pages and restoring a decent user experience on mobile; the latter prioritizes value extraction of above all other considerations.
Even if the company won’t publicly admit it, Google plans to lean on AMP to curb advertising excesses on media sites. Hence the initial idea to constrain the formats allowed in the AMP ecosystem. According to Google indisputable argument, pages that render four times faster on a smartphone will cause users to increase their page-views per session and to see more ads as a result.
For their part, ad buyers face pressure from creative people who want to splashiest possible formats to fit the (presumed) aspirations of their brands clients. From the mobile user’s perspective, fluffy ads translate into pages that take forever to load, and into a strong incentive to jump elsewhere: about half of users will leave a mobile site that takes more than 6 to 10 seconds to load.
Nevertheless, the advertising community now seems on board with the AMP project. Richard Gingras, head of News at Google and project lead, wrote this in a recent blog post:
[Media] Buyers have also been engaged: Annalect (Omnicom Media Group) is currently reviewing the project (…) Advertising companies that have expressed their intention to support AMP include: Outbrain, AOL, Taboola, OpenX, DoubleClick, AdSense, Pubmatic, Integral Ad Science, Moat, Smart AdServer, Krux, Polar, Nativo and Teads.tv.
I’m not so sure that having on board internet nuisances such as Outbrain or Taboola is such good news. With remarkable consistency, these two disfigure thousands of sites across the world by inserting grotesque promotional or editorial recommendations in news pages. As for Teads.tv, it created many unseen-before video formats that should be rewarded by ad blocker companies for their ability to trigger user rejection. Example here with this InRead video format, with autostart at full volume promoted by Teads [See Pierre Chappaz response in the comments]. It will be interesting to watch how Google contains these companies’ propensity to impact user experience in such negative fashion.
For good measure, let’s also mention that AMP places a bet on native ads integration; Google will propose its own product as well as third party solutions such as the Polar platform.
From Google’s standpoint, the priority given to speed justifies a certain inflexibility in its drive to use AMP as the prime argument to get rid of bad ads. Even if some rapprochement is under way, the ad community seems a bit too slow to respond while publishers don’t feel like they are in a position to pressure them…
To me, the surest way to make progress is a decisive move from the creative advertising side. Instead of fighting for the status quo, agencies should devote more resources to come up with truly creative formats that fit AMP specs. And publishers should take the user’s side.
Embarking Analytics
In building AMP, Google had to deal with the multiple flavors of analytics asked (and sometimes actually used) by publishers. News media have a strange relationship to analytics. They want to use most of them as if they would warrant performance. But, unlike e-commerce sites, media are not culturally accustomed to make intensive use of data. Instead of embedding just a couple of analytics code segments in their pages, some sites end up using dozens of those. Such non-choice proves efficient at slowing down the rendering of these pages. Smartly, the AMP team decided early on to team up with Chartbeat, probably the preferred analytics tool in the news community. Today, multiple web metrics providers are on board, including Moat (who partner with Chartbeat), Nielsen, ComScore, Parse.ly, ClickTale, Adobe Analytics, etc. It is unclear, though, how AMP will be able to discourage publishers to install too many of those.
A major break, through the paywalls
One of the most complicated issue the AMP engineering team had to deal with was the implementation of paywalls. These are insistently asked by publishers ranging from The Wall Street Journal, The New York Times and European publishers such as the FT or Les Echos. Due to the widely distributed architecture of AMP in which a single page could be replicated hundreds of times all over multiple caches, reproducing a metered system, the partial display of a story, or a login flow was quite a task.
The good news is: It’s done.
This week, AMP’s engineers will release the version 0.1 of the code that allows publishers to implement paywalls in the AMP ecosystem. This is a critical feature for the economy of quality news media — an advantage that Facebook’s Instant Articles, or Apple’s News are nowhere near to offering.
How does AMP paywall support work? Let’s start with a simplistic sketch summing up today’s situation:
The main drawback is obvious: each time users flush their cookies, they start over for free. That’s why the most stringent paywalls require a registration. This carries two advantages: cheating is more difficult, and the user can be followed from one device to another. Then, why did so few publishers elect to not require a registration? Again: the non-choice syndrome. They want to win on both ends, subscription and advertising.
Now, let’s move to the AMP-implemented paywall. It carries two complications: the caching system and the dual nature of the documents with the AMP pages coming from search, social etc, and non-AMP pages, that are not cached —in the latter case, the system works as described above.
Then let’s focus on the AMP-pages paywalls. Publishers involved in discussions came up with demands (not only is the publisher poor, rarely tech savvy, but also demanding and sometimes arrogant —just kidding.)
The requirements were:
— A metered system with a number of free articles
— [or] Limited viewing of a document (as the WSJ does when the main part of the article is masked to non subscribers)
— Ability to customize the user experience for subscribers, such as removing ads.
Naturally, publishers wanted to have full control of the parameters for the metering system, the login/authentication process, the tracking the users and the possibility of changing all sorts of settings on a per document level… “Vaste programme” would have quipped General De Gaulle.
It goes like this (the chart below is based on numerous discussions I had with the engineering team. It is a bit simplistic.)
Again, for the sake of clarity I passed over several features, including many events on the reader side that occur right within the browser’s AMP Runtime. As you might have noticed, AMP introduces several new components such as the AMP Reader ID, a unique reader identifier as seen by AMP and issued by it. At some point, the AMP Reader ID will be reconciled with the regular cookie issued by the publisher, to highlight a returning reader, or a known subscriber for instance. Also not shown are three elements provided by the Publisher: the Access Content Markup which defines which part of the document are visible under which circumstances; the Authorization endpoint that sends back a response stating which part of the document the reader can view; and the Pingback endpoint used to send the “view” impression of the document. Go to Github today or later in the week for complete specs.
Summing up, when it comes to implementing paid subscriptions support, the AMP team has gone way further than expected. What is still a preliminary version of specs already allows numerous paywall fine-tuning possibilities. And there is more to come.
The users didn’t “register” to the AMP repo on GitHub, they just starred it :). It’s like a thumbs up on Facebook.
Good point, lol. Makes it sound like something else.
Our audio app provides short and crisp news, which no one does and has a revenue model, which is attracting newspapers, radio stations and news websites. We have thousands of listens on a day to day basis and new source requests keep coming.
Dear Frederic,
Are you sure that you are shooting on the right enemy? here is our Native Video format, please watch it on your smartphone (scroll down to see the ad):
http://sample.teads.net/demo/demo.html?pid=1&vast=http://sample.teads.net/vast/vast-mpg.xml&startMode=v2p&slot=p&soundMode=click
I wonder why you would dislike it, it is soundless by default, not interruptive, in one word it is far more user-friendly that pre-roll ads who are blocking the user navigation. This is the very reason why it has been adopted so quickly by the the most prestigious media and brands all over the world.
You may have seen one of the numerous copy cats, some of them having a different behavior?
Just checked your site and and on this URL
( http://misc.teads.tv/us/demo/InReadWeltDemo2/index.html#23294367)
is the perfect demo of a super-invasive video —autostart at full volume— that triggers a massive rejection of the users. While I understand the economic short term benefit for the user, on the long run, this kind of format is responsible for the rise of adblockers.
Frédéric,
I am sorry but any honest person who will click on the link that you are showing from a smartphone (AMP is for mobile, isn’t it?) will see that I am right and you are wrong: Our videos are entirely silent, unless the user chooses to activate the sound. Try again, you will see.
Apart from that, I would really like to know what your opinion is about pre-roll video ads, you know those video ads placed before video content, that the users are forced to watch even when they are not interested. All surveys are showing that they are (together with interstitials) the main cause for the raise of adblockers. Shouldn’t you suggest to Google to get rid of them?
“sould” should be “should”.
“I’m not so sure that having on board internet nuisances such as Outbrain or Taboola is such good news.”
Look at a story using the Guardian AMP test, and you don’t get Outbrain stuff at the bottom of the page. Seems reasonable to me, if speed is the goal. No doubt Outbrain is in circle-squaring discussions with Google on this issue.
(Also, all the Guardian’s lovingly-chosen custom fonts are gone: only standard web fonts are used. That’s reasonable too.)
I’m curious why caching is a significant part of the effort to reduce page-load times.
The time to traverse the Atlantic or other similar heroic measures to get a news page, is insignificant compared to the turnaround time of a *SINGLE* ping from the cellphone to the nearest tower.
And while it does essentially nothing to speed the page delivery time, it interjects Google more tightly into the production/delivery process, making it harder to unwind the experiment if, for instance Google declares it a noble experiment, as they are so wont to do to new efforts.
Meanwhile, the page-slimming logic appears primarily to be best-practices stuff that any publisher who actually cared about the user experience could direct his own content managers to perform, with little or no fuss. Except from the suits who garbage up the page with their various trackers, etc. The stuff that actually contributes most of the deadweight, and that Google will apparently be accommodating.
If AMP-html is the cudgel that engineers at publishers need to slim down the site (by telling the business managers that their bloated “tools” just can’t be included in the new format), I guess it’s a net plus. Otherwise, it looks like a huge distraction from the real problem of how publishers can deliver a good user experience to mobile users outside of the various news platforms.
Does this relate to Apple killing iAd and allowing publishers to keep 100% of ad revenues?
This is not what this article suggests …
http://uk.businessinsider.com/apple-walked-away-from-iad-to-starve-googles-core-business-into-irrelevance-2016-1?r=US&IR=T
“If Google product managers adamantly insist on the absolute neutrality of Search”
If they’re saying “Use AMP or be penalized in search results” there is no neutrality left. Not that there has been for a while. Google gave up on neutrality a long time ago.
I believe the article said that page render time factors into page rank. Devil’s advocate argument: If you can use non-AMP techniques to create a page that renders at the speed of sound then you need not use AMP.
They precisely say they won’t favor AMP-HTML Pages, however, since, download time is a known criteria to get a better ranking, the use on AMP will de facto improve the page rank —that’s my personal assumption.
A quite interesting article, but it I could not help thinking that this somewhat resembles Akamai and other Content Distribution Networks (CDNs), and to go even further back, Squid (a caching web proxy server).
To some extend it does, except that AMP is putting away, in “container” most of the code that slows down the page rendering. See, the official AMP Blog for more details…
How long until this is banned by the EU as “monopoly” technology?
Since it’s an open project —anyone can access to the code to build AMP pages— I don’t see any reason for the EU to move on to this.
I tried this on a Guardian article just now. Normally, it’s a 10 MB page with 12 iframes, many of which don’t load due to permissions errors. With /amp, it’s a 2 MB page with over 100 XHR calls that fail due to permissions errors. Unlike Google, they don’t use HTTP/2 yet, so the 100+ connections it does succeed in making aren’t exactly free.
From where I stand, the two big questions that AMP will have to answer are:
1. How is this any different from using known best practices for webpage design? Why do I need Yet Another Javascript Library to make a page load quickly? If I had a slow 10 MB webpage, wouldn’t it be a lot easier just to remove the iframes and video ads myself?
2. If the “AMP” project does succeed, why wouldn’t all users just flip a switch (or install an extension) to always browse the rel=”amphtml” page? Does anyone think that desktop users actually like slow-loading webpages that are full of annoying ads?
I can’t decide if this is a useless project, or brilliant marketing on the part of Google. Maybe both. It shouldn’t be necessary in the first place, but it’s probably easier to get publishers on board if you call something “Accelerated Mobile Pages” than “Everybody Please Uncrapify Your Webpages”.
“Everybody Please Uncrapify Your Webpages”
Gina: nail and head, in the most amusing way!
There’s an existing wordpress plugin that creates AMP formats automatically by adding /amp onto the end of any posts URL. I’m worried about duplicating my content at multiple URLs and wondering if adding some parameter like ?v=amp would be better? Also, if a parameter is used to render the page via AMP, how do we let Google know about these pages? Can we submit a separate AMP sitemap?