My Journey Building AMP Websites in WordPress

Editor’s Note: the following guest post was written by Daniel Bisett, Owner/Developer, Austintatious Design.

I’ve been building websites since the days of Telnet, back in 1996. Initially, I used straight HTML and eventually CSS entered the playing field. Websites back then were very simple, they didn’t even have images in the very beginning. As you may recall, page load time was often measured in minutes depending on the bells and whistles and the modem connection speed. We all seemed to have the patience of gods. 

As internet connectivity has improved and mobile phone usage has increased, we’ve lost our willingness to wait. Some say our attention span is now shorter than a goldfish, and for slow loading pages, that is terrible news. Google worked diligently to figure out what makes a website work. Eventually they compiled their learnings into a list of best-practice techniques and came out with a method of building websites then called the Accelerated Mobile Pages project, otherwise known as AMP.

Using AMP in Client Content and Ad Strategies

When I started building sites in mid-2016, AMP wasn’t necessarily a replacement to a website, it was an addition to an already existing website; a much better, faster, higher-performing mobile version. Even big businesses with “perfectly good” desktop websites could still benefit from AMP for their mobile visitors. To me, this meant that there was lots of potential for work! Beyond client opportunities available for building AMP websites, it also became clear that harnessing AMP could significantly impact the content strategies of my current clients.

Web content needs to be engaging and meaningful to my clients’ leads. If the leads have to wait too long, the chances of reaching them before they bounce become slimmer and slimmer. The “first-touch” content must load fast to avoid loosing users. By delivering highly relevant content at consistently good speed, those same leads were far more likely to find the solution to their pain point. Once they identified that they’d discovered the right place, they’d be far more likely to access more and more content. Each additional touch point would create a stronger and stronger bond between the lead and my client. Because the content was built using AMP, it loaded almost instantly from the search result page. The more they read, watch, view and engage, the more likely they will build trust in my clients. That trust directly relates to the successful closing of deals over time. 

Similarly, I saw that if the landing pages associated with paid ad campaigns were built on AMP, and therefore loaded almost instantly after the ad was clicked, users would be far more likely to engage with them. The landing page experience would be much better and the overall Ad Quality Score would improve significantly. Thus, not only would my clients’ ads CPC (Cost Per Click) be reduced (higher Quality Score = cheaper to run), but the visitor experience would also be vastly improved. To wit, less than 4 weeks after rebuilding one of my client’s landing pages using AMP as an experiment, that paid ad led to their first multi-million dollar contract. 

Full AMP Websites and Early Challenges

After playing with AMP for several months I realized that AMP could be a full-blown replacement for a website. It didn’t just have to be the mobile version, it could be the only version. I started experimenting with ways to fully harness AMP for entire sites in WordPress. But AMP in WordPress was limited at the time and the only option was to provide AMP content only for posts not pages. I tackled the challenges in the following way.

Step 1: The Library 

At first, I built a special blog post that harnessed the Advanced Custom Fields plugin. I called this blog post the “Archive” or “Library” sometimes. The “Library” had extra fields that emulated what a traditional main blog page would provide: 

● Featured Image 

● Title

● Excerpt

● Author 

● Publication Date

●  Link to “Read More” (to access the full blog post), etc. 

These custom fields were filled out manually each time a new blog post was published. But, because it was a post the plugin would do its magic and make it AMP-valid (at this time, the plugin only converted posts not pages). It was THIS “Library” post that was linked to from the static web site navigation menu. 

Step 2: Modifying the Plugin 

However, the struggle didn’t end there. I  had to also dissect the AMP plugin’s posts to make them compliant and consistent in UI/UX with the rest of the website. I would edit the individual single.php, style.css and several other files to get the look and feel to render correctly. Then I also had to build in the navigation system because this was not originally included in the first iterations of the AMP plugin either. But, because all of the menu items were static, this was also, relatively speaking, easy. And, voici, a fully functional 100% AMP-valid website. 

Unintended Consequences: Plugin Updates & Google Indexing 

But there were unintended consequences. First and foremost, when the plugin was updated, all of my changes were stripped! I had to return to each of the websites I built using this method and rebuild the plugin files after every update. A further unanticipated issue was that the first iteration or two of the plugin didn’t provide the Native setting. For those early days, my clients’ posts were getting indexed twice. While AMP versions of  the posts were rebuilt to emulate the rest of the website in layout and design, I did not, initially, pay any attention to the non-AMP versions. Desktop visitors were being sent (from Google) to those non-AMP posts and getting really, really confused. What’s more, because the menu items in the AMP posts were hard-coded, the menu items in the non-AMP posts weren’t connected at all to the rest of the static website. It was a minefield of struggles. 

Temporary Fix: .htaccess 

