Best WordPress Amp Optimization Techniques

If you are fed up about WordPress Amp optimization and finding the best solutions or methods of Amp Optimization on GOOGLE then you are at right place. Isn’t the whole point of AMP that it makes my pages fast? Well, yes, but there’s more to the story. Here’s how to make your AMP pages even faster. OK, it’s true, the AMP library is optimized for speed, and all valid AMP pages load fast. However, you can improve additional performance so that the browser loads AMP pages even faster. Many of these changes are minor and can improve loads without breaking the validity of AMP significantly. Before we jump in, let’s talk about AMP caches. You might have heard or read about the fact that AMP caches do a whole lot of these additional optimizations and that’s true in some cases, such as when AMP pages are surfaced in Google of Bing search results.

But there are other cases where they shift from the origin, for instance, when your canonical web pages are built with AMP, such as, or any other platforms without their own caches link to AMP pages on the origin. For example, Twitter started linking to AMP pages if available. If you click a link in one of your mobile apps on Twitter, you will be linked to the AMP version of your page on your own server.

These are scenarios where the AMP cash can help you with speedy delivery and further aggressive optimizations. Now, the optimizations we can do to an AMP page essentially fall into two categories, optimizations to asset and AMP library loading, and server-side rendering of AMP.

Browser Load AMP Faster

Let’s start with the low-hanging fruit to help the browser load AMP faster. The AMP library needs to be loaded for an AMP-specific element such as AMP Image or AMP Video to work. This means an AMP image will only start downloading an image once the AMP library has been loaded. This allows us to load AMP pages faster in two different ways. First, make sure you get the AMP library downloaded as quickly as you can. Second, tell your browser, before the AMP library is available, to begin downloading major assets such as images. The key to achieving this is using resource hints, such as rel=”preload”, to privatize the download of critical resources.

For example, even just adding a resource hint in the form of link as=script can make a major difference, as the browser now understands that the AMP library is critical to displaying the page and can prioritize its delivery. You’ll find many more of these easy wins in the AMP optimization guide on our website linked in the description it is also a good place to check into the AMP boiler plate generator, which enables optimized AMP templates to be created quickly. But as promised, it’s possible to take performance optimization one step further with server-side rendering. And the explicit goal here is to improve the so-called first content full paint, basically, the first time something useful appears on the screen. The AMP library comes with a static page layout system to reduce rendering and scrolling junk it works by hiding the document initially from the AMP boilerplate code until the AMP library is loaded. The library calculates the design and shows the content once it is loaded. The downside of this approach is that it causes the user to see an empty page until the template is loaded, and it does not support progressive rendering.

To offset these negatives, first, content full paint times can be improved by using AMP server-side rendering. This time you can remove the AMP boiler plate so you can layout and paint AMP documents without running the JavaScript AMP library. For instance, the AMP boiler plate generator’s service version makes it twice the speed of a standard AMP version.

Server-Side Rendering On Your AMP Pages

If you want to try out server-side rendering on your AMP pages, I’d suggest to try out the AMP Optimizer, part of a collection of Node.js-based tools we call the AMP Toolbox. The only major downside is that as of today, we haven’t yet taught our validators to read the service-side rendered result. So the output will be invalid AMP. For the time being, we recommend you to serve UN-optimized AMP pages alongside your optimized ones and pair them by a link rel amp HTML, just like you would link a non-AMP page to an AMP page. Yes, it’s a little convoluted today, but I promise we’ll make it better.

Finally, does any of this actually matter, or are these just a bunch of micro-optimizations? My teammate Sebastian has published a blog post where he compared the UN-optimized source to lightly optimized and aggressively optimized with service app rendering.

And the results are pretty clear, with savings between 15% and 55%, depending on the use case. Good luck digging through our optimization guide

Leave a Comment