Almost five years ago, Google debuted a splashy new project called Accelerated Mobile Pages (AMP) that promised to speed up load times on websites accessed via phone. Fast-forward to today, and AMP has grown into something much more ambitious: Earlier this month, Google rolled out a new feature that allows AMP to use server-side rendering (SSR), boosting performance for sites that adopt the technology across their entire domain.
The overall AMP project launched with a focus on news publishers. They’re asked to create a second, lightweight version of their articles; these versions surface in Google Search and load relatively quickly on mobile devices. In return, Google raises the search-results ranking of pages that use AMP, providing an influx of free traffic. Google itself even hosts “approved” AMP pages for publishers accepted into Google News, circumventing publishers’ websites entirely unless users click through on a separate URL that appears at the top of a page. AMP adoption is also the only way to gain access to Google’s Discover feed, which features articles on the page that appears when you open a new tab in the Chrome browser, potentially driving hundreds of thousands of views if the algorithm chooses your content.
At first, AMP specifically targeted mobile devices, but it has begun quietly experimenting with desktop sites as well. Publishers may soon find it’s best to enable AMP across their entire domains, putting more eggs in Google’s basket. Everything’s come full circle with the new SSR functionality — why not just put your whole website into the format, right?
To be clear, the concept behind AMP isn’t a problem. In fact, it’s fundamentally a good idea. Why shouldn’t mobile users have access to faster-loading, stripped-down web pages? The problem is that speed comes with a major catch.
AMP strips publishers of full autonomy and control over their content. Hosted AMP pages obfuscate the source of what you’re reading, removes some control over your own brand, and essentially allows Google to use your content for free under the guise of making the web better. It hides your URL in favor of a Google.com-hosted version. (Though that will soon change for developers who opt to enable a “signed exchange” that authenticates their content with Google — a complex, technical workaround for what appears to be a simple design problem.) Previous applications of AMP even threw posts into a swipeable carousel, as if all the content were on display in a shop window.
All of which is to say that AMP is a way for Google to own the browsing experience. Sure, it’s technically optional — but it’s not really an option. If developers don’t use it, they stand to miss out on important traffic. Their websites will rank significantly lower in search. Google is by far the dominant search engine, with 92% market share worldwide and 94.5% on mobile. It’s simply impossible to ignore.
I’m well aware of all these problems because I was there when AMP was born. I attended the event where Google unveiled the project and hailed it as the savior of the mobile web. It was a noble cause: Someone had to do something about how slow and horrible it was to use the web on a phone. I worked at a news company that adopted AMP as a launch partner, and I’ve used it on my own site. It’s hard to exaggerate how much impact adding AMP support to a website actually has on traffic.
Here’s traffic to my site in 2018. I implemented AMP in late 2018 and saw a spike in traffic, almost doubling inbound clicks and impressions. My blog is smaller than a major news organization, but flipping on a hastily coded version of AMP added more than 3,000 more impressions a day, or 1.3 million potential eyeballs I wouldn’t have had otherwise over the past year.
At first, all of this was great: AMP sped up the web and provided a genuinely better experience for users. As it became popular, however, AMP quietly became a tool for entrenching Google’s technology into the web itself. It’s unavoidable if you rely on traffic to sell ads against your content, for example. Though the technology is technically open source, it’s really about as open as Chromium, the project Google Chrome is based on — meaning, not really at all. Sure, anyone can contribute to the code and read it on GitHub, but the primary contributors to the format’s direction are Googlers, who also happen to be the ones who tend to decide on AMP’s roadmap. The company likes to talk about how others contribute to the format, but it alone controls the most important platforms AMP runs on.
There’s still no way to say that you prefer the full version of sites or that you don’t want to be served AMP pages at all.
If you want to jump in and use AMP for your subscription journalism, for example, there’s a handy component for that. The catch? The only provider available for it is created by Google, and the ability to use those tools is by invitation-only, with no contact details or information in the documentationabout how a developer can actually use it without being chosen by the company. The Financial Times is able to allow subscription access via the AMP product, but I couldn’t implement it on my own, smaller blog at this point. (I’ve regularly tried contacting Google about AMP products like this one, but the company doesn’t reply to inquiries.)
And readers can’t automatically opt out of AMP. Using AMP means a stripped-down version of the page that can be difficult to copy a link from or browse the rest of the publisher’s site — let alone avoid being tracked by Google as you’re reading. Nearly five years into AMP, there’s still no way to say that you prefer the full version of sites or that you don’t want to be served AMP pages at all. The only way to avoid them is by not clicking anything with the AMP logo in search.
As a publisher, there are few ways out. It’s harder than ever to get traffic, and AMP provides a lot of it for free. Try to remove AMP, and your search ranking tanks. I broke my own AMP pages accidentally in April 2019 and saw a monthlong drop in traffic until I figured out what was going wrong.
A single tag typo saw me lose hundreds of potential readers every day because Google’s algorithms stripped my AMP boost as soon as it broke.
As AMP’s ambitions continue to grow and Google tries to get publishers to build entire sites using the format, it’s getting harder to keep up. Building a second version of your pages for Google AMP and a third for the Apple News platform was already a nontrivial investment, but now building your whole site in a special format? No, thanks.
Google has argued that AMP is good for the web as a whole and that it cares about journalism. I agree that the company has invested heavily in the ecosystem and that AMP has helped make the web faster — but if Google genuinely cared, it would rank pages based on speed alone, not whether they use some special format of HTML. If the company wanted a better ecosystem, it could build something that didn’t push publishers into investing limited resources on a format that primarily furthers Google’s goals.
If I use AMP, I tie my fate to Google’s whims.
But I’m worried that these concerns are too late and that the damage AMP has done to the web is already too extensive. As an independent publisher running my own blog outside of this column on OneZero, I can’t avoid AMP, because I’ll be drowned in Google’s opaque search algorithms and ignored entirely by products like Google News.
But if I use AMP, I tie my fate to Google’s whims and am along for the ride no matter what it tries to force in the future. Every news publisher I can think of faces these challenges today and will come to the same conclusion: Get AMP, or get left behind.
No comments:
Post a Comment