Core Web Vitals: How to Get Ready for the Page Experience Update

What is the Google Page Experience Update?

This is a big Google algorithm update that will combine a number of metrics known as Core Web Vitals to form a page experience ranking factor. It’ll happen in May of 2021, so you’ll have plenty of time to make the necessary improvements to your website.

How is this different?

Since Google rarely announces algorithm changes until they go live, this would have a huge effect on how websites are ranked. Individual websites may see a minor impact, particularly in industries that have already prioritised page load times and quality UX, but niche ecommerce websites, news blogs, and other sites with outdated user interfaces may see a significant impact.

Google’s charge to improve mobile site efficiency continues here. Google has made it clear that mobile search is the future, beginning with the transition to https (helping to eliminate the stigma associated with shopping over insecure networks) and then with the update to mobile-first indexing. Google is now setting out the blueprint for profitable online companies and websites by rewarding pages that load quickly.

What are Core Web Vitals?

Three metrics that rate a user’s experience loading a website are known as Core Web Vitals. These metrics rate the speed with which page content loads, the speed with which a browser loading a webpage can react to a user’s feedback, and the stability with which the content loads in the browser. These three metrics will be combined with Mobile Friendliness, Safe Browsing, HTTPS, and Intrusive Interstitials to form the “Page Experience Signal,” according to Google.

LCP – Largest Contentful Paint

Simply put, this is the point at which the main content of a website has loaded. You may have heard terms like DOM or DOMContentLoad mentioned by your development team or an SEO in the past. That’s close, but Google claims this is a more straightforward calculation based on the render time of the largest visible image or text block.

To put it another way, if your site has a big picture or a video background that takes a long time to load, you’re in trouble.

Similarly, if you have a lot of render-blocking JS or CSS (another common SEO & Dev topic), or if your site is set up with client-side rendering, you’ll probably have to spend some time in the coming months upgrading your LCP to meet Google’s new guidelines.

CLS – Cumulative Layout Shift

Have you ever been on a website where the whole content changed? More than one element shifted at times, or shifted multiple times. It was almost as if the layout changed every time anything loaded on the page, and it all added up to a lot of shifting over time…

You guessed it: this has finally been labelled as a bad user experience.

This awesome video was shared by the Google web.dev forum, which highlights this experience:

Perfectly captured…

So, how do we comprehend and respond to this problem? Basically, resources and content are loaded after and above existing content on the page. Perhaps you have a wide image that you’ve decided to load after the most important material. Perhaps there’s an ad that appears after you’ve loaded everything else on the web. Perhaps there’s a widget in the sidebar that moves the main article to the right.

All of these are examples of layout instability that contribute to a Cumulative Layout Shift ranking, which is calculated by adding all of the unforeseen layout shifts together.

FID – First Input Delay

When we load webpages in a browser, we normally expect the page to be ready to accept our input the second we see a visual feature, such as a button, a picture, or a scroll bar, load on the screen. And if the page appears to be loading, we expect to be able to press the button or scroll down the page.

When our experience does not live up to our expectations and a page does not begin to react to our acts, we become frustrated.

The reality is that the browser is often unable to react because it is occupied with parsing a huge JavaScript that controls an on-page feature. The browser does not have the resources to run event listeners that would respond to the user’s input while it is loading this file.

The first input delay (FID) is a user-centric metric that helps measure user dissatisfaction. It’s important to remember that FID only measures the delay in processing the user-initiated event, not the event processing time or the time it takes to make changes to page layout or content.

We can see a good example of FID calculation in the example above, which can be found at https://web.dev/fid/. A user has started loading the page in this case. The browser’s main thread is busy performing tasks like loading a JavaScript file as the page content loads and starts to render.

The user notices something interesting and wants to communicate with the page, so the page has already begun to load visual elements. Since the main thread is already busy with other tasks, it must wait until the current task is finished before acting on the user’s feedback. FID is the amount of time that passes between when a user attempts to interact with a page and when the browser is able to react to that user’s input.

Evaluating your Core Web Vitals

1. How can we figure out where our pages stand now that we’ve learned everything there is to know about the Core Web Vitals? Fortunately, there are a few options for analysing the website.
2. The simplest way to fix several pages on a vast site is to use Google Search Console. GSC has a section in the main navigation called Enhancements where you can see how many pages on your site are influenced by each Core Web Vital.
3. You’ll see a report for each Core Web Vital issue where your site might be having trouble after clicking through to this section.
4. The brightedge.com site, as you can see in the example below, has a minor CLS problem. There is a CLS problem on 5 of our websites. I’ve outlined how to read this study most effectively:
5. CLS greater than.25 is the problem and the guideline in this situation.
6. The total number of pages on your web that are impacted by this problem. Core Web Is Crucial
7. This is an example of a page that has this problem. This is a significant distinction between this study and those from the GSC. You won’t see any page that needs to be fixed in the Core Web Vitals reports. To be honest, it would be a long and inconvenient way to solve all of Web Vital’s problems, as you’ll almost certainly need to fix things on a templated level to correct more than one page at a time.
8. This page is one of up to 20 that have the same problem. Each example URL will take you to a page that is similar to the one you are looking at. This approach is being used by Google to highlight where the same problems that were found on your example page are also present on other pages on your web. If you have a problem on your /blog/ and the same problem on pages in your /press-releases/ section, you’ll only see one of them in the example urls, but the other will appear in the example info. This should indicate that more pages in /press-releases/ would need the same correction.

Fixing your Core Web Vitals

Now that you know what and Core Web Vitals metric measures and how they reflect pain points for consumers seeking to access your content and connect with your brands, it’s time to take steps to strengthen these metrics – and, more importantly, your customer engagement.

Each location will be distinct in some way. It’s unlikely for two different sites to have exactly the same problems, so it’s critical to thoroughly investigate and examine each of your domains to determine which changes would be the most effective.

Of course, there are more common problems that website’s face, and we will guide you to common solutions for those issues.

Common LCP-related activities

• Using the PRPL pattern, apply instant loading to your Critical Rendering Path.
• CSS files should be optimised, as should image file sizes and compression.
• Web fonts should be optimised or removed.
• Reduce or optimise your JavaScript (for client-rendered sites)

Common FID-related behaviours

• Reduce the effect of third-party code and the time it takes JavaScript to execute
• Keep request counts low and transfer sizes small by minimising main thread work.

CLS-related behaviours that are common

• Include size attributes on your images and video components, or use CSS aspect ratio boxes to reserve space.
• Except in response to a user interaction, never introduce content above existing content.
• Instead of property animations that force layout changes, use transform animations.