AMP: Hope and Fears (Part 1)
This essay has evolved from my notes and comments from the AMP Roadshow in Sunnyvale on April 4 and feedback received since. Any factual errors are mine. Feedback is always welcome.
The questions/issues I have are in bold throughout the rest of the article.
at the #amproadshow learning about AMP, what's next and what cool things you can do with it.
— Carlos Araya (@elrond25) April 4, 2018
I'm ambivalent about AMP and am hoping to be convinced otherwise
What problem is AMP trying to solve? #
Particularly since the introduction of AMP stories and the loosening JavaScript restrictions on adding JavaScript to AMP content, it's starting to look just like another optimized library to create web content and, furthermore, the AMP cache is starting to look more and more like the old m-dot mobile sites of yesterday. When using an AMP cache link on a desktop machine I've been redirected to the desktop version of the site and not given access to the AMP version; my expectation is that links to the cache will point me towards the AMP version of the content regardless of what form factor I'm using to access it.
So it begs the question:
Beyond performance, what else are we trying to solve with it?
User experience #
One of the things that bother me is that AMP looks like it wants to replace most other web technologies that try to improve the user experience.
This is part of a more general question why Google competes with itself in so many different categories? In the web space is AMP trying to provide a single solution that will work instead of existing web properties like Polymer and Angular?
So, it begs the first question in this category.
If this is for best users experiences why not support technologies that enhance what's already there instead of creating something new?
It may be true that this wouldn't solve the bloat problem of the web as it is today, but I don't think that being overly restrictive is a good solution either. AMP proposes a solution now and, to be honest, I can't think of a better.
The AMP team acts as gatekeepers for what is and isn't part of the AMP stack and platform. My problem, for example, is that I can't run the Prism syntax highlighter into AMP code (mine is generated by WordPress' wp-amp plugin compiled from source). It works under normal circumstances when used with non-AMP content so why should AMP content be any different? It may be true that I need to enable asynchronous highlighting on the Prism side of the equation but not because it's a requirement to use a library.
As an aside, Prism does support asynchronous highlighting via workers, just not by default. According to the Prism documentation:
Why is asynchronous highlighting disabled by default? Web Workers are good for preventing syntax highlighting of really large code blocks from blocking the main UI thread. In most cases, you will want to highlight reasonably sized chunks of code, and this will not be needed. Furthermore, using Web Workers is actually slower than synchronously highlighting, due to the overhead of creating and terminating the Worker. It just appears faster in these cases because it doesn't block the main thread. In addition, since Web Workers operate on files instead of objects, plugins that hook on core parts of Prism (e.g. modify language definitions) will not work unless included in the same file (using the builder in the Download page will protect you from this pitfall). Lastly, Web Workers cannot interact with the DOM and most other APIs (e.g. the console), so they are notoriously hard to debug. From the Prism FAQ
Since we can't use JavaScript on AMP content, how can we leverage web APIs without being forced to use AMP supported wrappers? I understand that you're working on relaxing the restriction of using JavaScript in AMP content and experimenting with using workers to offload running scripts (amp-script) but, right now, I can't use any APIs that the AMP team doesn't allow. Some of my issues in this area:
- If we need AMP sanctioned wrappers for scripted and interactive content, How many wrappers will we need to address users' content cases?
- How many proposed wrappers are approved. My own experience with filling an issue on Syntax highlighting leaves me somewhat less than hopeful in that area (issue 14425 in the AMP repository, for completeness sake)
All JavaScript APIs require some sort of launch script or a link inside the page that is using it... neither of which is allowed in AMP by default. If we pick features like service workers we have the initialization script (replaced with AMP's amp-install-serviceworker, and most other examples should be covered by using amp-iframe and amp-bind but only if you choose to work with iframes in your pages and learn the AMP way of doing things.
If we move to talk about CSS features, they fall under another restriction in the AMP platform. They don't apply here.
Until the AMP team relaxes the restrictions for scripts on AMP content the AMP library itself will not accept scripts other than the ones they whitelist, so whenever you need a script that is not approved by AMP the page will still work but it will lose all benefits from AMP.
In my case with my code highlighter, I still get something that looks different enough from my content to be distinguishable from prose but not what I expected as syntax highlighted code.
I guess I could pre-process the content and insert the elements I need before the content is loaded but doesn't that defeat the purpose? If we move everything to the server and pre-process, server-side render the content and preload it, aren't we inviting the same types of bottlenecks and potential rendering delays because of user's network connectivity?
Where to go if there's a problem? #
Until better debugging tooling is available it's very hard to do good AMP development. Given all the restrictions of what you can't do and how you should do what you can, it's hard to remember that your primary debugging tools for AMP are the browser's Dev Tools and the Google Search Console for your site, assuming that you're after SEO and Google SERP preloading, and while they are good tools they are not what most people use to debug HTML.
Most people won't bother to check the search console to see if there is a problem with search and AMP or know how to fix it so having AMP working is not guarantee that the tool is working properly, or at all...
I had a problem with linked data being incorrect, The AMP validator did not check for correct syntax in the JSON-LD content, so I got no validation errors and only found out that there was a problem (and that it had been fixed) when I went to the Google Search Console looking for something else.
AMP is different from most tools out there. If we misconfigure a script we expect it to fail. However, if we miss a tag or misquote an attribute in HTML the expectation, right or wrong, is that the page, up to the point where the error happened, will still render. With AMP I'm not certain this is the case, at least it wasn't my experience.
So whose responsibility is it? Mine? The plugin developer? The AMP team?
I also don't know if AMP Validation Errors will cause the page not to render or if these are warnings of things that must be fixed to be compliant. Furthermore, will any errors render the page non-AMP-compliant and, therefore, unable to benefit from the AMP ecosystem?
Garbage in, Garbage out #
I host my own installation of Wordpress so this is less of an issue for me. But for the people who host content in Wordppress.com this may come in as a surprise: AMP is enabled by default! (see AMP (Accelerated Mobile Pages) in the Wordpress.com support site).
Twitter is also sending users to AMP version of the content (when available) by default. Shouldn't this be an opt-in experience rather than opt-out or no choice at all?
This is less of an issue for Twitter and self-hosted versions of Wordpress than it is for Wordpres.com hosted blogs because in the earlier cases, it's a conscious action to link to an AMP resource or install and activate the plugin. In Wordpress.com it's a setting enabled by default so it'll publish AMP until you, the content creator, disable it. This means that Wordpress.com authors may not be aware that they are publishing AMP for their blog.
This is not a problem for the AMP team but, in my opinion, will reflect poorly on AMP the platform because if we get low-quality content pushed into AMP nobody wins.
Duplicating effort? #
When AMP first came out as an optimization library I had my reservations but saw it as an interim solution to the mobile performance issues that I see documented everywhere and that has gotten progressively worse.
When I first saw AMP, I saw it sold as a performance improvement for mobile load times. It may not be the purpose behind the project but that's how most people see it.
But even if the assumption that AMP is all about mobile performance (and, according to the AMP team, it is not) that is changing in ways that I wasn't expecting.
The concept of stories at least according to the news I've read out there throws the concept of non-AMP sites out the window. If there is no equivalency check, what will search engines do when the content is different? Which version of the content will get priority?
According to Search Engine Land:
Breaking with previous guidance, Google does not intend for this type of AMP content to match your non-mobile content. Instead, this mobile-only content should be unique. I followed up on this point with a Google rep, who characterized AMP Story content this way:
AMP stories is all about encouraging new forms of expression and storytelling, so we expect most publishers to not be already publishing this kind of content out on the web currently. AMP stories is meant to facilitate this and make it easier.
The rep also added that “AMP Story content should be fulfilling and standalone.” Because Google has historically argued specifically against creating different content for different users, this new “separate but equal” stance surprised me. Google further explained:
This does not run counter to the idea that the publisher may also have separate expressions [of] similar content published. Say a publisher has a long-form analysis article about college admissions data. Then, say they have a companion piece that’s an interactive experience letting people play with the data through charts and other visualizations. It wouldn’t be correct to call the long-form piece the canonical for the interactive. They each stand on their own, although being related.
This bothers me in so many levels but I'll start with the most basic concern and fear: Are we turning the mobile web into a single-vendor experience? Will this difference between stories and web content force publishers into AMP or be left behind by not providing good results on the search page? what happens if the search engine doesn't support canonical URLs like Google does?
AMP like many major projects like Angular, React, Bootstrap and Polymer are Open Source projects but the company that originally released the software maintains a certain level of control either in the decision making process or in vetting changes to the codebase
How about leveraging other parts of the web platform to tell the same type of stories you do with AMP? Again, isn't improving the whole web experience the name of the game? Having looked deeper at the stack AMP uses I can see a lot of good practices and things we should all be doing to improve users' experience with our web content. Creating a brand-new product that hides all the best practices under a set of restrictions and custom elements may not be the way to provide the interim solution that will work and teach the best practices that people, particularly beginners, need to learn.