Is AMP Good For SEO ?

Enabling AMP (formerly Accelerated Mobile Pages) on your website can be a lot of work. You may have to rewrite parts of your web structure along with some of your pages and posts. So before starting this migration for my own website, I asked myself if AMP was really so good for SEO that I would be ready to do the job.

AMP allows web pages load faster on mobile and desktop devices. For example on mobile, “First Contentful Paint” went from 4,5s for non-AMP to 2,2s for AMP for a 4700 words page with 12 images. This performance enhancement improves the web user experience, and as a result is good for SEO ranking factors.

AMP is an open-source HTML framework that provides a way to create fast loading web pages with a user friendly experience. This may look like a commercial description. However this is exactly what I experienced when I migrated my WordPress website to AMP.

This is the reason why I wanted to start this article with a real page example. I will show you how AMP improved the user experience as well as SEO speed indicators. Then we’ll analyze in more technical terms the reasons why I think AMP improves SEO.

Table of Content :

• AMP is Good for Page Loading Speed
• AMP Improves SEO Ranking Factors
• How does Technically AMP Improve Page Speed
• The AMP Cache is Not Always Used for AMP Pages
• Conclusion

AMP is Good for Page Loading Speed

With AMP, real-life examples speak for themselves.

That’s the reason why, I chose to review with you the AMP and non-AMP versions of this URL : The Photographer’s Metadata Survival Guide – In Depth Description.

It’s a 4724 words article, with 12 image illustrations along the way and 4 embedded Youtube videos.

I created a test WordPress site with two pages, one AMP and the other non-AMP, with exactly the same content of the original page. I discouraged search engines from indexing this site.

More about my WordPress environment :

• I use WordPress core theme Twenty Twenty
• the WordPress plugin AMP for WordPress by AMP Project Contributors. This is the official AMP plugin for WordPress, referenced in the AMP Project. I use the Standard mode : “Your site is AMP-first and your canonical URLs are AMP”. It creates by default AMP pages, but allow you to individually design some pages as non-AMP. I used this feature to perform the test with one AMP and one non-AMP page with the same content.

Here are my WordPress optimization plugins :

• WP Lazy Loading by the WordPress Team
• WP Super Cache by Automattic
• Autoptimize by Frank Goossens (futtta)

I tested the AMP and non-AMP version of the same page with the pingdom tool and Google PageSpeed Insight (PSI).

Non-AMP Page

First with pingdom :

These numbers were quite good for a long article.

I tested the page on Google PageSpeed Insight (PSI). Tests are performed for mobile and desktop and results presented in 2 tabs.

I could recognize correct page load times for desktop. This was coherent with the Pingdom results.

On the other hand, page load results are pretty bad on mobile.

AMP Page

Here are first the pingdom testing results for the AMP page.

I then tested the AMP page with Google PageSpeed Insight.

All indicators are better with the AMP page than with the non-AMP page, as we’ll show in the following result table.

Page Load Comparison for AMP and non-AMP Page

Here is the summarize table for these tests :

All numbers are far better with the AMP version of the page. The improvements concern the page size, the number of requests to the server, and all response times.

At this point, it is important to get into more details about the tests. When we tested the load page response test of the AMP and non-AMP pages, we were testing the response time of my website serving these pages.

In this configuration the AMP cache is not being used.

This is a very important precision. It took some time for me to understand that the AMP cache is not being used every time you access an AMP page :

• When your AMP page is clicked from a Bing or Google Search Result, it is served from an AMP cache.
• When your AMP page is accessed directly via its URL, it is NOT served by an AMP cache.

I will get into more details about the AMP cache later in this article.

This precision is important, because we can say that even without the use of the AMP cache, the page loading factors of our AMP page is better than those for its non-AMP version.

This is how, in my experience, I saw that the AMP framework that provided a way to create fast loading web pages with a better user-experience.

AMP Improves SEO Ranking Factors

Google collects more than 200 numbers about your page and site in order to position your page in the search indexes.

No search engine will ever publish their exact list of ranking factors, nor their algorythms. They communicate regularily however, give hints about important factors.

