What you need to know before you AMP

The AMP HTML framework continues to gain attention and the v1.0 release of the official WordPress plugin has made it even easier to implement AMP on WordPress. Even though the plugin provides the ability to just flick the switch, AMP implementation should be carefully planned for. For projects that we work on, there are a series of things that we consider and understand before we kick off any development.

The following is a summary of these things. If you’re looking at AMP, take note of these points and build them into your planning.

1. Understand your existing site performance and what could be reasonably achieved with AMP

Performance is as performance does. Benchmarking performance on the existing site and understanding:

  1. Where it sits as far as bad<—>good goes
  2. How much AMP could realistically move the needle

This will give you an idea of the gap you may be able to bridge with AMP and whether or not the investment is worth the potential return. I.e. moving from a 7 to a 9 performance score means something quite different than moving from a 3 to an 8.

If you’re looking for modern tools for assessing performance (amongst other things), we turn to:

Each of these tools provides agnostic metrics that you can use to track your performance trends over time. We recommend learning the nuances so you can master each of them.

2. Understand the different implementation types of AMP

With the AMP for WordPress plugin, there are 3 different modes for implementation. These are:

  1. Classic
  2. Paired
  3. Native

Each implementation has a different impact on the way your site will operate. Native and Paired modes use your theme’s templates and styling. They often look just like your non-AMP URLs. (Classic mode uses a template bundled with the plugin. Based on changes to SEO best practices and the lack of a “canonical” experience with Classic Mode, we don’t recommend you use Classic Mode.)

The value these 3 different modes bring varies and the choice between them can often be influenced by the technical limitations of how your site is set up. Understanding these will help frame your thinking as you move towards more technical discovery.

The AMP Modes & The WordPress Plugin section on this page cover these 3 modes in more detail. You can also read more over on the plugin’s documentation.

3. Audit asset optimization infrastructure (CDNs, Caching, etc) and define what could be removed and what could conflict with AMP

There are a thousand ways to skin a cache. Asset optimization takes many forms and their friendliness with AMP varies. Auditing what you have active on your current site means that when you move into testing AMP compliance, you’ll be better equipped to identify where issues (if there are any) come from and how to resolve them.

4. Understand performance-related revenue streams

This is different for every site. Revenue streams can come from:

  • Ad revenue: Both programmatic and manual
  • Subscriptions
  • Ecommerce
  • Affiliate and Sponsored Content

Review how page performance, and the resulting user experience, can influence conversion rates and technical implementations on these.

5. Audit current Ad-Tech implementations

AdTech implementations deserve their own point here as it varies greatly and is usually Javascript heavy. AMP offers AdTech-specific components for working with this, but the implementation can vary. Understanding your AdTech stack will help you:

  1. Determine how to implement the ads in AMP, like with amp-ad
  2. Help inform you on how you should go about testing AMP and its impact on ad revenue

6. Audit current Javascript

From tracking codes to frontend features, Javascript is everywhere. Knowing the what and how of it on your site will help you determine:

  1. What you can actually say goodbye to (you’ll be surprised how often we are able to remove JS from sites we work on without impacting functionality or integrations)
  2. What you can reimplement in AMP, like with amp-bind, amp-ad, or amp-analytics

Once you get to testing, the simplest first step is simply turn off JavaScript in the browser and get a sense of how your site functions without it.

7. Audit tracking/cookie implementations

This is part of the JavaScript step as well but can be considered on its own. Tracking snippets on websites are easily one of the biggest contributors to poor performance. We’ve seen many cases where turning off tracking, without doing anything else, has improved page performance by more than 50%.

However, tracking is an important component of modern website management. An audit of what you have though can help you determine:

  1. What could be safely removed from your AMP pages
  2. How to leverage existing components like amp-analytics, amp-bind, and amp-list

AMP have components available to help facilitate tracking. The Google Tag Manager service actually has AMP specific features to help implement tracking while maintaining AMP compatibility.

8. Audit the total amount of CSS on URLs. The plugin can remove unused CSS, but it can still exceed AMP’s maximum of 50KB.

One of the restrictions AMP places on a page is a maximum file size for CSS of 50KB. The AMP for WordPress plugin through a feature called tree-shaking reviews a page and produces a minimized file of only the required CSS. However, this feature doesn’t guarantee that the file size will be under the threshold. Reviewing key page templates, particularly for complex pages, will help you scope the project around the need to refactor CSS on the site.

9. Your current state of AMP compatibility

This actually falls into more of the discovery stage of a project but is actually something that can be done, at least at a high level, quite easily. S0 if you’re in the exploratory stage of looking at AMP, doing this can give you a serious head start.

The process basically involves working on a staging/testing/alt version of your site, installing the AMP WordPress plugin and using its features to identify validation errors.

The step-by-step for this can be found here.

10. Understand the Roadmap for AMP & the AMP Plugin for WordPress

Knowing what’s coming, even what’s just around the corner, can help inform your decision around an AMP implementation. A no-go factor about AMP or the plugin may actually be something that could be resolved in the near future. The Roadmap is public and can be easily reviewed over here.


These 10 points are what our teams move through when scoping an AMP implementation project. Considering, understanding, even implementing them yourself will mean you’re highly informed about AMP and its potential value for your website.

With Google, we’re the lead developers on the official AMP for WordPress plugin

If you want to know more about what AMP, or performance gains in general, can do for your website…

let’s talk.


An Introduction to Native AMP

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 ye 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?”


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.

P.s. 1.0-beta of the plugin ready now for testing.