Note: Content might be outdated!
While large parts of my WordPress timeline have been outdoing themselves in climbing the Gutenberg lately, there’s been stuff happening around Google’s Accelerated Mobile Pages of which a nagging feeling keeps telling me I should come to grips with now, or I might not have a profession in a year or two.
If you have a minute, watch me unravel about AMP, Google, WordPress, and how to move an ant hill.
Update December 2020
This may render parts of this article, or all of it, irrelevant: AMP Under Fire in New Antitrust Lawsuit Against Google
In this article
- What’s the problem AMP tries to solve?
- How does AMP solve the problem?
- What is AMP?
- Why is AMP controversial?
- So why AMP?
- For we know not what we do?
- WordPress has democratised screwing up 30% of the web
- Corporate WordPress to the rescue
- Ok, but … why AMP??
- The donkey paradox
- Epilogue: How to move an ant hill
- Personal notes and conclusions
Side note: About this article
These are personal thoughts and learnings, and I’m still learning. If you think I missed the point here and there, I appreciate it if you let me know.
You’ll see a few sections (like this one) titled “side note” throughout this article. They’re contextual little detours. Feel free to read them in order of appearance, or skip them and come back to read them later, or never read them at all.
You’ll also see a few illustrations of birds uttering random profanity. I’ve asked their creator for permission to use them, because I think they’re hilarious.
What’s the problem AMP tries to solve?
Facebook, by and large.
The way the soup has hit the fan with Cambridge Analytica kind of looks like a bat signal to save the open web. I don’t think we need to go into why we must not let Facebook continue to replace the World Wide Web on the World Wide Web. (And I’m using “Facebook” partly as a placeholder for closed platforms in general.)
Google are one of the largest stakeholders of an open web globally. Their business model is selling ads and web services, and they’re losing millions of new internet users to Facebook while billions more are coming online.
If standard web pages are going to compete with closed apps, usability and performance on the open web must be improved at scale, and fast.
Other than a walled garden like Facebook, though, the web poses a huge challenge:
Google need to get other people to optimise their web pages.
Something that often gets overlooked, though, is the fact that Google is just the largest player in the game. Probably everyone reading this article depend on the web in one way or the other.
Problems that Google see on the open web aren’t necessarily affecting individuals like you and I yet. However, anything that makes Google’s seismic needle quiver is likely going to affect us in the near future.
If the only way to reach an audience to do business online will be over closed platforms in the future, everybody loses.
How does AMP solve the problem?
Accelerated Mobile Pages essentially limit the code that renders a mobile web page to a set of whitelisted components. This provides a safe frame for pre-rendering pages on the server, so they can fire up instantly in the browser.
People use all types of mobile devices with all kinds of ranges of technical capacities to access the web. Getting performance right at the root requires design thinking down to a technical level of whether an animation uses CPU. Few developers I have met can afford to think about that kind of thing on a regular basis.
AMP aims to cover those little big details meticulously, and provides a framework to serve mobile web pages more inclusively to people all around the world, even on devices with weak CPU, and in browsers that don’t necessarily support recent standards.
In short: AMP makes
static (update: all kinds of) content fast and usable on as many types of mobile devices, and under as many network conditions as possible.
Side note: Bundled bandwidth
I can’t prove it, but I’m wondering whether the ability of making a rough prediction of how big a web page will turn out in size when it’s rendered is of any relevance for AMP; as it certainly has been for the rise of closed apps in areas with low infrastructure.
WhatsApp’s constrained format, for example, makes it super convenient for mobile operators in many African countries to predict how much data a person will consume over the course of a week. So they offer inexpensive WhatsApp-only data bundles instead of having people burn precious bandwidth on obese pages on the open web.
If you rely on infrastructure that only allows for so much traffic to go down the wire, limiting what people can do with their bandwidth can become a necessity. And when you think about it, there’s no such thing as infinite bandwidth, nowhere.
We live on a finite planet. I’m not trying to advocate for arbitrary restrictions on data (yes, net neutrality!), however, self-regulation doesn’t seem to work either.
The majority of WordPress sites I see on my support job each day, from all around the world, are built as if there was no tomorrow.
What is AMP?
AMP is at least three things:
- AMP HTML:
- Mostly HTML, but with a few custom elements and attributes to ensure an AMP page can be validated as such.
- AMP JS:
- AMP Cache:
- The server-side part that makes a page ridiculously fast through pre-rendering. It’s worth mentioning that AMP Caches are an important implementation of one of the design principles AMP is based upon: Solve problems on the right layer.
All of those are open source, and none of them makes Google more important than they already are. Even AMP Caches don’t have to be operated by Google. Cloudflare have launched their own recently, others will follow.
The part that’s not open source is the way Accelerated Mobile Pages are treated/used/favoured by other platforms, first of all Google’s own Mobile Search.
Side note: Because we can
The makers of AMP probably could have used standard HTML to come up with unique attributes, like
data-amp or something.
On the other hand, when you’re trying to push a new framework to the entire web, you better be careful about the assumptions you make.
A thing like
<html ⚡️>, or
<html amp> simply didn’t exist before, so it’s definitely unique.
It also frankly looks better. If you were to ship code you believed to become the foundation of the mobile web, would you have its main identifier be boring old
data-blah, or a geeky fresh emoji attribute?
AMP HTML is a statement in and out of itself, apart from its technical implications. It’s a mindset wrapped in code: “Because we can.”
Why is AMP controversial?
I’d like to offer a somewhat biased selection of answers to this one, to highlight a certain type of criticism. So the following list is by no means complete.
Among other things, AMP sparks controversy because:
- Some people think Google are abusing their power to introduce a corporate-flavoured HTML variant as a new quasi web standard, thus undermining the purpose and existence of true web standards.
- Some people think Google are abusing their power by favouring their own framework on their search platform we all depend on, essentially creating a two-tier web where those who adhere to Google standards (AMP) win over those who don’t.
- Some people think Google are abusing their power, because that much power concentrated in one place will automatically transform decent human beings into greedy assholes, regardless of any good intentions they might have started out with.
- Some people think Google, and stop right there.
Side note: people aren’t companies
Isn’t it curious how easy it feels to blame a company for just about anything? It’s a trap, of course. Companies are conglomerates of ordinary (albeit often talented) people. And most people don’t spend their day plotting a plot to make everybody else feel miserable.
Each time I catch myself saying “company X did this” I remind myself to put faces to the action. It’s much harder to attribute insincerity to a person than dismissing an anonymous corporation as too big to do good.
So why AMP?
What drives the folks who made AMP?
AMP lead Malte Ubl spoke about the motivation behind AMP when he wrote about standardising lessons learned from AMP recently:
We started working on AMP because we were seeing the mobile web feel clunky and slow, falling behind the tightly-integrated, highly-optimized user experiences that walled garden platforms can offer.
Or, as he had said earlier when asked why they created AMP instead of proposing a set of performance-oriented web standards in the first place:
We were worried about the web not existing anymore due to native apps and walled gardens killing it off.
We wanted to make the web competitive.
We saw a sense of urgency and thus we decided to [..] build AMP instead of waiting for standards and browsers and websites to catch up.
I stand behind this process.
I’m a practical guy.
Let’s hear that last one again, slightly paraphrased:
We were worried about our environment going extinct.
We wanted to do something to help.
We saw there wasn’t much time left.
We decided to take action.
I take responsibility for what we’ve done as a team.
I value actionable solutions over theoretical debates.
Clearly a corporation trying to force the world into a straightjacket, isn’t it?
Let’s paraphrase again, and (Entschuldigung, Malte) I’m going to over-exaggerate to make a point:
This place is dying away under our feet.
So excuse us while we NOT ask for anyone’s approval, or permission, as we have ZERO time to wait for old farts debating principle, or politics.
We must change NOW if we’re going to have a planet to live on, y’all, let’s DO THIS!
Did I say planet? I meant to say: web.
And yet, in the era of computer-synchronised rocket ship ballet and self-driving cabs running over pedestrians, the one web we’ve built, the one planet we’ve inherited, and the one humanity we embody, more than ever seem strangely interconnected.
Side note: Internet, Inc.
Russia has had it with Internet, Inc. Made in Silicon Valley, they’re building their own.
Meanwhile, an ever growing demand for virtual bandwidth has us wrap the Earth in a very physical net of submarine cables, so that Google and Facebook can send 144 TB/s from Los Angeles to Hong Kong. (Russia, again, says hi.)
We’ve literally placed the open web behind a paywall, simply by not giving a shit.
“Y’all, we got this”, says Facebook as WhatsApp has replaced the internet in some of the the world’s biggest markets.
With authoritarianism on the rise globally, now more than ever is the time to invest in a healthy, decentralised, diverse, and open World Wide Web.
We genuinely don’t care for those things, though. We care for header videos, Instagram widgets, intrusive popovers, and ruinous third-party ad implementations.
For we know not what we do?
So while the motivation that drives the folks who made AMP undoubtably is sincere, the underlying witch craft that spelled the thing into existence clearly is our own day-to-day ignorance.
We’ve forced millions onto closed platforms as we’ve built a web that’s unusable from anywhere else than our privileged urban bubbles.
Yet we have the nerve to complain about AMP being “forced down our throats”. Yes, it is forced down our throats—as a life-saving tube, to ensure the web will continue to live and breathe!
Earlier this year, Chris Coyier concluded in a response to Ethan Marcotte:
AMP, as a technology, is saying y’all have lost the plot here and we need to save you from yourselves.
Ethan had described his experience testing the off-shelf performance of a random selection of WordPress themes.
To him, the results of his tests came off
On a 3G connection, the slower themes I tested took anywhere from 45-90 seconds for any content to appear. In other words, the pages took roughly a minute before they were usable.
I can personally confirm Ethan’s experience, although I have to say having dealt with hundreds of DIY WordPress sites as a customer support agent, the surprising moment wears off pretty quickly, and you begin to notice patterns.
WordPress has democratised screwing up 30% of the web
I’m saying the above with all the love I have for WordPress’ community, and from the highly biased perspective of someone who has made a living patching up desperately messed up WordPress sites for the last five years. So please take that headline with a grain of salt.
Point is, not only can literally anyone whip up a WordPress site these days, in the complete absence of any clue about how the web works, or what is required to be a good citizen; WordPress itself also hasn’t enforced any significant house rules up to now.
Other than the security checks on the WordPress.org repositories, there are almost zero limits to what third-party code can do to a WordPress install:
The moment they activate your plugin or theme, you’re literally free to pee on a person’s rug.
The people of WordPress have succeeded to democratise publishing on large parts of the web. However, let’s not forget
Corporate WordPress to the rescue
The potential solution to WordPress’ little “peeing” problem is a thing named Tide, no pun intended.
From the project page:
Tide is a series of automated tests run against every plugin and theme in the directory and then displays PHP compatibility and test errors/warnings in the directory.
Tide is also based on the premise that WordPress will shape the future of the web in one way or the other:
WordPress plays an undeniably large role in [a future where the open web is more performant, secure, reliable, and accessible] with the quality of code across the ecosystem setting the stage for either its success or struggles.
Tide was initially built at XWP, and has since moved to WordPress.org where its maintenance is supported by XWP, Automattic, WP Engine, and Google.
In other words, Tide is a great example of what I like to call Corporate WordPress:
Companies from the WordPress industry, together with an ally no less powerful than Google, have joined forces to support contributions to the betterment of the WordPress ecosystem at scale.
A 30% chunk of the web potentially being improved by a single component.
It’s an interesting fact that pretty much the same companies (not sure about WP Engine) are collaborating to bring canonical AMP to WordPress.
The undeniable productivity of Corporate WordPress comes at a cost, though. Contributing in itself has gained momentum. Components like the Gutenberg editor, much like AMP on the Google repository, iterate fast—too fast for most people to be able to keep up.
Even though individual team members go great lengths in welcoming every new voice, and treat every concern with respect—at their current pace both Gutenberg, and AMP have struggled to build trust in the integrity of their underlying decision making within their communities.
Ok, but … why AMP??
Look, when a question starts with “why”, the answer almost never is about technology.
AMP isn’t even a new technology. It’s a wrapper to get people to use existing technology in a certain way. We all know HTML and CSS can power fast web pages. Even people from AMP say you don’t need AMP for that.
So, yes … why on earth?
The real problem with performance on the web is that the recipe for fast web pages is boring simple:
Load less stuff.
Effortless. Everybody can do it, but nobody wants to, because it’s not doing a thing—it’s not doing that thing.
“Less” doesn’t sell. Clients, as well as theme and plugin customers, pay to get maximum value in return for precious currency, and to most people value means: features. Matter. Stuff.
Side note: More for less
Some people, even when financially well off, obsess over the idea of getting more for less. Their life is constantly complicated, because they’re hardly ever satisfied.
They’re the ones who demand a coupon in return for their sheer existence, and they’re prepared to spend an hour on your live chat giving you shit for not seeing how they deserve better than everyone else around them.
While wanting more for less seems to be the default mindset in our consumer society, an increasing amount of people consciously choose to want less—“less is more”, you’ve heard it before.
Those people value simplicity, and to simplify means to design your own desires. Perhaps that’s why people who choose to get more out of wanting less often happen to be the most relaxed, friendly folks to be around.
“Less” doesn’t sell even when it’s free.
Showing off one’s skills isn’t exactly exciting when there’s less stuff to show off. How many developers you know regularly boast about all the stuff they didn’t do on a web page? Getting an ego boost from simplicity—stuff that isn’t there!—and creating a sales strategy for it, is an art only few have ever mastered.
For years, Google have tried—and failed—to secure their business model on the open web by teaching webmasters and developers how to implement good practices for better performance, particularly on mobile.
People just wouldn’t do it.
So many of the support customers I help on a daily basis must have that 100% performance grade while their website clearly reflects the profound and complete absence of any technical skills whatsoever.
I’m the last one to blame those people for not being experts. They run a website not because building websites is their business, but because running a business is their business. That’s perfectly fine—until it is not.
Even after five years in customer support I struggle to accept the fact that a lot of folks out there sincerely seem to believe you can stuff a website like a turkey on Thanksgiving, slap yet another WordPress plugin on top of it, and magically have your pages turned into a streamlined mobile UX dream.
It’s a paradox, it can’t work.
And it’s exactly what AMP does.
People don’t figure stuff out these days. People expect stuff to figure itself out, so they can go ahead and just use it. In short: People want products.
So the AMP team had to perform a little marketing stunt and reverse the psychology of excellent performance.
This is what AMP tells you to do instead of “load less stuff”:
Load new stuff!
“New” means there’s stuff to get excited about. Better yet, it doesn’t cost a nickel, and it comes with super-powers!
“New” arguably also means you get to contribute to the Golden Arrow of Consumption. It definitely means you can do something instead of doing something not. And after all, for most of us “new stuff” means: sales.
So, why AMP? Because it’s a product.
Performance, careful design thinking, good citizenship on the web—these things are virtues. You have to practice them.
AMP wraps all these things into a convenient package and enables you to use instead of practice. There’s no need to change, to learn, to understand, to perhaps become a better person on the way even—just use new stuff.
The donkey paradox
Part of the reason why AMP, other than an organically grown open source project like WordPress, is developed and marketed as a product, is that its core objective is massive adoption, in the shortest time possible.
Achieving that goal obviously requires a massive growth hack—even more so since a strategy like “commoditising excellence” is based on the premise that you can’t assume excellence among your target audience.
Google’s growth hack for AMP is what arguably makes it “the most contentious piece of the web” as The Verge has put it recently:
Publishers that support AMP show up in Google’s top stories carousel, which means a flood of traffic. It’s a huge incentive …
Incentive. Carrot, stick … donkey.
The paradox here is that in dismissing people from practicing their agency, and treating them as “donkeys”, Google inevitably contribute back to the problem they’re trying to solve: irresponsible consumerism on the web.
Update: Tim Kadlec concludes from a number of tests that actually “the incentives being placed on AMP content seem to be … incentivizing AMP, not performance”.
If AMP will be turned into new web standards eventually, those will be standards driven by the business interest of the largest player in the game, on behalf of the rest of us—
That millions-of-souls rest of us who prefer to not get involved, or can’t afford to, as we trot along, heads down, faces glued to the screens of our phones, immune to the shame of our complete surrender as humans to the one and only role corporate tech ever had and ever will have reserved for us: the role of a user.
Apparently, we have to be incentivised into our own future, because we can’t be bothered. But it sure sucks.
Epilogue: How to move an ant hill
From the creative chaos in its early days, WordPress has moved to organisational structures companies from its ecosystem are able to relate with, and can justify allocating resources to.
However, from outside of the community bubble, WordPress today still looks like what it factually is: A human ant hill.
How do you move an ant hill to a new place?
You certainly don’t try to persuade the collective body of the colony into packing up and digging a new nest.
Experts suggest you don’t actually move the hill at all. Instead you would catch a fertile queen and put her in a test tube, so she would eventually start producing her own new colony.
I believe that’s exactly what’s happening at this very moment.
With Google partnering up with Automattic et al. to bring Progressive Web Apps to Jetpack, and AMP to WordPress, we’re witnessing the early stages of a new ant colony—one where WordPress could progress from its old, often frowned upon codebase to a beacon of modern web technology where progressive themes and accelerated mobile experiences shine.
WordPress is AMP’s ticket to 30% of the web.
Once the dust has settled around Gutenberg, and the idea of what AMP can mean for theme and plugin businesses has begun to manifest in public discussion, I don’t think there’s anything holding AMP back from becoming a new standard for mobile experiences in WordPress.
An interesting detail in the making of a new ant colony is that once a fertile young queen has mated and is pregnant, there’s no way for her to go back to the old nest. So you end up with two ant hills—which isn’t a problem in most ant breeding scenarios, but it could become one for WordPress.
That being said, Alberto Medina, if by any chance you happen to be reading this, I’d like to say you look like a very skilled and gentle mover of ant hills. From my little balcony inside of the old colony, I wish you well.
Personal notes and conclusions
My journey to writing this article started with a comment on the XWP blog. Aside from noting that I’m not necessarily proud of that comment, I would like to express my gratitude to Luke Carbis from XWP for mustering the most amazing amount of patience and kindness in his response to my agitated gibberish.
I’ve since written (and not published) close to 9,000 words on AMP, simply because writing is my preferred way of processing a topic. Research, learn, write, doubt, research, delete, repeat—some of you know the deal, I’m sure.
So far, it has taken the better part of three months for me to do my homework on AMP, to the point that by now I feel I have understood why it exists, why it has been successful, and why I felt so mad about it. Getting to grips with last part was the hardest.
I felt mad, because AMP put me in my place.
I had thought the crisis of the open web could be solved with education, flanked by a standardised, whitelisted library of well-optimised WordPress components—Accelerated WordPress, essentially, or WordPress lite.
In both, my ignorance and arrogance towards AMP I hadn’t even noticed AMP was pretty much just what I believed was needed—only a lot more advanced.
Instead, I had enjoyed dreaming up a great adventure where a diverse task force of community people would set out to fix WordPress’ performance at the root of the problem. The realisation that task force has been at work for years (just not limited to WordPress), and the solution they’re bringing is AMP, was kind of a tough awakening to my still kind of naive view on the web’s problem.
On my quest to understand AMP, I have been able to align my personal experiences as a support rep for a WordPress caching plugin with what I believe are some of the core premises AMP is based upon:
- That education alone fails at the scale of the crisis we’re dealing with;
- That most people just can’t afford to build up the level of expertise required to make truly high-performing websites;
- That we’re running out of time;
- That an accelerated “silo” on the open web after all must be considered less harmful than a walled garden, at least as a starting point;
- And that in our hyperconnected consumer society classic virtues like integrity, empathy, or just common sense can’t get people to act in their own best interest, but a streamlined product can—even in web development.
Last, but not least, the most compelling argument for AMP to me has been a realisation about its loudest critics—people like myself with my comment on Luke’s post only two months ago:
Those who criticise AMP the most usually are the least affected by the problems it aims to solve—2G networks as a regular, low CPU devices, old operating systems with browsers that don’t support the latest and greatest new stuff from the web standard portfolio yet.
There’s room for critique even when you’re not affected, of course; for what it’s worth, though, I can say I’m glad I didn’t publish some of my early rants, and I got a lot more aware of my own biases doing more research instead.
I thought I hated AMP. I now realise that what I hated was the fact that a thing like AMP has become necessary, and that I—like you, probably—have contributed to its becoming a necessity.
I’m cautiously trying to embrace the fact AMP exists and continues to make its way into WordPress. It still hurts, like any tube being forced down one’s throat.
I hope sucking it up will really save our lives on the open web.
🦉EffinBirds appear courtesy of Aaron Reynolds.
Thanks go to Lucy Beer, Andrey Savchenko, and Remkus de Fries who endured reading earlier versions of this piece, and provided helpful feedback; also to Jenny Beaumont and Thomas Kräftner for gently kicking my butt to publish something at all.
Got thoughts, corrections, opinions? Drop a comment, or webmention!