Analysis

Will the race for a faster Web kill off small publishers?

October 14, 2015
Wikimedia Commons

Last week, when Google’s head of news, Richard Gringras, introduced Accelerate Mobile Pages, the company’s new open-source project aimed at making the Web faster, he said its main objectives were to create a “deal-less environment” that’s “about making sure the World Wide Web is not the World Wide Wait.”

The new model could have wide-sweeping implications for publishers, advertisers, and ultimately anyone who reads on the Web. By killing off most ad trackers and the slowest-loading parts of HTML, AMP will surely enhance the user experience by making pages load faster. It’s also a decisive step towards cleaning up the advertising ecosystem. But for smaller publishers and local orgs that depend on advertising revenue and may be slower to adopt what Google is offering, there are possible pitfalls.

AMP is a new breed of HTML that uses the fastest-loading pieces of the language while killing off the slowest. So far, it’s been met with a lot of excitement, much of it positive. Google has been praised as a fairy godmother, while AMP itself has been hailed as a possible savior for at least one major woe of the internet. “At its core it’s a simple mission. Letting the Web once again become a source of wonder rather than a source of frustration,” Tony Haile, CEO of Chartbeat, tweeted.


But as Google’s founding analytics partner, Chartbeat is getting in on the AMP project early, as are The New York Times, The Guardian, BuzzFeed, Vox, and 40 other big-name publishers who have the resources to adapt to the structural changes AMP imposes on the Web. Small publishers and local news organizations don’t share the same advantages.

By banning any tracking code that relies on JavaScript, as well as third-party scripts and a laundry list of standard HTML tags, AMP, as it exists today, does two important things: It dictates how publishers track their users and build metrics–only five ad networks are supported by AMP for now, and Google owns four of them–and it closes a loop around Google’s traffic by banning and customizing pieces of HTML that have been part of the open web for decades. AMP may be the open source answer to Facebook’s Instant Articles, but it creates a walled garden of its own.

Sign up for CJR's daily email

So what does this mean for publishers? They don’t have to adopt AMP (they might choose Facebook’s Instant Articles, or Apple News instead), but the ones who do have three options going forward. They can a)  build two different versions of their Web pages (HTML and AMP HTML), in the same way that publishers five years ago had parallel mobile pages; b) use a WordPress plugin that is currently in the early stages of development, and that will enable publishers to produce AMP-formatted content from WordPress; or c)  rebuild their sites from scratch.

AMP is still a work in progress, and Google says it’s ready “to collaborate with the entire Web community to develop this promising idea into something more real, sharing our techniques, ideas, and code.” The concern, however, is whether or not small publishers, or any publisher that’s strapped for cash or programmer talent, will be able to make the switch to AMP before AMP makes them irrelevant, or at least too slow to compete. Some may say good riddance to publishers who aren’t able to survive on a Web that’s faster, more user-friendly, and less ad-dependent–or, even better, they might say bravo to Google for forcing advertisers to compete on the basis of quality, as opposed to sheer volume.

But there is also worry among journalists and developers the deal may be a kind of Faustian betrayal: Google is offering publishers more speed in exchange for more control over their content as well as how it’s distributed, all while breaking the revenue model they helped create in the first place.

“Google is providing an opportunity, and you can’t necessarily blame organizations who take them up on it,” says Aram Zucker-Scharff, a freelance developer at PressForward, a free and open source software project that circulates scholarship, including journal papers, white papers, and digital projects. “But at the same time, it’s essentially sort of dishonest to say that AMP is going to solve the problems of the slowdown on the internet, especially when Google and DoubleClick for Publishers is responsible for the slowdown of the internet.” Shortly after the announcement, Zucker-Scharff tweeted:

Zucker-Scharff, who designs tools around user engagement and digital narratives, recognizes that AMP does provide a solution for some. “The advertising technology ecosystem is awful, it’s terrible, and a lot of the tech in there is really, really bad,” he says. “But trying to bypass it is something that will only work for large publishers. For the small publishers, they better hope the field doesn’t change fast enough that they go out of business.”

Many of the hurdles publishers will face in building parallel AMP pages, or new sites altogether, are technological. Since current content management systems and tools depend on and interact with standard HTML pages, publishers will need to build new systems and tools that can interact with AMP HTML. Even with a WordPress plugin, it’s an evolution that will require significant time and resources.

“A WordPress plugin will cover a lot of publishers for sure, but at the same time you still have to do some work. Why would you Invest in putting up an amp page and then ask your developers to build stuff that can’t be seen by Google traffic?”

And since AMP as it stands today only allows some very basic tracking, publishers may also be giving up the advantage of knowing how users are interacting with their content. These obstacles will likely hit small, resource-strapped publishers hardest.

Hours after the AMP announcement, some had already started experimenting with the demo:

Images and tweets aren’t the only things AMP kills. Until websites like archive.org, which Zucker-Scharff has worked for, figure out a way to start archiving AMP-only pages, a lot of content–text, images, your favorite BuzzFeed listicles–could be lost if hackers were to wipe out a site, or a publication were to suddenly fold. “When that happens, the first draft of history is lost,” says Zucker-Scharff.

What troubles some journalists and developers like Zucker-Scharff is the sense that behind the rhetoric around speeding up the internet, Google is essentially muscling publishers to adapt in order to survive by asking them to trade open Web standards for a code they built. They say Google’s response to Facebook’s walled garden has simply been to build one of their own and exert more control over how the web works:

As for being open source, all of AMP’s code is available for publishers to see and analyze, which gives them more control than they would have with Facebook’s Instant Articles. And yet others sniffed out a different motive all together.

“Again: Google AMP, Facebook Articles, Apple News are all just fancy RSS readers (that strip ads) & force publishers to sell ads through them,” Matt Haughey, programmer, blogger, and founder of the community weblog MetaFilter, tweeted. For all the promise that AMP holds for the future of a faster Web that’s more attuned to its users, Haughney’s 23-word reminder should ring in the ears of publishers large and small.

Damaris Colhoun is CJR’s digital correspondent covering the media business. A reporter at large in New York, Colhoun has also written for The Believer, The New York Times, The Guardian, and Atlas Obscura. Find her on Twitter @damarisdeere.