Earlier this year, Google announced a plan to speed up mobile news — and the entire mobile Web — with a new initiative called Accelerated Mobile Pages. AMP, as it’s called, has been described as an open-source bid to overhaul mobile performance and compared to Instant Articles, a similar effort launched earlier this year by Facebook.
When Google unveiled AMP in October, the measure was greeted by a mix of enthusiasm and wariness from future-of-news types, who alternatively hailed it as a huge boon to online journalism or an attempt by Google to position itself as the arbiter of Web standards for a community of publishers.
It’s already drawn high-profile adherents — including technologists from The New York Times, Vox Media and Hearst — who say the increased performance justifies tweaking their digital news reports to conform with the new standard.
Those who find some fault with the measure confess uneasiness at having Google set the agenda for digital publishers around the world. In an article written shortly after AMP debuted, Nieman Lab’s Joshua Benton added this caveat to an even-handed explainer of the effort:
In a world of controlled platforms and walled app gardens, the Web is the last open space standing, built over two decades, and there’s something irksome about a few Google engineers deciding which parts to ban.
Javascript, which enables much of the Web’s interactivity, is excluded from AMP HTML documents — although there are workarounds for this omission (more on that below). Some HTML tags, including “iframe,” “embed” and “object,” are also gone, per Benton.
Despite the skeptics, Google says it’s building a consensus among journalists and others that widespread adoption of AMP is the right thing for the news industry. In November, the Web giant announced that thousands of publishers and several influential advertising technology firms were on board with the burgeoning standard. With the launch of AMP set for early next year, Poynter asked Richard Gingras, the head of news and social products at Google, what journalists can expect in the coming months. What follows is an edited and condensed version of our conversation.
What can you tell me about the progress you’ve made with AMP since it was unveiled in October?
Since that announcement, more than 1,000 publications and well over 4,000 developers have engaged with the effort. We have been further developing the platform and its various capabilities to make sure that the format does what publishers feel it should do.
Last week, you might’ve noticed that we came out and provided a more detailed update to all those interested in the AMP project, and we noted that we’re looking to make AMP live to the public on Google Search as early as late February of next year. The train, as it were, has left the station. At this point, our effort is largely around finishing up the various code work that has to be done. But just as importantly, to make sure that the ecosystem of publishers is keenly aware of what’s happening and ready to jump on board that train.
Why is Google waiting until February to launch AMP, and what will that switch mean for news publishers?
In Google Search, we’re going to take that demo experience and make it live. So we’ll actually show and feature articles from publishers using AMP in search results — and the user experience will likely be very close to the user experience that we demonstrated at the announcement.
There will be a carousel that will trigger on the page of results when there is sufficient coverage related to that query, so users can have the full benefit of getting the answers that they’re looking for and experiencing them in an instantaneous fashion. Given their speed, we expect it will drive additional engagement on the part of those users, which is a key benefit to publishers.
To the second part of your question, why wait until February? As we stated clearly when we announced the project in October, what we were demonstrating was: “Here’s what AMP can be like. Here’s what it can do.” But there’s a lot of additional work to be done. I’ll give you a very specific example. As you know, what is so important about AMP is not only do we address the news ecosystem’s problem of speed and trying to drive a better ads experience. More importantly, we do it in a way that follows basic Web principles which include that the publisher is in control.
AMP is quite different from the solutions that we’ve seen with Snapchat or Apple News or Facebook in that the publisher is in control. These are the publishers’ webpages, they’re simply done in a format which allows them to be lightning fast. But the publisher’s in control. They’re in control of their product, they’re in control of serving the product. They’re in control of the business model of the product. Effectively, they’re in control of their own destinies.
So if you say that the publisher’s in control and these are publisher’s Web pages, that means that we need to make sure that all the analytics that a publisher might want are there and available for them — whether that’s via comScore or Google Analytics or Adobe Analytics or Chartbeat. We needed to make sure that capability was there.
Because in this ecosystem today, most major websites are running maybe half a dozen analytics providers on their pages. They’ve got comScore. They’ve got Google Analytics. They’ve got Chartbeat, and maybe two or three more. The problem today is that each one of those vendors is running an additional set of code, all, in many cases, looking to measure the same thing. Where’s the scroll point on the page? How far did the user go?
So what we’ve needed time to do was to come up with an architecture that both made it efficient yet provided the publishers with the same array of statistics and analytics that they had before. So now, embedded in AMP will be the native ability to get all those core metrics and send all of those analytics to an end point of the publisher’s choosing so they can distribute those data points to their third-party providers.
That’s the kind of stuff that we’re working on, and we needed to get it done between announcing and showing what AMP could be like and actually getting it to the point where we had robust functionality and capabilities that a publisher would expect to see.
How will adoption of AMP will affect Web traffic for publishers who adopt it? Will publishers who do not adopt it be disadvantaged? Will AMP pages be given higher priority in Google Search results?
Let’s take that in pieces. As for the last point, this question does come up regularly. What we say quite emphatically is that we will continue to operate Google Search ranking as we always have — in a very principled fashion. Our objective is to satisfy our users by making sure the best possible results are there. We will continue to do that.
As you know, there are many signals that we use to achieve that end result — some 200 signals. One of those signals, as has been clear for over a year now, is performance, or the speed of the page. Because if the page isn’t readily available, it’s not a particularly satisfying experience for the end user.
So, without question, AMP will certainly help in ranking from a performance perspective, because those pages are lightning fast. But that does not mean that the ranking will be completely biased toward the AMP format. It will not. If the best quality results are not in the AMP format, we will continue to surface them, as they should be, at the top of the page. We’ll keep the core principles.
But this is about creating an instantaneous experience. Look at how we operate. We are all incredibly impatient people who are looking to be instantly gratified at all times. And those of us who have been working in this field for a long time know that to the extent that the experience is extremely fast and responsive, people will spend more time with it. To the extent that I’m browsing and the links are lightning fast or instantaneous, I’ll consume more content. While none of us can expand the amount of time in the day, we can certainly make that time better. And I think that’s what AMP does. It uses the time better.
So overall, do we expect engagement to increase? Absolutely. I don’t think there’s any question that engagement will increase. Does that mean that someone adopting AMP is all of a sudden going to see a massive increase in search traffic? I wouldn’t say that either. Obviously, we expect all the numbers to go up. But obviously all within reason.
When journalists or developers object to AMP, they usually cite concerns about code subsetting, which emphasizes certain elements of a webpage at the expense of others. The gist of their qualms seems to be that Google is enforcing a standard on much of the Internet, deciding which scripts are important and which aren’t. What’s your response to that?
Our response to that is pretty straightforward. The objective of AMP is not to reduce the level of functionality that one can have in a webpage. It’s not to reduce or constrain the level of creativity that a publisher or author can bring to their content. The objective of AMP is not one which simply addresses text-based articles and doesn’t care about more complex approaches to engagement.
This is Google, together with many others, reaching the conclusion that there’s a better way for us to architect how webpages work in the interest of performance and simplicity without giving up functionality and creativity.
For us, the biggest opportunity with the architecture is to make things fast, identify redundant code and make that a common resource. And so yes, we said there is no Javascript in the AMP file. It’s not that there isn’t Javascript being used to create a fully-functioning webpage — it’s simply that it’s done in a different fashion. So in come cases, we take that Javascript functionality, for example, a slideshow, and what we’ll do is add the raw slideshow capability to AMP itself.
Some might say, well, but there’s still areas where I need to be able to do more — and that’s a very fair point. So what we’ve also added to the spec are what we’re referring to as “escape hatches.” With a click, a user can engage in a far more complicated interactive experience that the publisher crafts in Javascript, as they might today.
One of those escape hatches is something called “click to play.” Let’s imagine that you’re doing an article and you want to show an interactive data visualization on election turnout, for instance. With “click to play” in the AMP article, you might have a graphical element there — maybe it’s an animated GIF or something that’s showing what the data looks like — and it says, “click to learn more.” I click in and that goes into a full Javascript-driven experience hand crafted by that publisher or author.
It sounds like the idea behind these escape hatches is to allow news organizations to optimize their sites while simultaneously allowing for additional functionality.
Exactly. It’ll always be important to have these escape hatches. But we’ll also continue to expand the capabilities of AMP natively. We’ve already had code contributions from third parties and will continue to operate in that fashion. We’re enriching AMP with functional primitives that allow authors to build more functional content without having to go deep into the Javascript.
Was the decision to preview AMP this fall prompted by the release of Facebook’s Instant Articles earlier this year? Do you see Facebook as a competitor in this space, or do you see the products as co-existing long-term?
AMP came out of a rather thorough assessment of the state of the ecosystem that we did in conjunction with many other publishers and tech companies. There were a lot of issues with the ecosystem that we felt were important to address. Certainly, one of them was, given the performance of the Web currently, you saw proprietary platforms — like Apple News and Snapchat — saying “we can make that easier for you, just let us host your content.”
Clearly that was a factor. As I said, we think the most important ecosystem for publishers is the open Web. And to the extent that the open Web gets diminished because of the increase in size of proprietary platforms, that would be an unfortunate thing.
I don’t see it as competitive to Facebook or Apple in the sense that it’s a completely different animal. It’s not proprietary, it’s open-source. I think maybe some folks expected that Google would come in with its own proprietary approach to fast content.
But that’s not the way we looked at it. The real thing to do here is fix content consumption on the Web. Let’s make it as fast and compelling as we know it can be.
Broadly speaking, how do you expect the rollout of AMP to affect news publishers and the Web writ large? How and when do you envision those changes taking place?
The objectives are: Can we enable a faster, more compelling experience on the Web in general? Can we, with AMP, begin to influence ad behaviors such that we see fewer people reaching for ad blockers and quick views? I’d like to think so. Can we, in making the Web healthier and more vibrant, make publishers less vulnerable to proprietary platforms? Which I think we all agree are not, in the long-term, good for publishers? Then indeed we will do so.
Every publisher today is looking to evolve their products, create new products and find audiences for them. And the Web is clearly the best possible means for them to benefit from various discovery funnels to let people find their new product. Whether that be via Google Search, or whether that be via social networks or simply the fabric of links that is the Web itself.
In the end, I think the long-term health and sustainability of the publisher ecosystem is incredibly dependent on their being an open Web ecosystem that they can take and effectively leverage.
Do you worry, with the emphasis on stripped-down pages, that you’re taking some functionality and flexibility away from advertising among news outlets?
It’s useful to note here that we have a considerable business in ads. Obviously, what’s important to us is to have a healthy ecosystem for ads — not a diminished one.
I look at ad blockers as a system in an ecosystem that’s not what it should be. And certainly, AMP, in various ways, looks to address that. One of the problems of the current ecosystem has been the lack of transparency of the performance of these underlying ad systems themselves. Among publishers, it’s just too hard to find out why pages are all of a sudden two seconds slower. Is that because I have an additional third-party ad network that has a serving structure that’s not optimum? Is that because I’m running an ad request through four exchange hops to find an ad? What’s going on here?
We look to address that with a reorientation of priorities. Load content first. Load ads second. Put an appropriate spotlight on performance such that the ad tech community can begin to look at those challenges or opportunities, depending on how you want to look at it.
We also insist that the ad operate in a predetermined size, that it communicate its size such that we don’t have the jankiness we have today with ads loading in, shifting the page around while you’re trying to read the article. And we also don’t allow ads to reach outside the page, which means that popups can’t happen.
So obviously, we’re taking steps to help put the ecosystem in a better place. That’s going to take the collective efforts of the ad industry overall to begin to consider what the next generation of better ad practices should be.
Is there anything else you’d like to add?
Is AMP easy to adopt? I would say that it is. We’ve been working hard with various CMS providers. WordPress, for instance, already has a plugin supporting AMP. So websites that are working on WordPress today should be able to easily adopt AMP. Publishers who have their own CMS’, we’re finding that they can adopt AMP with a little amount of work — sometimes in a matter of days. So it’s not a huge effort to begin to move down the road toward adopting AMP.
