Google’s algorithm is largely opaque. For users, it’s nearly impossible to determine what factors boost rankings and what can lead to performance drops. This makes sense, of course, considering that Google likely doesn’t want to give away much about their trillion dollar business.

However, Google does make it clear that speed is an important factor when it comes to determining rankings. This conclusion was first noted regarding desktop page speed back in 2010 and was reiterated in 2018 as it related to the speed of mobile pages. The big takeaway: a page that loads faster is sure to rank higher.

 Although the value of speed is certain, Google hasn’t always clarified how speed is measured and what adjacent factors are taken into account. Google’s PageSpeed Insights tool has long offered a helpful baseline, but it consistently fails to provide a true user experience score because the data is lab generated. To address this concern, Google recently released Core Web Vitals, a tool that provides specific details on your site’s real-life speed and experience.

 In this post, we’re going to explore the factors that contribute to Google’s Core Web Vitals and explain how to use the measurements to test your website efficiently. While we’ll go into a good amount of detail about what can hamper user-experience, score, and ranking, please know that the post isn’t exhaustive and that it may skip over some of the elements that we consider to be a given for each new build. That said, don’t hesitate to reach out to us with any questions about your specific situation. 

About the Measurements in Google’s Core Web Vitals

Web Vitals are the four new measurement scores that Google uses to evaluate the speed of a particular URL. Before diving into the measurements themselves, it’s important to note that each one will be impacted by the real-world circumstances under which the website is tested. For example, a site tested on a fast laptop with broadband internet is going to receive different scores than a site tested on an old cell phone with 3G internet. That said, it’s crucial to account for the fact that any data is shaped by both the site’s performance and the device’s capability. 

On to the good stuff. To start, here’s an introduction to the four measurements that make up the Web Vitals Score:

• FCP - First Contentful Paint
• LCP - Largest Contentful Paint
• FID - First Input Delay
• CLS - Cumulative Layout Shift

These measurements all cover something different, but it's worth noting that the first three measurements are about how quickly the page is ready for a user. The last one, Cumulative Layout Shift, measures how much the content of a page jumps around both while the site is loading and throughout a user's time interacting with a page. 

It's also worth noting that this entire writeup ignores server-side performance. It takes for granted that your web server will quickly serve an HTML response to a URL request. This is the very first thing that MUST happen on every pageview and if it's not fast, every measurement taken is going to be bad.

Here are a few more details on what each of these measures means and how results might be delayed in the real world:

First Contentful Paint

This is the time that it takes from the browser's initial request of a URL to when anything is first drawn on the page. The idea for this measurement is that the perceived loading time of a page is improved when users are shown that progress is being made. This is the idea behind showing placeholder loading UI.

In the past, this score carried more weight. Sites went a bit overboard trying to game their FCP measurement, but luckily some have realized that it's not helpful to show placeholder loading UI if doing so delays the arrival of the actual content. 

In general, this score can be held up by things that block render, including stylesheets and scripts. Whenever a stylesheet reference is added to HTML, rendering is blocked until that resource is fully downloaded and parsed. The same is generally true of scripts, though they can be added with 'defer' or 'async' attributes. Those options are not available by default for styles, although there are tricks available like using the media attribute in combination with an onload event.

FCP score can be improved by only sending the resources necessary to render what’s visible to users in the viewport. There’s no need, for example, to ask the browser to immediately download images that show at the bottom of the page, or to download styles that apply to other pages on the site. This is why we use lazy image loading and inline styles that only apply to a particular page. 

Largest Contentful Paint

LCP is a new measurement that attempts to measure the time from the initial request to when the site's actual content is ready. That means that it waits until fonts and images in the viewport are fully loaded. Now that LCP is being measured, some of the tricks that sites would use to boost their FCP have turned out to be counterproductive.

For example, poorly implemented lazy-loading images can be problematic if a JS lazy-loading image appears in the viewport. Now, the FCP must wait not only for the image to load, but also for the lazy-loading JS to download, parse and execute. Needless to say, boosting the FCP at the expense of showing the actual content sooner is not a good practice.

In order to improve the LCP, it’s important to include the site fonts properly and make sure that the images in the viewport can load as quickly as possible. The latter can be done by using a native image tag with srcset or a picture element. Essentially, the goal is to ensure that all content in the viewport can be displayed with as few serial dependencies as possible.

First Input Delay

You know when you visit a really heavy page on your phone and everything feels choppy as the content loads in? That choppiness is called input delay. You ask the page to scroll, but it can't, because your phone is too busy doing a bunch of processing.

The processing that is occurring could be any number of things:

• Rendering complex styles
• Parsing assets
• Showing video/graphics
• Running a bunch of javascript
• The most common cause of FID is excessively complex JS from third parties like trackers and advertisers. But it can also be caused by scripts and libraries used on the site itself.

In order to reduce FID, the best thing to do is to reduce the amount of JS that runs on a given page. Then, of the remaining JS, procrastinate any JS that isn’t critical for the user experience. If you can, wait to download this non-critical Javascript until after the window.load event. On many sites, this makes sense even for analytics!

It has long been considered a good practice to include asynchronous analytics scripts as soon as possible on the page. This is done so that they can load as soon as possible and track all visits – even if they’re very short. However, if you have a good performing site, waiting for window.load doesn’t take very long at all.

