Core web vitals and AMP: Everything you need to know
Look back through the initiatives and updates that Google backs and they follow a pattern. They all encourage webmasters and publishers to strip away or minimize anything not absolutely essential that might slow down the user experience.
AMP pages are a prime example of how Google encourages the lightest possible framework. Core Web Vitals are the next step in the evolution that will bring these same principles to the entire mobile web.
If you have struggled with developing on AMP, or want to know how Core Web Vitals will affect the work done on AMP, we're covering everything you need to know regarding AMP and Core Web Vitals.
Core Web Vital scoring does apply to AMP pages
First, even though AMP pages can seem like a unique, island category, they are subject to the same search ranking scoring as any other page. But, the way they are built means that they are more likely to perform better than regular pages.
While AMP is not a ranking factor or a guarantee of ranking above other pages, AMP can help site owners meet the recommended performance targets outlined by Web Vitals. In fact, AMP Pages are 5X more likely to pass Core Web Vitals than normal mobile pages.
Let's look at how AMP are naturally designed to chime with each Core Web Vital performance requirement.
First Input Delay
AMP code doesn't block user interactions
Long tasks cause delays in user interactions by locking the page until they are completed. To break up these long tasks (over 150ms) AMP employs process chunking to split any long tasks into bite-sized versions.
Many small tasks mean that if the load is interrupted by user input, the browser can perform that new task almost instantly, rather than waiting to finish processing a long task. This is why AMP pages feel so responsive to every interaction.
In this example from Google's web development guide, you can see how long tasks will delay requests from being processed.
Chop down these long tasks and it makes interactions faster, making the page feel instantly responsive.
Widgets are sandboxed
If outside code, like a widget, is needed, it has to be loaded outside the basic AMP page, in an iframe. By running external code in a separate container, code-heavy widgets won't prevent users from interacting with the page.
Core web vital scoring generally covers the first viewport impression. Measurement ends when a user starts to interact with the page. Usually, this is when a user starts to scroll.
So, to avoid wasting time loading elements that aren't needed right away, AMP delays rendering elements that are lower down the page, in what is known as a deferred layout.
Cumulative Layout Shift
Dynamic features have to wait for user interactions
When using AMP, any element on the page that can potentially make the layout reload or shift has to be triggered by user interaction.
CLS is measured before the user starts to interact with the page. With this system in place, it means you can't have a widget pop up right the user clicks on something or interacts with the page.
This means big events that shift the layout about have to be responses to interactions, the page only moves when the user is expecting the page to react and move.
AMP ensures stable layouts because the framework infers the size of resources before they are downloaded. Images, videos, and iframes are loaded using built-in components which have a specified height and width.
When the page begins to render, AMP understands the height and width of the container so it knows the size to reserve before it has to download the actual element. Having these elements in place in advance prevents elements with unspecified sizing from shifting the other elements around.
By using set AMP components, such as this image carousel, it makes it easy for the browser to understand the dimensions and content of the page.
Largest Contentful Paint
The largest visible single element in the first viewport, AMP is also positioned to deliver the LCP almost instantly.
Prioritizing the content that users can see limits the resources fetched during page load, so the page feels faster and the largest contentful paint can be prioritized.
AMP pages are preloaded and pre-rendered by Google Cache. By hosting the page on an AMP cache, optimizations are added to the page and the content is preloaded. When a user clicks a page that has been pre-rendered the browser has already downloaded the content, so it feels instant.
AMP is not a catch-all solution to Core Web Vitals
While using AMP is a reliable way to score high in Core Web Vitals there are other factors that can stop pages from meeting the thresholds. Slow server response times, un-optimized images, and heavy files will slow any page day. Also, not every page can be an AMP version. Menu and home pages will be exempt.
Creating AMP pages can be a good way to save time and work optimizing every content page. As it is a framework that is preferred by Google, these are the pages that will be ranked for organic searches. AMP should be one part of a healthy site with a strong mobile performance and experience.
If you would like to get Marfeel-generated AMP versions of your content, click here to get an estimation of what your revenue will be.