AMP and WordPress will scale performance on the web for millions of users, hate it or love it

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

---

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.

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:

A library of pre-made JavaScript components. No custom JavaScript is allowed on an AMP page, except in an iframe. (Update: This is going to change at some point.)

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.

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.

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.

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 “surprising”:

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 “variety and disorder” go hand in hand in a democracy.

We’ve got a huge amount of homework to do as to how WordPress is going to deal with the fact it has helped messing up 30% of “the web” as a byproduct of its Four Freedoms.

Gutenberg may harmonise the site building experience, thus mitigate the dilemma of plugin and theme UX, but it won’t prevent a plugin from cheerfully peeing on your rug.

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.

“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.

As the WordPress ecosystem is buzzing with Gutenberg ante portas, the idea of canonical AMP in WordPress is slowly being moved from the sidelines to the centre of attention.

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!