Unless you work in the media, or have a fascination with things like the mechanics of Javascript calls in publishing software, you might have missed the launch of a Google project known as Accelerated Mobile Pages or AMP. In typical Google style, this boring name hides something fairly revolutionary — or something that could be revolutionary if enough media companies support it. But will they? And should they?
Without going into too much detail (there’s more here if you are interested in diving deeper into the technical aspects), Google has come up with its own variation on HTML, the code that underlies the web. This new version would streamline the display of most webpages by using a common library of code, so that every publisher doesn’t have to include megabytes worth of the same programming in every page, and it also allows for smart caching of that data for faster loading.
Nuzzel founder Jonathan Abrams, whose social-news app supports AMP, says that pages from websites like the New York Times that have been optimized with Google’s code load in less than half a second, compared with the usual loading time of about six seconds. And there are many who support the Google initiative, like Vox Media’s director of product Trei Brundrett, who said he was optimistic about the results:
Although the man behind the Google effort, head of news Richard Gingras, doesn’t like to describe it as such, AMP is clearly a response to Facebook’s “Instant Articles.” That’s the recently launched feature that allows certain publishing partners such as the New York Times and The Guardian to publish their content directly into Facebook’s mobile platform, so that their pages look better and load faster.
This amounts to a threat to Google in two ways: In one sense, it threatens the search giant’s advertising base, because web advertising and increasingly mobile advertising are the core of the company’s business, and if Facebook vacuums up a big chunk of that then Google suffers. And the second, related threat is that the more content gets published inside the Facebook walled garden, the less there is for Google to search. Apple’s new News offering poses a similar problem.
So Google pretty clearly has a vested interest in the open web, since that is what it has built its multibillion-dollar empire on. And it has pitched its new AMP offering as a way of strengthening the open web, and in particular the part of the web that has to do with publishing and mobile advertising.
Gingras says the rise of ad-blocking software has made it increasingly obvious that many users hate the kind of slow-loading pages many publishers are putting out, the ones that are filled with megabytes worth of tracking scripts and popup ads. AMP would solve many of those problems, Google says, and — although the company doesn’t come right out and say this — it would do so without forcing publishers to embrace a proprietary solution like Facebook’s or Apple’s.
Chartbeat CEO Tony Haile, whose analytics firm has partnered with Google on AMP, says that fixing the mobile web in the way Google has proposed would also help the open web compete with proprietary apps, which for many users have become the primary way they interact with content and media. Not everyone agrees, however.
The search giant has taken pains to make the AMP project as open as possible: The code behind the effort is all available on Github, which allows any programmer to view and even potentially modify it, ask questions of the developers, and so on. Of course, the fact that it uses an open repository doesn’t mean that Google isn’t running the project, or deciding what gets included and what doesn’t.
As a number of critics have pointed out, using AMP would come at a certain cost. For one thing, as Josh Benton at the Nieman Journalism Lab has pointed out in a thoughtful analysis of the project, the initial specification makes it impossible to use any kind of Javascript-based tracking or analytics codes in a page. That means many publishers would be unable to get certain kinds of information about their users, and many of the advertising formats they use would no longer work. Says Benton:
“Yes, publishers don’t have to adopt it, and yes, it’s an open source project, and yes, the performance gains are very real and very substantial. But publishers can choose to adopt Facebook Instant Articles and Apple News too. The point is that this is another stop on the path to powerlessness for publishers — another case of tech companies setting the rules.”
Google says it wants to develop ways to incorporate other kinds of analytics and advertising, by coming up with a centralized library of code that can integrate with any analysis or advertising network’s back-end. But that will take time. And in the meantime, some sceptics feel that Google will not-so-subtly be encouraging publishers to use its ad network and analytics, since they already work with AMP.
So should publishers be embracing AMP? Perhaps not entirely, since it is so new and it could impact their monetization fairly heavily. But it has to be worth experimenting with, if only because it solves a speed and usability problem that publishers and ad networks have so far been incapable of solving on their own.
One criticism from some open-web advocates is that AMP represents a step backward for the mobile web, back to the days when there were customized mobile pages designed for WAP browsers that restricted what publishers could do. And there are those who don’t feel any better about Google controlling the specs behind a major reinvention of the web than they do about Facebook or Apple and their walled gardens.
That said, however, at least Google’s AMP project is trying to be as open and inclusive as possible, unlike Facebook’s Instant Articles — which, like most of what Facebook does, is a black box into which content disappears. No one really knows what happens to it or why, unless they are a Facebook employee, or they have the keys to the algorithm.
And as Benton noted, publishers have another option if they don’t like Google’s AMP project: They can simply take the best parts of the specification from the publicly available documentation and implement those themselves. That way they get faster-loading pages and everyone wins. Of course, if they had the ability or the desire to do this, presumably they would have already done it by now.
You can follow Mathew Ingram on Twitter at @mathewi, and read all of his posts here or via his RSS feed. And please subscribe to Data Sheet, Fortune’s daily newsletter on the business of technology.
