Google Is Going to Speed Up the Web. Is This Good?

To improve reading the news on mobile — and better compete with Facebook Instant Articles — Google today is launching AMP

Dan Gillmor

Published in

Backchannel

11 min readFeb 24, 2016

Starting today, some users of mobile devices will get a happy surprise when they click on links to stories from some of their favorite blogs or news websites: The articles will show up in their browsers incredibly fast.

This will be surprising because of the current state of mobile browsing. “Sluggish” is too tame a word for what we endure now, due to an accumulation of terrible news-industry design and business choices in recent years.

The speed boost is the immediate result of a new initiative by Google and a host of partners in the company’s “Accelerated Mobile Pages” (AMP) project. They’re creating what amounts to an alternative mobile web built on top of, or adjacent to, the traditional one — while remaining at least somewhat friendly to advertising. This isn’t as walled-garden-ish as it sounds; the project is collaborative and the code is open-sourced. But participating does require some reworking on the part of publishers. And Google, already a mega-power on the Internet, is playing an outsized role.

Before getting into details about what’s happening here, let’s be clear on something. AMP wouldn’t be necessary — assuming it is in the first place — if the news industry hadn’t so thoroughly poisoned its own nest.

Looking for money in a business that grows more financially troubled by the month, media companies have infested articles with garbage code, much of it on behalf of advertising/surveillance companies, to the extent that readers have quite reasonably rebelled. We don’t like slow-responding sites, period. On our mobile devices, which are taking over as the way we “consume” information, we despise having to download megabytes of crapware just to read something, because the carriers charge us for the privilege. That’s one reason why we use ad blockers. (The other, at least for me, is that we despise being spied on so relentlessly.) The news business could have solved this problem without racing into the arms of giant, centralized tech companies. But it didn’t, and here we are.

Enter the new editors of the Internet: giant, centralized tech companies that have created platforms on which we rely for our computing and communications. News “content” is useful to them, probably not so much because their executives have a public-spirited wish to ensure that we are all well-informed, but more because it drives further usage of their platforms, especially mobile ones. These platforms — notably Facebook and Apple — want to be the newsstands of tomorrow: the place we go, inside their own ecosystems, to get our news and information.

In a world where centralized powers have such reach, journalism organizations feel they have no alternative but to be part of those ecosystems. This is short-sighted, for several reasons. First, if one or two or a few centralized companies control the flow of news, information and conversation, that’s dangerous on its face; should Facebook and Apple (and Google) have the power to pick the big winners in journalism and other information services? Second, that kind of control inevitably leads to business practices that financially squeeze the participants who have no control, in this case the news organizations. Just ask advertisers how much power they had in the days when local newspapers enjoyed monopolies in most U.S. communities.

Moreover, these ecosystems depart from the essential principles what made the open Internet (in this case the open web) so vital: that anyone can build on it, in any way they choose and — this is crucial — without anyone else’s permission. Centralization torpedoes the promise of the open Internet. The founders of YouTube, Amazon, and, yes, Facebook relied on it. The way things are going, you may well need permission one of these days — that is, if you want a real chance at success.

Facebook, by far the most powerful of the new platforms, has invited major publishers to participate in its “Instant Articles” system, where news organizations literally publish inside of Facebook instead of or in addition to their own sites. Hundreds are now participating, and in April Facebook will invite everyone to join (while remaining free, someday, to change its mind and/or the terms of its revenue deals). Likewise, Apple is pushing its Apple News system. Although both are using web technologies to create their news products, they’re still Hoovering the open web into the maw of proprietary platforms — an incredibly dangerous trend from my perspective.

Now enter AMP. The concepts behind it, including making articles and other content more portable, weren’t new, but they jelled on May 16, 2015, at a “Newsgeist” — a gathering of journalists and technologists sponsored by Google and the Knight Foundation — in Helsinki. Facebook had recently launched Instant Articles, and part of the conversation focused on whether there “might be another way” for publishers to stay more in control of how their content made its way to audiences while maintaining their business models, recalls Richard Gingras, head of news at Google. He and David Besbris, vice president of engineering for Google Search, have driven the project inside the company.

After Helsinki, they moved fast, gathering partners and launching the open-source project. And on Oct. 7, 2015, AMP was announced to the world. Jeff Jarvis, professor, writer, new media advocate, and key participant in the Newsgeist conversation that sparked the project, was (and remains) ecstatic at what emerged. “A link is no longer an invitation to wait,” he celebrated. “A link is just a next page, instantly and fully visible.” (Note: Jeff is a longtime friend. I’ve also known Richard Gingras for many years and serve with him on the board of the nonprofit First Amendment Coalition.)

Google’s surveillance-dependent business model should give us all pause, but it does have a stake in maintaining an open web, or at least a web open enough for its own, search-advertising business to continue to thrive. To the extent that the competition can capture the advertising that flows into its version of the Internet, the demise of an open web is a clear and present danger to Google.

That’s essential context for AMP. The project, on one level, can be seen as a laudable, if imperfect, attempt to speed things up while retaining much of what makes an open web workable — but we can also recognize it as a strategic move to counter Facebook’s (and Apple’s) businesses. The question is — what does it mean for us?

So what is AMP, anyway? Take a look at this demo first. (Spoiler alert: it loads news pages fast.) Now, without getting too technical, think of it in a couple of ways:

