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:
- 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.
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.
Anil Dash recently listed how it’s “essential to believe that there is good intention underlying most tech efforts if we’re going to effectively hold everyone accountable for the tech they create”.
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.)
That demand is partly driven by by a whopping 3 MB per mobile page view which can translate into as little as 15 page views per $1 spent on data.
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 “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.
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.
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!
Silence… Lights back on the stage… A clap in the audience… Then two… The clap thunder begin… Turns into a 10 minutes standing ovation!
Thanks a thousand times for sharing your thoughts about all this. I feel like I’ve found the map of a the maze I’m actually in… I’m not out of it yet, for sure, but I see where it could lead. Again : Bravo.
Glad you find it useful, Romain! If you’d like to continue the journey, these two may be even more important:
📄How GDPR Will Change The Way You Develop
📄Using Ethics In Web Design
Wow. What an amazingly thorough and well-written piece. Thank you.
Just wanted to add that AMP is not just for static content anymore, though it certainly started out that way. Now with its component library including things like amp-list and amp-bind, you can build dynamic experiences with AMP. And as was announced at AMP Conf this year, experimental work is underway to allow custom JavaScript to run safely and securely in AMP by means of Web Workers.
So going with AMP in WordPress doesn’t necessitate you settle for the ubiquitous and basic single post template with a simple blue header. Building with AMP doesn’t mean you have to sacrifice interactive dynamic experiences. It just means you have to do them in the AMP way. Additionally, there are patterns now for combining AMP with PWAs to make even more interactive experiences which previously were extremely difficult: if all content is served as AMP then it can be safely embedded and replaced in a single page application without worrying about some rogue JavaScript throwing a wrench into everything. I’m excited about the possibilities that open up when we have the more constrained and well-behaving foundation that AMP provides.
Thanks, Weston, appreciate the corrections and extra context! Updated accordingly. 🙌
AMP would remove the birds from this post. Right? LOL!
Very thought provoking article – thank you!
It wouldn’t. 😉
Glad you liked it!
Hi Caspar, thanks for the thoughtful post. I’m one of those critics of AMP (and keep being it), but it’s good to see the other point of view explained like it’s here.
I think the main conflict here is a matter of timing and strategy. Everyone admits the base problem, the terrible speed of most of the sites, the problem that WP plugins/themes devs have caused and the need to find a solution.
While I think we should educate devs, we must defend standards and keep insisting on speed and best practices, Google has decided to go for the “you’ll appear in this visible carousel at the top of the search results page” instead. And while Google is almost a monopoly in the search world, if they take the decisions (yes, it’s open source, but same open source as Matt saying we’re going to have Gutenberg in the next release) we’re going to be always depending on what the people there decide. And we can’t forget they’re a company looking for benefits and that they have a past of bad decisions for the users but good for their balances.
And probably people working there, they really really want an open web, they want AMP to become a standard, they want people from other companies to participate in the development. And maybe they even wish to fast-loading non-AMP pages to show up first in the results page because the final goal is to have an accessible web for everyone. But currently, it’s not what we see from the outside. And I think it’s important that the critics say things out loud because it’s a way to keep the AMP team paying attention and taking on responsibility for their work.
And maybe I’m wrong as you said you were in the past and I end up embracing it too. I assume that you make excellent points about people not caring, the donkey paradox and the scale of the problem and the other solutions. But it would be better for the project if we could trust that this is made mainly for the benefit of the open web and not just for the benefit of a big company fighting against Facebook (with a strategy that can change tomorrow).
Thanks for your thoughtful comment, Juan! I think you’re spot-on when you say that educating developers about performance is important, and that thorough critique on AMP must be voiced, and heard. The fact that AMP as a framework is being introduced by a quasi-monopoly like Google seems problematic indeed, and the team around AMP certainly is aware of how crucially important a constant feedback loop with the web community has been and will be in the future.
I’m also reading between your lines—correct me if I’m wrong—that you believe AMP shouldn’t be the only way of making fast (WordPress) websites in the future, and I wholeheartedly agree. For a person who is willing and able to use plain HTML and CSS responsibly, AMP probably won’t be necessary.
I’d even go so far to speculate if perhaps we’re witnessing something similar to the rise of jQuery years ago? Today, many developers prefer to write plain JavaScript over jQuery which usually reduces overhead and improves performance. However, a few years ago, jQuery was everywhere. For many WordPress theme developers it was the gateway to achieve rich user experiences with a lower learning curve than if they would have used plain JavaScript.
Similarly, AMP could function as a gateway to performance these days; until in a few years maybe, developers will have caught up and prefer to write plain HTML, CSS, and JavaScript again. Time will tell!
Wonderful essay. Bravo!
Thanks, Daniel, appreciate it!