Remember m-dot sites? You know, the ones where you would design and build a whole separate site for your mobile visitors and serve it under a subdomain (e.g. https://m.xwp.co). Two sites; one for desktop visitors and one for mobile visitors. Sure, in a world getting its feet wet with mobile devices, this got the ball rolling for better mobile experiences. However, it certainly didn’t represent DRY development. Now we can be thankful for modern responsive design and development. Single sites that deliver content to all screen sizes.
The technology evolved to serve the changing needs of the market.
Almost 3 years ago, Google announced the open source Accelerated Mobile Pages project (AMP). A clearly defined set of development practices that, when adhered to, produce a highly performant experience for site visitors. Through a clever layer of caching, Google began both encouraging and facilitating the adoption of AMP, with a natural focus on the publishing industry.
The experience of AMP these past few years, particularly with WordPress, has been like those olde m-dot sites. You would have your regular site and your AMP site. Sometimes called Paired Mode, AMP WordPress plugins have let users set up an AMP version of their site that delivered AMP compatible content, under the right circumstances, to users with the standard non-AMP site ready in the background to fill in the gaps.
There have been a few problems with this.
- Like with m-dot sites, 2 sites needed to be maintained.
- The upside of AMP was only available for certain content types under certain circumstances.
AMP is designed to offer an optimized performance experience for end users, achieved through strict adherence to a set of coding and performance best practices. The upside of AMP, blazing fast performance, isn’t something site owners just want for a select few pages for select mobile visitors. They, we, want that for the whole site!
A single site, built on AMP, for all device types and all visitors. Blazing fast across the board. Yes, please!
This is what Native AMP is.
Native AMP is the application of AMP across a whole site. This has been technically possible for some time, but only recently have we (web developers) been able to both work with AMP as well as adhere to the unique frontend styles of our brand. Additionally, AMP now provides several components that allow us to create the rich interactive experiences that we otherwise would typically have to build using custom JavaScript. When custom scripting is required, there is amp-bind which provides an increasingly-familiar way of creating state-managed reactive interfaces. The gap between what can be done with AMP and what web developers would like to do is reduced to the point that the upside of AMP performance often offsets any lost functionality.
The follow-up question, I hear coming from the developers, is
“That’s great, but are we going to have to refactor our entire WordPress theme to bring it inline with AMP standards?”
Nope!
V1.0 (currently in beta) of the AMP WordPress plugin does something special. It includes a post-processor that converts a theme’s templates and stylesheets into AMP-compatible templates.
In principle, it’s (almost) plug and play. If you enable AMP and do nothing else, the baseline experience is as if the user has visited your site with JavaScript turned off; so if you have no-JS fallbacks then these are served in AMP. Practically, there will need to be a few tweaks and changes, but the barrier to a site achieving AMP compatibility and realizing the serious performance gains has been significantly lowered.
One of our team architects Thierry, alongside Alberto Medina from Google, has given a couple of fantastic presentations at AMPConf and at WordCamp Europe in recent months, demonstrating these capabilities.
Native AMP, the ability to build an entire site in AMP, is now possible and offers site owners a fantastic path to better performance. Evidence? This site is Native AMP. We’re writing up what the experience was like of taking a theme that wasn’t initially built to be AMP compatible and how through working with the plugin and some minor fixes we were able to get up and running on AMP within about 10 hours of dev time.
The documentation for AMP is here, and the documentation for the WordPress plugin is here.
We’ve been working with Google and Automattic on this plugin for several months, and if you have questions, feedback, or need further direction, please don’t hesitate to reach out.
