Nieman Foundation at Harvard
Google’s AMP initiative — Accelerated Mobile Pages — officially launches today with the goal of getting the mobile web to that wonderful place where all “publishers can create mobile optimized content once and have it load instantly everywhere.” Unlike its platform-specific counterpart Facebook Instant Articles, Google’s AMP initiative applies to the open web and will rely on participating publishers and technologists to contribute (non-proprietary) code of their own to get AMP pages to a place where they reflect the fullness of the “regular” web. (Read more about some of the technical details around AMP HTML from the time of its announcement last fall here; Search Engine Land has a good quick summary today here.)
What kind of speed improvements does AMP deliver? Here’s one example: This desktop version of a New York Times story gets to domContentLoaded — a key point in a webpage’s load where the HTML is fully downloaded and certain important parsing has been completed — to 0.985 seconds and loads fully in 3.82 seconds. (That’s in a test in Chrome on a fast iMac.)
The mobile version of that page gets to domContentLoaded in 0.857 seconds and is fully loaded at 2.99 seconds.
The AMP version of that same webpage — note the .amp.html in the url — reaches domContentLoaded in 0.240 seconds and loads fully in 0.646 seconds.
So how are newsrooms adjusting to what is, on one hand, a chance to speed up their mobile presence but, on the other, a mandate to develop and maintain another version of all their stories? I reached out to a number of them and found a variety of responses — some all in, some testing the waters, and some unwilling (or unable) to commit the necessary developer resources.
A number of newsrooms I reached out to declined to speak for attribution, but cited “limited resources” and “different priorities” as reasons for not pursuing AMP for now.
The thing that burns me most about the reporting on things like FB Instant Articles, Google Amp, etc. …
— Adam Schweigert (@aschweig) February 23, 2016
Anyway. [pour one out for the lone tech folks at small news orgs fielding questions from clueless managers about Google AMP today]
— Adam Schweigert (@aschweig) February 23, 2016
“The most challenging task in our case has been the implementation of the paywall issues, because our system is totally based in JavaScript, which is not supported by AMP,” Folha de S.Paulo assistant managing editor Roberto Dias told me. The Brazilian paper is testing and experimenting with AMP on a limited scale. “Besides that, and looking strictly from a newsroom point of view, of course I would love if it allowed more interactive features and more links to related content. But I understand what the project is trying to do, and also understand it as a work in progress.”
“We have 29 newsrooms and we’re running an enterprise CMS — chasing a project like this requires a fair bit of due diligence,” McClatchy’s head of mobile initiatives Damon Kiesow told me. “We’re doing a sort of audit of our current pages, trying to understand what is natively supported in the AMP framework, what translates into the new system as of now — with the expectation that not everything is — what do we expect might be supported in say, six months. And when I talk about that, I mean mostly revenue elements on the page — video ads, and maybe things that are outside of AMP’s interest or scope, like trackers on the page.”
McClatchy plans to launch a pilot sometime next month at one of its California papers, and is getting assistance from an outside vendor that will handle coding page templates and providing daily support as McClatchy passes along its business requirements. Testing the initiative at one paper — rather than in all 29 markets — simplifies the implementation process, Kiesow said, while still returning some specific feedback on how the project impacts workflow, how it affects revenue, and how it affects users’ experiences, if at all. But even with the outside technical lift, AMP-ifying is far from a turnkey solution.
“Everything we know about building a webpage we have to relearn. But we’re relearning it from the premise of converting a current product over, not creating a product from scratch. It’s a fairly complex process!” he added. “But we’re no different than anyone else in the industry. We’ve been having discussions around page weight and page optimization, in depth, for about six months. This is just another opportunity for us to look at what Google’s proposing, in terms of the concept and approaches and strategies that they’ve taken to try to solve the problem.”
Depending on how the pilot goes, next steps could be to adopt some of the “best practices” proposed under the AMP framework, or to adopt AMP as a templating option for McClatchy sites.
@stuntbox This needs to be a conference session. We are chasing tech instead of readers.
— Damon Kiesow (@dkiesow) February 23, 2016
Many of those outlets, like Mic, are “all in” when it comes to making their stories online available as AMP pages. (From here on out, whenever users search for a Mic story on Google, “an AMP file will be displayed for 100 percent of our content,” Haik said.) Stories that have gotten the AMP treatment are have been showing up in a carousel in Google’s search results on mobile since Tuesday. (A search for “Trump” this morning brought up a carousel of AMP’d pages from USA Today, Fortune, BBC, ABC, The New York Times, U.S. News, The Big Lead, and MSNBC.)
“For us — and I think many publishers would agree — search is a pretty meaningful channel for us in terms of the new audiences, and mobile has only unlocked more of that,” Haik said. “More and more people as you know are on mobile, and none of these people are opening up Safari on their iPhones and typing in http-colon-slash-slash-mic-dot-com. That’s not how you get to content via mobile: You get through search and social.”
Mic has two people really focusing on AMP for now, and its developers have contributed code to the AMP HTML library as well. It’s also hosted a meetup in New York with the AMP Project’s lead engineer and other developers and product people in the area across publishing. And for Mic, “we’re able to monetize the way we need to; it’s still HTML we can manipulate — it’s not so restrictive.”
The Atlantic, too, intends to have AMP pages for 100 percent of its content, starting first with its standard article pages.
“It’s been impressive to see this project evolve. We’ve really benefited from the active participation of the whole ecosystem — from analytics providers to third-party ad technology,” The Atlantic’s general manager of digital Kimberly Lau said. “Right now, we’re making sure we can fully replicate our advertising capabilities in this format. This week, we’re focused on integrating native ad capabilities into our AMP pages.”
The Guardian, which has been intimately involved in the AMP initiative from the beginning, has AMP ready for its core article format, “which accounts for about 18 million individual articles” and “may later start publishing AMP versions of our remaining content types, including liveblogs and galleries,” according to its head of product Anthony Sullivan. The Guardian’s not currently using an AMP version of its homepages, “but we haven’t ruled this out for the future — it depends where AMP goes, and where we decide to take it.”
Sullivan acknowledged some challenges translating the publisher’s existing revenue elements and analytics requirements into AMP, but was bullish about the future of the project, saying that “broadly the direction of travel seems to be towards AMP receiving the wider support it needs to succeed.”
“Google is very much the gatekeeper for AMP code, but their developers have been remarkably open and responsive to external input and the AMP product teams at Google have been attentive to understanding the requirements of the publishing industry,” he added.
