Less baffling jargon: The pros and cons of AMP
I rarely write responses to other posts and usually leave comments or reach out to the author directly instead, but I was positively surprised by Dan Fabulich’s “How to Replace Google’s AMP Without Slowing It Down”. It’s a thoughtful, constructive piece with some good ideas that I’d like to discuss further.
Pre-rendering isn’t the only unique selling point for AMP
Dan’s explanation of pre-rendering, and the issue around privacy, is pretty spot on. And I’m very hopeful about a future where Web Packaging can replace it, and solve many of the current UI issues (URL, scrolling, URL bar) that are unfortunate side effects of the current implementation.
What’s interesting is the sole focus on load time performance. Fast loading pages are great, but what if they load fast, but interacting with them is a nightmare? If you’re reading this, then you’ve dealt with unresponsive buttons and janky scroll, newsletter capture modals that fly in your face out of nowhere and paragraphs that suddenly change position after you started reading.
Embeddability, e.g. the document participating in swiping the carousel (by coordinating touch events with the parent), and most importantly the ‘run time’ user experience, e.g. interacting with content when it’s been loaded, are infinitely harder problems to control and solve for in a standards way, and a huge reason AMP exists.
Baffling Jargon: Canonical, Metadata and the Origin Model
Dan argues that my explanation at Why AMP Caches exist is a bunch of baffling jargon, and not clear at all. While I’ve received a lot of positive feedback for it back then, I agree with his basic premise. Especially the term “canonical” is super confusing, and in our own communications we’ve replaced terms like “canonical AMP” with “AMP as your website” (still not perfect, but better).
His proposal for a reworded statement:
AMP has some real problems, but for some sites, the performance benefits outweigh the costs. On AMP pages, the URL isn’t right, and the scrolling feels unnatural. But our #1 goal for AMP is performance, and there’s no way for us to fix AMP’s major problems today without compromising on performance or on your privacy.
We’re working on web standards that will fix these issues, but new standards will take years to arrive, if they arrive at all. We’ll do everything we can in the short term to make AMP sites as pleasant to use as possible, and leave it up to publishers to decide whether AMP’s problems are worse than the performance benefits.
I think this is close! I’ll change it slightly, but here’s my version (changes boldened):
Update (1/3/2018): Yehuda Katz made an excellent point about the fact that the URL is of course also part of the UX. I reworded this slightly to make it clear that AMP tries to aim for the best overall user experience possible, and that we can currently only to this by comprising on one part of the UX (the URL).
AMP has some real problems, but for most sites, the user & developer experience benefits outweigh the costs. On AMP pages served through the Google AMP Viewer, the URL isn’t right [deleted, because fixed:, and the scrolling feels unnatural]. But our #1 goal for AMP is an overall excellent user experience, and there’s no way for us to fix AMP’s problems today without compromising on other parts of the user experience or on your privacy.
We’re working on web standards that will fix these issues, but new standards will take a while to arrive across all browsers, if they arrive at all. We’ll do everything we can in the short term to make AMP sites as pleasant to use as possible, and leave it up to publishers to decide whether AMP’s problems are worse than the performance benefits.
Branding the future
Dan says that “despite cries that Google is trying to subvert the open web, the result could be a more open web, a web open to copying, sharing, and archiving websites.” It probably doesn’t come as surprise that I agree.
Where I don’t agree is that the AMP brand is “toxic” now (oh SNAP!). I’m incredibly proud of what we’ve achieved to date in the name of a better user experience for everyone, and while I’ll readily acknowledge our shortcomings both in implementation and communication, I believe AMP needed to be created, and needs to exist to push the web forward.
Is AMP the end goal? Absolutely not, if you ask me. I’m as excited as the Chrome team dreaming about a future where we have all future web standards in place to allow everyone, independent of library or framework, stay on the fast, user-friendly path (watch out for a post by Malte in the next few days detailing what we and Google are doing in this space). This is a future where AMP becomes just one of many web components libraries, and the only reason folks keep using it is because they like the ease of development and components AMP provides.
And then I’ll smile when I hear developers say “remember when only AMP could do pre-rendering? Ugh, so glad it’s straightforward to build great UX on the web platform now”, comparing it to the many times devs have said the same stuff about other now-dismissed tech, all while being blissfully unaware about the progress and ripple effect they have caused. And I’ll be OK.