A big thing to realize about FID is the degree to which it is impacted by device performance. This goes back to our comparison between the fast laptop and old cell phone. The measurement that is being taken for the FID score is time – it's not 'amount of scripts'. A modern computer can handle a LOT of computation in a very short period of time, but an older phone cannot. So even if you see a great FID score on a laptop, that may not mean much in the real world when your site is being visited by a variety of devices. Worse yet is the fact that when a site is running slowly, it tends to snowball.

A fast laptop might get the site rendering out of the way immediately and then start working on the non-critical javascript. A slower device might have all of the site's resources start to pile up and have a hard time finishing any of them at a given time. It's not uncommon for a device that’s half as fast to take four-times as long to be ready for user input.

Cumulative Layout Shift

As mentioned above, this measurement is unique because it’s ongoing. It measures how much site content jumps around as things load throughout a user's time on a page. This score is looking for situations where the text that you're reading suddenly jumps out of view, or the button that you’re about to click shifts to a different location due to page loading. Layout shift is a very frustrating experience that is often caused by efforts to improve initial load time.

The primary culprit for layout shift is image loading. When a simple image tag is put on the page without additional information about the image’s size, the browser has no idea how much space to reserve for that image until it actually loads. This means that your layout can be held up waiting for an image to be properly displayed. Images are typically the largest assets on a site, so you can see why this is problematic. 

Now that CLS is being measured, it’s proven to be a bit of a “gotcha” even for sites that are attempting to do the right thing. How? Many developers use the PageSpeed Insights tool to test site performance. This is fine, but it only provides a snapshot score at the time of initial render. What that means is that lazy loading images – which are invisible to the tool because they load later – leave developers unaware that layout shift will occur when images fully load.

As a result, many sites receive great scores on the first three metrics but a terrible user-experience and CLS score. The solution is to reserve space for every image on your site by declaring dimensions or proportions in either the HTML, the CSS, or a combination of the two.

Using Web Vitals Measurements to Build Faster Websites

Now that these measurements have been introduced, it's important to discuss the best way to monitor them when working to build a site. There are three main sources of measurements to keep in mind:

1. The actual Field Data that Google has for a given page.
2. Lab Data from Google PageSpeed Insights
3. Lab Data from the Web Vitals Extension

The italicized distinctions are worth highlighting. Field Data is a real world measurement from actual users. It’s based on true user-experience and it drives the SEO performance of a given URL. Lab Data consists of a measurement taken at a given time under specific circumstances that might not match the real world. Just because it's possible to pull good lab data for a given URL, it doesn't necessarily mean that actual field data will improve. And if you've done work that shows up in your lab data, it may take some time for enough real-world measurements to show up in the field data.

Below we’ll go into a bit more detail about each of the three data sources. 

Field Data

There are a number of ways to get access to Google's field data that are well covered by this blog post. The easiest ways, however, are to either look in Google Search Console under Enhancements > Core Web Vitals or in a PageSpeed Insights report under the “Field Data” section. PageSpeed Insights will generally show you aggregate field data for the domain that’s being checked, and, if the checked URL is popular enough, it will also show field data for the specific URL. 

The field data is generally a running average of performance for the previous 30 days. However, if big improvements have been made to the site, it can show up more quickly, particularly if a request is made through Google Search Console.

Looking at field data is the only way to know for sure how a given page is performing.

Lab Data from the PageSpeed Insights Tool

PSI is a wonderful tool that lets you quickly check the performance of a given URL against a simulated mobile and desktop device. At the time of writing, the simulated mobile device was a very-old Motorola G4 with a slow connection. If your page has a problem, PageSpeed Insights will almost certainly show it.

In addition to showing scores, it also shows suggestions. Now, it even shows suggestions that are tied to particular Web Vital metrics. For example, if there is a large, unoptimized image that shows up above the fold on page load, it will likely list that image as a problem under “First Contentful Paint.”

One thing to keep in mind when analyzing the suggestions is that any audit that has been "passed" is hidden by default. While this is helpful to reduce clutter, it sometimes hides important information. It is not uncommon for a particular URL to have a poor FID while passing all audits. When that is the case, it's worth digging in to see how many barely passed. Everything can start to add up.

The biggest thing to keep in mind with the PageSpeed Insights Tool is that it cannot effectively measure CLS since it does not interact with the page for more than a moment. If a page has layout shift issues when scrolled, this tool will never find those issues.

Lab Data from the Web Vitals Extension

It is also possible to quickly check the Web Vitals scores for any page you visit using the Web Vitals Chrome Extension. This can be very handy because the extension quickly shows a red or green light for a given page while also measuring layout shift as you interact with it. So if you were to scroll down a fast page that has layout shift problems, you could literally see the extension light change from green to red.

The most important thing to remember with the extension is that it is measuring using your device and your internet connection. If there are problems related to excess scripts running or oversized images and assets, you may not notice them on a fast device with a fast connection. The extension won't either.

Google has made it possible to simulate the performance of a slower device with a worse connection using Device Mode. This can be very helpful in combination with the extension since it will allow you to quickly check any number of pages as you browse around a site.

In Conclusion

All of this information can feel overwhelming, particularly if each point is considered without proper context. However, each detail of Core Web Vitals extends from a very basic principle: Google wants fast sites with good user-experience to rank higher. And while the metrics in this post are current now, it’s reasonable to expect that Google will continue to reassess and tweak their testing practices to better address that goal.