First, it simplifies web pages, by allowing some things and not others. The most important: AMP won’t run JavaScript — except the (open-source) JavaScript “runtime,” written largely but not entirely by Google, on which AMP is is based. This is a good thing for the most part, because as noted, news sites’ web pages tend to require us to load and run massive amounts of code, and most of that code tends to be JavaScript.
Second, AMP is designed to load “content first, ads second,” says Gingras. What’s not to like about that?
Third, the pages publishers create for AMP are designed to be cached. That is, they are pre-loaded on servers — Google’s servers will be the most likely destinations, given the company’s offer to do this at no cost to publishers — at sites that are geographically near to users, so they’ll load even more quickly when requested.
Fourth, AMP allows advertising and analytics (software that watches and collects data on what we do), but in constrained ways. “We’re working to ensure that many scenarios publishers rely on will continue to work,” says Rudy Galfi, AMP project manager. Without ads and analytics, Google knows, publishers would just say no. This won’t begin to address the spyware issue, but it will give users a better reading experience and, possibly, lead to more revenue.

That last point is not trivial. One of the key objectives of AMP has been “to make sure publishers can monetize better than they can do today,” says Gingras. If it works, he says, AMP will “correct for a lot of the unfortunate ad behavior” that has led increasing numbers of users to install ad-blocking software.

There’s much more to this, of course. The project aims to support a wide variety of interactive capabilities, things like visualizations, quizzes, and more, via what Gingras calls “escape hatches” in the AMP architecture — page items that load separately from articles’ text, photos, etc.

And, like advertising, they also load later, in most cases. Great! We’ve all been stymied by apparently monolithic mobile web pages that keep us waiting while they load all kinds of images, ads and other stuff, only then allowing us to start reading. But AMP pages are created, in effect, as a bunch of discrete components. When someone wants to view the page, it’s rendered according to a combination of 1) where the component exists on the page (what’s at the top gets higher priority than material lower down the page); and 2) what kind of resources it needs to load, with components that require fewer resources (such as text) showing up first.

The component-ization of information is a growing trend, and by and large a positive one. Jeff Jarvis celebrates the idea that we’ll all create stuff that will appear wherever users are. But since Facebook is where so many people are, is it healthy for us in the long run to be feeding the beast that aims to be the Internet? You can guess my answer. (As Jarvis and others have suggested, Facebook might just as well adopt AMP itself for display inside its own site.)

Google, as noted, is no shrinking violet. And a big incentive for news organizations to participate in AMP is to satisfy their AMP “general partner” (my expression, not Google’s) on another front — better placement on Google’s search results. Google’s bread and butter is the ads it can sell based on search, and the company has made clear its intention to rank loading speed high in how it calculates search results. Google insists it won’t favor sites using AMP just because they’re serving up AMP pages, but that may become a distinction with little difference.

Gingras told me last week that Google’s search bots had seen AMP pages from more than 1,000 domains — including many major media companies — and, so far, 33 countries. Sites will have to create separate versions of stories, including at least one for AMP mobile pages and another for regular (desktop/laptop) rendering. Kinsey Wilson, ‎the New York Times’ executive vice president for product and technology, calls AMP “probably the most publisher-friendly solution we’ve seen to date” from the big tech companies, but making it all work takes real effort and staff time.

The Times has ample staff to make it all work; smaller publishers face a bigger hurdle. Even if it’s (relatively) simple to build AMP pages alongside the regular ones going forward, they’ll suffer to some degree if they don’t do this for the archives. (And, as open-standards advocate Kevin Marks notes, by relying on Google JavaScript code, not traditional HTML, for page rendering, AMP pages could ultimately make parts of the web even more fragile and difficult to archive.)

It’s not just traditional and online-only news organizations that are part of this. So are some other web platform companies, including Twitter and Pinterest, plus analytics companies like Chartbeat. Twitter, spanning the worlds of platform and media, is a key partner. One of Twitter’s goals is to make it easier and faster for people to include individual tweets in other pages. Another is to make sure that embedded links in Tweets get loaded fast in users’ mobile browsers.

Another crucial partner is WordPress: an enormous portion of the Web, over 20 percent by some estimates, comes from its sites. As with other participants in this initiative, Automattic, the company behind WordPress, worries that the open Web is in trouble. So it’s building AMP into its WordPress.com commercial site, and making a plug-in available to people (like me) who run the free-to-use software on their own servers. My personal WordPress site is about as stripped down as it could be in any case, so AMP won’t make it all that much faster. But the cumulative effect of WordPress plus AMP is bound to be significant.

Keep in mind that AMP is, at most, in Version 1.0 condition: a minimum set of working features needed to get wide buy-in from the various players. The community it has generated to discuss, build and tweak the code and policies is impressive, and regularly adding members. Google is coordinating a number of working groups discussing various elements and issues, and it all seems to be rolling along. For a project that was hatched only last year, it’s made great strides, to say the least.

I still have a million questions about this, and some are the ones I began with: What if Google changes its strategy, by making it more proprietary and centralized? What if news sites had just done the right thing in the first place? Or, since they didn’t, what if they just resolved to build faster pages — using standard HTML markup and loading components in a non-annoying way — now? Wouldn’t that have gone a long way toward solving the problem? Do they, and we, really need all this?

For now, at any rate, the answer seems to be yes.

Google Is Going to Speed Up the Web. Is This Good?

To improve reading the news on mobile — and better compete with Facebook Instant Articles — Google today is launching AMP

Further reading

Written by Dan Gillmor