For instance, webusers are now more and more using web search engines from a mobile than from a desktop. This lead Google to migrate indexing bots from desktop to mobile, and to increase the importance of the mobile friendliness and speed for page indexing.

AMP is not a direct ranking factor. However, when an AMP page is available, it can be featured on mobile search as part of rich results and carousels. See Google documentation Understand how AMP looks in search results.

So how does AMP improve SEO indexing ?

AMP increases these ranking factors for your page :

• Page loading speed measured by bots, in particular the First Contentful Paint (FCP) metric.
• Statistics on your page loading speed : Core Web Vitals reports.

The FCP Metric

You can measure your Page loading speed with Google PageSpeed Insight. This tool is accessible online at this address.

The Lab Data section contains the performances for your page measured instantly.

One tab gives you performance insights for mobiles, and another tab for desktops. This is particularily convenient since google moved their bots from desktops to mobile with their mobile-first indexing campain.

PagesSpeed > Lab Data measures instantly :

• First Contentful Paint
• Largest Contentful Paint
• Speed Index
• Cumulative Layout Shift
• Time to Interactive
• Total Blocking Time

You can find more information for PageSpeed Insights / Lab Data on Google documentation here.

The Core Web Vitals

Google gathers also information from real users on the web. In particular, Google collects every page’s response time visited for users that agreed to be part of this collection program, the Chrome User Experience Report (CrUX) . These data are aggregated and served in the Field Data section of Google PageSpeed Insights, but also in Google Search Console.

Consult Google PageSpeed Insight for your page, Field Data section.

You can find more information for the CrUX here.

In other words, the Field Data section is an average of the user experience for your page over time.

Not every indexed page has sufficient web traffic to have a Field Data Section populated however.

Here are the data gathered with the CrUX program :

• First Contentful Paint (FCP), measures overall waiting time.
• First Input Delay (FID), measures interactivity.
• Largest Contentful Paint (LCP), measures the loading performance.
• Cumulative Layout Shift (CLS), measures visual stability

Google selected then 3 of these metrics as The Core Web Vitals :

• FID
• LCP
• CLS

A page passes the Core Web Vitals assessment if 75% of all three metrics are Good. Otherwise, the page does not pass the assessment.

Google Search Console gives you a report with the Core Web Vitals for your site. You can see how many pages have already enough data for this metric, and which pages pass or not.

Google PageSpeed Insights is another way to query the Web Vitals for a specific URL, which may be in your site or any URL on the web.

As you can see in our example, page “https://developers.google.com/speed/docs/insights/v5/about” did not pass the Core Web Vitals when I write this article. It reached more than 75% good for FID, but not for LCP and CLS.

You can find more information for the Core Web Vitals on Google documentation here.

How does Technically AMP Improve Page Speed

AMP comes with a set of rules that apply when writing the page and when executing it.

When you use an AMP plugin in WordPress, the plugin does all the AMP coding and rule enhancement for you. The rules we’ll see below are taken care of by the AMP plugin.

Regarding the page loading speed, the following rules help pages load faster :

• Asynchronous JavaScript shortens the waiting times
• Deferred layout for instance video player
• Keep all third-party JavaScript out of the critical path within iframes. These scripts are not blocking the main page flow.
• Size all resources statically, usefull for pageloading.
• Interaction required for dynamic content, no blocking popup appears out of the blue.
• Efficient font loading.
• AMP cache (under conditions).

This video published by the AMP Channel gets into details : “7 Ways AMP Makes Your Pages Fast” :

If you prefer written explanations, here is an article from the WordPress official plugin documentation : “How AMP Achieves its Speed“.

Let’s get deaper into the AMP’s cache.

The AMP Cache is Not Always Used for AMP Pages

It’s important to note that you don’t always access an AMP page through the AMP cache :

AMP Page Clicked in Google Search Results

As a website owner, you don’t choose an AMP Cache, it’s actually the platform (Google, Bing…) that indexes your content that chooses the AMP Cache (if any) to use. In other words : when published on the web, you AMP page will be cached and it’s automatic. You don’t have to choose a CDN, you don’t have to configure anything in order for your page to be present in the AMP cache.

