If you’ve spent any time looking into Google’s “Accelerated Mobile Pages” (AMP) project, I’m sure you’ll agree: it’s wonderful to hear the AMP team talk about how using their framework (and hosting the output on servers owned or approved by Google) creates faster sites, and happier users. Few corporations have done as much as Google to elevate the importance of page speed as a design issue, and the work done by the AMP team is no exception.

But in my experience, the only voices promoting AMP’s performance benefits are coming from inside Google. Most companies I’ve spoken with don’t consider “happier users” or “faster pages” the business case for AMP. (In fact, some have found that AMP pages perform worse than their own websites.) Rather, those companies use AMP to ensure their articles appear in the carousel near the top of Google’s search results, a carousel that only displays content published with AMP’s proprietary format — which then, in turn, drives more traffic to publishers’ content. (At least, theoretically.)

For site owners, choosing to forego AMP means sacrificing higher visibility in Google’s search results — which means they’re effectively required to use Google’s AMP format. In fact, many companies I’ve spoken with say they’re seeing a massive slice of their mobile traffic coming from AMP. And that number’s almost certain to grow, thanks to AMP’s prominence in Google’s mobile search results.

I’m skeptical AMP would’ve gained the adoption it currently enjoys without the stick carrot stick carrot of higher search visibility that Google’s holding. In fact, AMP’s placement in Google’s search results creates a very, very skewed power differential between those who advocate for Google AMP’s usage, and those who publish their work on the open web. And since digital advertising revenue has been declining steadily for quite some time, most companies that rely on ad-subsidized traffic aren’t exactly in a position to argue with Google.

What’s more, AMP’s scope is expanding. There’s talk of an upcoming AMP variant called “Stamp”, an extension of the framework that’d provide a Snapchat-like, media-friendly experience for publishers (and their advertisers). But I’m also given to understand Google’s about to position AMP as a general site-building framework, similar to Bootstrap or Foundation. Rather than creating a separate feed of articles published in the AMP format, you’d just, well, design your entire site with CSS and (AMP-approved) HTML. For an example of this in action, take a look under the hood of the AMP project’s own website. If you view the site’s source, you might notice it’s filled with AMP-ish custom elements, with tags like <amp-sidebar>, <amp-accordion>, and <amp-img>. Each of those elements are styled with CSS, decorated with JavaScript, and laid out in a (quite fetching) responsive design — but they’re part of a proprietary markup standard, defined almost exclusively by Google’s staff.

I’ve had a few conversations with members of the Google AMP team, and I do believe they care about making the web better. But given how AMP pages are privileged in Google’s search results, the net effect of the team’s hard, earnest work comes across as a corporate-backed attempt to rewrite HTML in Google’s image. Now, I don’t know if these new permutations of AMP will gain traction among publishers. But I do know that no single company should be able to exert this much influence over the direction of the web.

I’m not the first to express concerns about AMP. And frankly, most of my reservations would go away if AMP wasn’t featured in Google’s own search results, something Yehuda Katz recently suggested. But that aside, I can’t help but wish Google had approached their “Accelerated Mobile Pages Project” differently, perhaps as a set of guidelines. Rather than creating a parallel HTML standard, and leveraging Google’s own search results to incentivize adoption, I wish the AMP team had defined a set of criteria that could’ve been validated by, say, Google’s own Lighthouse project. Doing so would have given site owners the tools necessary to ensure their work measures up to how Google defines a fast, mobile-friendly experience — but without sacrificing the standards, the decentralization, the self-direction that make the open web so powerful.

I want to be very clear: I believe AMP is a framework designed with good intentions, aimed at solving the very real problem of a web that’s gotten far, far too slow for its users. But using AMP? The cost for the web, and for those who do business on it, is much, much too high.

My thanks to Mat Marquis, Jeff Lembeck, Karen McGrane, and Scott Jehl for reviewing earlier drafts of this post.

This entry was recently translated into French, courtesy of Stéphane Deschamps.