I then had to write some .htaccess rewrites to deal with the non-AMP blog posts to point them to the AMP ones so anyone discovering the desktop version in a Google search result would be redirected to the AMP version. 

A New Game Changer Enters

Then, around August of 2018, I discovered that Google was spearheading the effort to improve the AMP plugin and things started changing dramatically! The plugin supported all content types, not just posts, as well as responsive menus, and it provided mechanisms for developers (like me) to make modifications (child-theme style). The plugin made it all work!!! 

From that point on, I stopped my “Frankenstein” approach to building websites using the mostly static AMP site (as described above). I built 100% AMP-valid fully functional WordPress themes that harnessed the full CMS functionality/ opportunity that WordPress provides its developers. Sure, there were still improvements to be made, but the new versions of the plugin were a total game changer. There are now many more themes that are built to be compatible with the AMP plugin.  However, from my experience, several of these themes do not render ‘identically’ in the Native (Standard mode) format, so I will be hand-building my own themes for the foreseeable future. That said, we did use Twenty-Twenty with an in-house child-theme with great success. So if you’re not yet ready to tackle a full WordPress theme from the ground-up, building with a child theme is a totally workable solution! 

Together using CSS-Grid for layouts, PostCSS for speed, my WordPress websites rely on only three plugins to be fully functional and beautiful: AMP plugin, Custom Post Types UI, and Advanced Custom Fields Pro. And additionally Yoast SEO for SEO, and WordFence for site security. Instead of relying on 10, 15, 30 plugins which many of these WP themes out there do, mine typically use only 5. My websites routinely score very high in Google Lighthouse results as well as GTMetrix, and Webpagetest.org. 

Ease-of-Use and Build Time Impact 

When I first started building AMP websites, my build time was often in the 120 hours range for a new site from scratch. I had to consider and include all aspects of AMP: HTML, CSS, scripts.  I also had to build out every aspect of the site intentionally. It was not only time consuming, it was somewhat painstaking because there was a lot to remember. And one mishap meant no AMP validity. Perhaps the most challenging aspect of building AMP websites was the CSS limitations. These took WordPress out of the picture entirely. That is, until the AMP plugin came into the picture. With the plugin, several major things happened: 

The Tree Shaker

CSS Tree Shaking automatically removes all unused CSS. Prior to this, I had to use third-party tools to compare every individual page on a site to the CSS built into the page. The tool would find all styles that were not required for that page and remove them. It then provided me a file with only the CSS that the page needed. But this method had flaws. Often, it would strip styles that were not required in the desktop view, but WERE required for the mobile view. It would also not strip out CSS that was mentioned (by class, id or otherwise), so my files would still end up with a ton of bloat. The AMP plugin’s tree shaking mechanism does this flawlessly and quickly! 

HTML Conversion to AMP HTML 

The plugin also converts html tags that are not allowed to their AMP HTML equivalents. For example, instead of writing an <amp-img> tag in my code, having to include width and height dimensions (or aspect ratios), taking advantage of the plugin I can just write:

<img src="xxx.jpg" layout="responsive"> Code language: HTML, XML (xml)

and the plugin will convert that to:

<amp-img src="xxx.jpg" width="100" height="100" layout="responsive"></amp-img> Code language: HTML, XML (xml)

This kind of automation in the generation of AMP markup is one of the mechanisms the AMP plugin provides to make AMP content publishing in WordPress very easy.

AMP Scripts Done Right 

Another element the plugin handles automatically is the addition of scripts associated with any AMP components used on a page.  For example, if I use an <amp-carousel> component, I don’t have to worry about including the corresponding script in the <head> of the document. The plugin adds it automatically. And the plugin also checks all of the html in the site for errors, correcting the ones that can be corrected automatically, and reporting those that cannot.  

Time savings: from 120 to 30 Hours 

My clients are seeing drastic improvements in their lead generation. While AMP is not responsible for closing the deal, it has played a major role in creating a fast and engaging opportunity for their leads to then build trust with their companies and moving from consideration to conversion.

With the latest developments in the official AMP plugin for WordPress, I can focus on building the user experience my clients are looking for without having to do much of the heavy lifting, leaving the bulk of that work to the plugin itself. So long as I keep the AMP restrictions in mind and with a little help from the AMP plugin, my websites stay fully AMP effortlessly.

Looking at my invoices, I have shifted from build hours averaging in the 120 hours/site to around 30 hours/site. This is not to say that the AMP plugin is solely responsible for the improved timeframe, but it has played a major role! My latest build is 100% AMP-valid, scores 95 for Performance in Google’s Lighthouse, and has taken 32 hours to build from scratch. As my grandfather used to say, “That ain’t nothin”! 

About the Author