In October, Google’s open source AMP project (Accelerated Mobile Pages) will be heading into its third year. The initiative aims to improve performance on the mobile web and currently boasts usage on 25 million domains across publishing, advertising, e-commerce, and business websites.
WordPress had a rocky beginning with its official AMP plugin, which was originally developed by Automattic, one of the earliest publishing partners on the project. The first versions of the plugin were not easy to use, especially for heavily customized installations. It required site owners to invest considerable effort into optimizing AMP pages and fine tuning them for their needs. AMP for WordPress went without updates for 10 months in 2017, was fraught with errors, and incompatible with many other plugins.
XWP began leading development of the plugin last year in partnership with Google, beginning with the 0.6 release. Weston Ruter is the tech lead with several XWP engineers contributing to development, design, and testing. Alberto Medina, Developer Advocate at Google, and his team have been leading the product management and outreach efforts.
“Around May last year, my team at Google started a long-term effort with a bigger scope than just AMP, which included significantly investing engineering resources on the development of the plugin,” Medina said. “We started investing development resources, and then teamed up with XWP to expand the engineering scope. During this phase of the project Google and XWP have driven all the execution of the project and the development efforts.”
Ruter said his team went through six months of the plugin’s support topics on WordPress.org and categorized them to figure out what issues users were struggling with most. They used that information to guide the focus for their first release and have been keeping a pulse on the support forum ever since.
The plugin has incorporated many changes since XWP began spearheading its development, putting AMP’s newer features to use within the context of WordPress. Earlier versions of the plugin only allowed posts to be served as AMP but the 0.6 release added pages to its capabilities. Version 0.7 introduced the ability for all URLS on a site to served as AMP (“Native AMP”) but lacked the ability for users to customize which types of content should be excluded from this format. The upcoming 1.0 release will allow users to have a native AMP site that excludes certain templates, such as a shopping cart or a category archive, from being served as AMP.
“AMP initially was limited in functionality,” Ruter said. “The AMP plugin was created when AMP was young. In the beginning it was focused on Accelerated Mobile Pages and it wasn’t able to recreate full responsive experiences that site owners expect. This has changed and AMP is able to do a lot. So that is what we have been focused on with the AMP plugin, is to bring it up to speed with the AMP project itself so that WordPress sites can take advantage of all the features and functionality that are now available.”
The team at XWP is aiming to release version 1.0 of AMP for WordPress in mid-September. The 1.0 alpha release introduced extended AMP theme support with a more user-oriented approach to the settings. Previous versions of the plugin were more developer-centric, requiring edits to a theme or child theme to configure template support. Users can now enable Native AMP or Paired mode on the AMP settings screen and the beta release adds granular controls for selecting supported templates.
Other notable updates in the alpha and beta releases include:
- Enhanced UI for handling AMP validation errors
- Expanded Gutenberg support to surface AMP validation errors at a block level
- Addition of AMP-specific functionality to core blocks
- Redirection to non-AMP URL when unaccepted validation errors present
- Beta brings back WP Admin Bar AMP menu with AMP error highlighting
AMP for WordPress v1.0-beta2 was released in August and is not yet ready for production use. The good news for those who want to use AMP is that the plugin is becoming more of a plug-and-play solution as development progresses.
“There is only one setting that the user needs to change to take advantage of the new theme support: switching from legacy to paired or native,” Ruter said. “Everything else is optional and just customizes the behavior. There will be a new admin pointer in 1.0 that will call out this updated admin screen.”
Ruter also said his team is considering implementing a wizard-type experience to minimize the number of tweaks users need to make. They are discussing automating the compatibility check of the various templates prior to enabling theme support so users can get a high level view of the areas of the site that would be best-suited for AMP.
AMP Remains a Controversial Solution to Web Page Performance
Many users encountered insurmountable difficulties in their first attempts at using the AMP plugin with highly customized sites, relegating AMP usage to sites with dedicated engineering teams. Early versions of the AMP project did not have the flexibility that many publishers required.
Brian Boyer, VP of Product and People at Spirited Media, home of The Incline, Billy Penn, and Denverite publications, gave a presentation at WordCamp for Publishers titled “Why we ditched AMP, and other UX choices we made for launching membership.”
“We need more control over our user experience than AMP allows – to build an unshitty, persuasive, native feeling, highly effective membership experience, I need a little more JavaScript,” Boyer said. “I need a little bit more control over the page and to be fair, we could probably make some of this stuff but we cannot afford to design, build, and most crucially, test multiple versions of our website.”
Boyer cited the expense of of building and testing multiple codebases as one of the primary reasons his team ditched AMP. The complication of maintaining a second user experience was “far too much to ask” for his development team, who had already produced a fast, lightweight WordPress setup with proper caching.
“An AMP page might load a little faster but our other needs far outweigh that minor performance improvement,” Boyer said. “We got over our FOMP (Fear of Missing Pageviews). If I can be better at making conversions, I’ll take the hit with pageviews.”
Recent Enhancements to the AMP project and the plugin, including the addition of components allowing for the creation of rich interactive experiences, continue to narrow the gap between the custom JavaScript many websites require and AMP’s limitations. This may be encouraging for those who have chosen to embrace AMP, but ultimately will not make a difference for those who fundamentally oppose the initiative as an affront to the open web.
Beyond the technical investment in fine-tuning an AMP setup to meet the needs of his publications, Boyer concluded the presentation by outlining his broader objections to the AMP project:
By policing slow websites, Google has turned the big publishers’ problem into my problem, but that fix comes at a high cost to me, a small publisher,” Boyer said. “AMP is not the Open Web – it’s a short term fix for bad choices. If you build a slow and terrible website that supports a creepy business model, like tracking the shit out of your users, then yes, AMP is one path to a better user experience. It is an escape hatch from your legacy code and the bad choices of your predecessors. I understand why that would be tempting, but it is also a deal with the devil. AMP and its cousin Instant Articles put even more control in the hands of companies that already have too much control, and I for one cannot abide by that. I just ask you, do the work, fix your websites, make them fast, friendly, and respectful.
Other vocal critics are not comfortable with how Google is positioning AMP as a long-term solution, instead of addressing the root issues of web page performance. Jeremy Keith articulated this stance in his article titled “AMPstinction.”
“If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it,” Keith said. “But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
“Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandants delivered to us from on-high by one organization, enforced by preferential treatment by that organization’s monopoly in search.”
However, decoupling AMP from Google’s influence would also mean separating the project from the leadership and resources that have so far driven its adoption across millions of websites. There may be other approaches to addressing performance but Alberto Medina and his team see AMP as serving a practical purpose for users and developers who wouldn’t otherwise be capable of optimizing their sites to the same degree. What he described is in a sense “democratizing performance.”
“The root causes of web performance problems are well known and there are tools, techniques, and web APIs, that allow developers to achieve awesome UX close to what AMP provides,” Medina said. “However, the reality is that doing so is very hard for most developers. Usually achieving it requires having solid engineering teams and enough financial resources. That is not fair for most developers and organizations that do not have the resources.”
Medina sees AMP as an answer to what he describes as the Capability/Usage gap: the difference between what can be achieved in the web and what is actually done in the web.
“The problem is that as the power and complexity of the web increases, that gap has increased as well,” Medina said. “The problem is that as long as that gap exists, achieving the best UX is not possible. So, the goal is to close that gap. There are two options: developers do the right thing all the time, or we provide tooling/libraries that enable them to do the right thing in an easy and effective way. AMP served the latter purpose.”
Medina also emphasized that AMP is fully built on open web technologies. “Basically, it provides what developers could do by themselves but it is hard to do,” he said.
In a recent Recode Decode podcast interview with Kara Swisher, Matt Mullenweg also weighed in on the AMP project.
“It gets a bad rap because Google kind of botched the rollout a little bit,” Mullenweg said. “The underlying tech is open source and it’s actually quite good. Because for you as an independent publisher to have a future, we need you to load just as fast as something that’s embedded in an app. Facebook has done the bait and switch so many times that we need an independent alternative and I think AMP can be that.”
Google’s investment in the AMP plugin through its partnership with Automattic and XWP has made AMP more approachable for the average user, especially with the updates coming in version 1.0. Medina said Google chose to collaborate with WordPress because they share a similar goal of providing a better user experience for the platform.
“AMP is not an end goal in itself; the real objective is enabling all WordPress developers and site owners to provide awesome user experiences powered by WordPress,” Medina said. “AMP is just a component in that overall story, together with PWA capabilities, coding and performance best practices, Tide, etc.” In architecting the latest version of the plugin, Medina said the team is aiming to “enable native AMP experiences in WordPress without compromising content fidelity or surrendering the flexibility of the WordPress platform.”
Whatever your opinion of the AMP project, the user-friendly theme support options and better validation error handling are game changing improvements for the WordPress plugin. It is currently active on more than 300,000 sites. Updates coming in the 1.0 release will enable thousands of WordPress users to have a more successful experience with AMP.
Yes, this is a concern. And this is the key advantage of going the “Native AMP” route. By not using the paired mode—where there are separate AMP-specific URLs and even entirely separate templates—you only have to maintain one single codebase. You can just rely on AMP’s own web components, like
amp-carouselinstead of also having to find something equivalent with some jQuery carousel plugin, for example. You can also just useamp-bindfor developing interactive experiences where otherwise you would have to use custom JavaScript.Nevertheless, the plugin’s new paired mode is able to fully re-use your active theme’s templates and styles. Since the AMP plugin does not allow any custom JavaScript, then the default behavior in this new paired mode is just as if JavaScript is disabled in the browser. So as long as you account for the “no script” users, then your site in paired mode will gracefully degrade even without porting your site’s custom JavaScript to using the equivalent AMP components.