Mehta: So tell me a little about AMP (Accelerated Mobile Pages), and why Google is investing so much time and money into it.
Gingras: Let me start with background. We began engaging with publishers early last year, to basically assess the state of the ecosystem, understand the challenges and see what we in collaborating with publishers could do to address these opportunities and challenges. AMP is the most active open-source project we’ve ever been involved with; there’s a massive collaboration of publishers around the world. Every day, we are seeing over half a million articles produced in AMP over 20,000 domains from 30 countries around the world.
When it comes to the World Wide Web, here’s where publishers and Google have a very common objective, which is that we both depend on a healthy Web for business. For Google, without a rich ecosystem of the Web, then Google search, for instance, has less relevance and value. Similarly, publishers as well require an open ecosystem like the Web to have an opportunity to build the audiences they want to build. So the truth is that AMP is existentially as important to Google as it is to publishers. That is why we are doing this.
Mehta: How does AMP help the cause of the open Web?
Gingras: When it came with the Web, there were two key issues. One is that the performance of the Web is not what we would like it to be. It’s simply too slow, and has become increasingly slow over the last several years. And, secondly, is the situation with ads–too many ads that are far more annoying than they are compelling, obviously then causing users to reach for ad blockers.
These two issues have significant secondary effects on the ad side. Obviously, if ads aren’t working, then monetization won’t work for publishers. With regard to speed, the secondary effect was really creating a greater opportunity for proprietary platforms such as Facebook and Snapchat to have even more leverage over publishers in terms of how they take and seek audiences. Clearly, Instant Articles was an understandable effort on their part to address the speed issue, but by having publishers put their content inside Facebook’s environment.
Mehta: But how is AMP any different (from Facebook and Snapchat)? I recently read a Wired article (“Google’s AMP is speeding the Web by changing how it works”) that said when you are accessing AMP articles through Google search, it’s Google’s cached content that is coming up, and when you share these articles the person who clicks on the shared article from AMP comes up to a Google website. So you’re talking about how Facebook and Snapchat are within their own ecosystem, but doesn’t Google have the same plans with AMP?
Gingras: No, not at all. This is hugely different, and I cannot emphasize this enough. Because AMP, just like any other HTML page, they control the content, they control the business model, whether that be via advertising or via subscriptions. There is zero requirement that they use Google ad systems in any way. No revenue sharing; all the revenue is theirs. So a key objective of AMP is indeed to make sure that publishers could control content, control business models, and their own destinies.
Now, caching is something that has long been done by various platforms, including Google. But the cache is a complete copy of the webpage of that publisher. The business model, the ads, do not get affected by any of the caching. All the caching does is make the page fast. And if the publisher updates the page with new information, that would get reflected in the cache almost instantly as well. So the caching is is done for additional performance purposes and has no impact on publisher controls. No impact on the publisher’s business model.
Mehta: I’m reading out the wired article, quoting directly from it.
That’s a big change in how the Google search engine works. Historically, Google has acted as an index that points people away from Google to other websites. With its AMP search results, Google is amassing content on its own servers and keeping readers on Google.
In that sense, Google’s use of AMP is similar to Facebook’s Instant Articles service, to which it’s often compared.
So want to know about the technical point they are making, is it a change from when Google was more as an index or gatekeeper to the Web, and is that feeding into the insecurity publishers have when it comes to losing control over their platforms?
Gingras: I wanna say that again: This is entirely inaccurate. The representation within Wired, absolutely inaccurate. The article is completely controlled by the publishers. It’s their thing, they can do what they will.
Let me give you a specific example of how these things are different. The monetization is all theirs, the ad revenue is all theirs, there is no requirements that they use any Google ad platforms.
Every publisher, when they get a click from Google or Facebook, they want the user to spend more time on their website. They do that, obviously, by enticing readers with additional links to additional articles. It’s their webpage to do that, and we encourage them to do that. That’s something can’t be done with Facebook–Instant Articles is their format, dictated by them, with their rules.
AMP is open-source format, much like HTML, no rules about templates, no rules about business models. No deals involved. So please do not make the mistake of concluding that caching changes any of that, because it does not. This is all about how can we make sure that the Web is as compelling as it needs to be. Whether that’s other people’s websites, whether that’s people accessing an article that might be shared with them on Facebook, it’s about making content instant everywhere, not just on Google surfaces. Want to make that very, very clear.
Mehta: So the Wired article is misleading, the way they have written it.
Gingras: It’s completely misleading, and based on what I have heard from you, it’s actually technically inaccurate.
Mehta: Reading again from the Wired article:
If readers decide to share a link to an AMP page they’ve clicked on through a Google search, the link points to Google.com (for example, google.com/amp/yoursite.com/yourpage/amp), not to your site.
That’s flat out wrong, is that correct?
Gingras: Well, again, what that’s pointing to is a cache of the article, nothing new in caching. So it’s not wrong to say that article is indeed rendered from the cache, but that does not change the core principles that the page is controlled by the publisher, it’s content is controlled by publisher with respect to business model, completely.
Mehta: I’m also looking at a Wall Street Journal article (“Google tests feature that lets media companies, marketers publish directly to search results”). There is a new feature allowing media companies to publish content on Google and allow it to appear instantly on search results. Reading out from it:
Google has built a Web-based interface through which posts can be formatted and uploaded directly to its systems. The posts can be up to 14,400 characters in length and can include links and up to 10 images or videos. The pages also include options to share them via Twitter, Facebook or email.
Each post is hosted by Google itself on a dedicated page, and appears in a carousel in results pages for searches related to their authors for up to a week.
So Google has said they are keeping this experiment separate from AMP, but looking down the road and going back to the concern of media publishers which are seeing all these experiments by social media websites to host the content directly, does this play into their concerns at all?
Gingras: On all the things that we are doing, we try to live by a core philosophy, one where the approach is open to all to participate. Secondly, a keen respect in the publishers’ need to create an experience for users which allows them to engage further. They build a relationship with publishers. Third, respect for publishers’ need to own the monetization of that experience. So all of these cut across the various efforts.
Mehta: So, basically, the answer is keeping publishers in charge of the money flow. So how would these experiments of Google, whether AMP or new feature, how is the core philosophy different? Google is also moving to a setup where they directly host content.
Gingras: As I said, important part here, is what’s the philosophy in terms of openness of the effort and respect for publishers being in charge of their content, in control of their business models, and ultimately in control of their destinies. So whether it’s an effort to help us get the freshest content or whether it’s an approach like AMP to architect the Web for speed, we want to do all of it with that philosophy in mind.
Mehta: Earlier, Google supported the responsive Web design, while AMP requires newsrooms to invest in a second code base. So how much of an extra investment, like newsrooms are already struggling, so how much extra investment is there for AMP, how seamlessly can it be integrated with their responsive Web design?
Gingras: First of all, publishers today are increasingly being asked to create custom implementation for various platforms, whether it be Facebook or Snapchat. The objective of AMP was to reduce that, come up with an environment that allows sites to be so fast that content distribution is not necessary. Produce it once, in one format, and have it used everywhere. That’s the objective.
And the truth is that AMP is very, very easy to adopt–and, by the way, responsive design is part of the mix. WordPress, for instance, already supports AMP in all their websites, which is about 25 percent of websites. In fact, one of the things publishers are looking for AMP to do, is to be that common format that allows them to do compelling, responsive-design websites that are super fast for desktop, for mobile, even the content expressed within their native ads.
Mehta: The vice president of The Weather Channel, Sheri Bachstein, was quoted in an AMP report (by eMarketer) as saying that it is an extra investment and they need to look at ROI (return of investment) and then decide whether to invest in the new code base. The exact quote:
The challenge for publishers like us who have invested in responsive Web design with a single code base is that AMP requires a second code base. We have to understand what the ROI [return on investment] would be from additional traffic vs. managing a second code base.
Is there a number on how many extra resources to switch, from earlier responsive Web design and new code base. Is that affecting the newsroom, their calculations?
Gingras: So again, want to reemphasize this, AMP does not introduce new technology into the mix. It is basically a re-architecture of existing Web technology, and once it’s adopted and implemented within the content management system that a publisher uses, their work should be done. Which is why WordPress joining is so significant. AMP supports responsive design, so it’s not a dramatic shift.
And for small publishers, that was a core objective as well. Big publishers have more resources, they are more able to deal with and work with proprietary platforms, and so on and so forth. Small publishers don’t have the ability, which is why we built AMP the way we did, why we made sure WordPress was supporting AMP the day it was announced.
Secondly, understand the issue we are talking about. One thing I was asked a long time ago is how fast does content have to be? My answer was simple: If it’s not instantaneous, you’re losing engagement with every additional second it takes to load a page. So this is core to any publisher’s objective. How do they make the sites that are compelling for users; how do they make those sites accommodate advertising that is respectful of users and also helps build their bottom line?
Mehta: Anything else I should focus on or know about when it comes to AMP?
Gingras: No, I think that’s largely it. With AMP specifically, I would say that it addresses the Web itself, not just content on different platforms. The Web right now is failing us and we need to, as I often say, make the Web great again.