Google and Bing have their own AMP cache.

Bing AMP Cache serves cached copies of valid AMP (Accelerated Mobile Pages) content published to allow Bing to provide faster mobile experiences to Bing users. More about Bing and AMP here.

The Google AMP cache performs modifications and optimization, as for instance :

• Validates the AMP content
• Caches AMP document, images and fonts.
• Limits maximum image dimensions.
• Various transformations on images :
  • Conversion of images to smaller and mobile-friendlier image formats, such as converting GIF, PNG, and JPEG format images to WebP in browsers that support WebP.
  • Transformation of the image to a lower quality if the request includes the Save-Data header.
  • Generation of alternatively sized versions to support delivery of responsively sized images.

If you want to access a page from the AMP cache, you can read this google documentation : Google AMP Cache.

Google published a tools that gives you the URL of your page in the AMP cache.

For instance, if we go back to the article I took as an example.

• the AMP page URL is

https://blog.laurencebichon.com/photographer-metadata-survival-guide/

• the AMP cache URL is

https://laurencebichon-com.cdn.ampproject.org/c/s/laurencebichon.com/photographer-metadata-survival-guide.

If you want to investigate further on, you can then load the AMP cached page and use developper tools to analyze its structure.

You can also run a Pingdom on this AMP cache URL and see for instance that the images are now served as Webp and come from the cache :

I also analyzed this image a little further and noticed that images in the AMP cache still have metadata, in particular copyright metadata. This is a very important feature for photographers for instance.

AMP Page Accessed via it’s Origin URL

When an AMP page is accessed via it’s origin URL, your web server serves it, not the AMP cache.

This happens when a user types directly your AMP page URL, or when another platform links to your AMP page. If a user clicks in Twitter on a link to your AMP page, this AMP page will be served by your own website too, not from the AMP cache.

If we look back at the tests I did in the first chapter of this article : AMP is Good for Page Loading Speed, we saw that the AMP version loaded faster than the non-AMP version of the same page.

In this case, we did not measure the benefits of the AMP cache because it was not being used. Indeed, we did not access the page via a search result, but directly via its URL.

We can run a Pingdom on the AMP page URL, it is served from the web site, not the AMP cache :

Also the images you serve are being served directly from your site. So the image optimisation has to be done within your site.

The AMP Channel communicated recommandations for serving directly AMP pages. You can see their Youtube video “How to make your AMP pages even faster” :

This video presents the big picture for the usage of the AMP cache on AMP pages. It refers to a more indepth article about possible optimizations to AMP pages that will enhance the load time of these pages when they are served by your website : “Optimize your hosted AMP pages” at https://amp.dev.

Some of the optimizations are already done with my AMP for WordPress official plugin :

• Put the meta charset as the first tag, folllowed by the remaining meta tags.
• Preload the amp library with a resource hint : <link rel=”preload” as=”script” href=”https://cdn.ampproject.org/v0.js“>
• Server Side Rendering (SSR). You may check by looking for ‘transformed=”self;v=1″‘ in the source code of you AMP page.

Some of the optimizations are also general web server optimizations, that will also be beneficial to your AMP pages when served directly by your site :

• Optimize images and videos.
• Compress and minify CSS & HTML.
• Use HTTP Caching

This is why it is usefull to still use a caching system on your website. Personnaly, I use :

• WP Lazy Loading by the WordPress Team
• WP Super Cache by Automattic
• Autoptimize by Frank Goossens (futtta)

I also started to research about serving Webp images instead of JPEG images. As I’m not finished yet, I’ll speak about it later.

Conclusion

In conclusion, is AMP good or bad for SEO ?

AMP is designed to enhance the page loading time and experience.

It’s been effective on my site where I’ve seen my page load indicator been raised significantly.

Knowing that page speed is a SEO ranking factor leads me to answer : yes, AMP is good for SEO !

So we’ve reached the end of this post.

I thank you for your visit. See you for other technical topics related to photography technics and publishing on #TechCorner.