Google Core Web Vitals: A Simple (But Complete) Guide

As you can see, Google is not just considering page experience badges, they’re actively preparing for this feature.

If you want to positively influence searcher behavior by showing a “good page experience” badge to users – it makes sense to have your core web vitals in order.

(3). Speed Matters

The data is clear, users **** fast websites.

Not only do visitors buy more from quick-loading pages, and return to them more often.

They are WAY less likely to bounce off a page when the page is fast to load.

In fact, in a recent study of millions of page impressions, Google found that sites meeting Core Web Vitals thresholds were 24% less likely to experience abandonments before full page load.

So while there’s a lot of hype about core web vitals as a ranking factor, SEOs are missing the point.

The reason to address core web vitals is not just to rank higher, but because it’s better for user experience overall.

How is Core Web Vitals Measured?

Core Web Vitals are measured using real world data.

In other words, the actual experience users have interacting with your web pages.

Core Web Vital scores are not measured using simulations, they use data gathered from genuine Google Chrome browser sessions.

Why that’s important?

When it comes to Web Vitals, there are two types of data you can look at – field data and lab data.

Field data is collected from real users, each with their unique device and network connection, through the Chrome User Experience Report (“CrUX report” for short). It’s data on how users are actually interacting with your web pages.

Lab data is collected within a controlled environment with predefined device and network connection settings, without any involvement from real users. It’s synthetic data simulating how users may be interacting with your web pages.

Google uses field data to asses web vitals.

Let that sink in.

You could see great scores for your Lighthouse reports (lab data) and be crowning yourself as the core web vitals king, while your actual users are having a shoddy user experience (field data).

Here’s a list of tools and the data they use:

Now, I’m not saying only look at field data. The challenge with field data is that it is aggregated over 28 days – which means when you optimize your Core Web Vitals, using field data, you’ll not know if your optimizations worked for 4 weeks.

Thats a helluva long time to wait.

That’s why lab data such as Lighthouse, Chrome Dev Tools, and GT Metrix are useful. They give you an instant snapshot of your likely page experience.

The Three Components of Core Web Vitals

Here are the three current components of Core Web Vitals:

Let’s break each one down in detail:

Largest Contentful Paint – Loading

The Largest Contentful Paint (LCP) is how long it takes for a page to load from the point of view of a user.

It’s basically the time between a user clicking on a link and them seeing the majority of the content on their screen.

LCP is assessed by measuring the actual load time of the largest content piece in the viewport.

That’s typically a featured image or maybe the h1 tag, but could be any of these:

• <img> element
• <image> element inside an <svg> element
• The image inside a <video> element
• Background image loaded with the url() function
• Blocks of text

<svg> and <video> may be added in the future.

The Largest Contentful Paint is different from other page speed measurements. 

That’s because page speed metrics (like Time to First Byte and First Contextual Paint) don’t represent what it’s like for a user to open a webpage.

On the other hand, LCP focuses on what matters most when it comes to page speed: a user being able to see – and subsequently interact with a page.

How to Measure LCP

You can check your web pages LCP using PageSpeed Insights.

What I really like about Google Page Speed Insights is that it provides actionable ways to improve your LCP score.

What’s also neat about using Pagespeed Insights over a tool like webpagetest.org is that you get to see how your page has performed in the real world (based on actual Chrome browser data).

With that said, I also recommend looking at your LCP data in Google Search Console.

Why?

Well, like Google PageSpeed Insights, the data in Search Console comes from the Chrome User Experience Report.

But unlike PageSpeed Insights, you can see LCP data across your entire site. 

So instead of analyzing random pages one by one, you get a list of URLs that are good, bad… or somewhere in-between.

Once, you’ve identified the pages that need improvement, you can head over to PageSpeed Insights to understand what you need to address.

Understanding Your LCP Score

Like all its core web vital metrics, Google breaks down Largest Contentful Paint into three buckets: Good, Needs Improvement, and Poor.

• Under 2.5 seconds = Good
• 2.5 to 4 seconds = Needs improvement
• Above 4 seconds = Poor

This means, your goal for LCP is to have every page on your site load within 2.5 seconds.

Easier said than done. 

Take this post on our blog. It contains dozens of custom images and is SUPER long.

That’s why the LCP is 4.2 seconds (which is considered “poor”).

I’m not making excuses, but it goes to show that improving LCP isn’t as simple as installing a caching plugin or using a CDN (both of which we’ve done).

With that, here are some things you can do to improve your site’s LCP.

Optimizing LCP

There is a bunch of things you can do to improve your LCP score. Here are my top-3 recommendations.

Defer JavaScript

Render-blocking resources like JavaScript files are one of the main culprits of a bad LCP score.

They get in the way of HTML files and slow down the page rendering process.

To address this problem, I recommend you defer the loading of JavaScript files till later. This ensures the HTML files which house your content gets loaded first – and your LCP time improves.

Optimize Your Images

Optimizing images can fix a bad LCP score.

That’s because, for many website designs, a featured image is the LCP element. By improving the load time of featured images, you’ll boost the Largest Contentful Paint performance.

Here’s what you can do to optimize your images for faster load times:

• Compress and resize your images. You want to reduce the file size without losing quality. The smaller the image dimension is, the faster the loading time will be.
• Convert your images into new formats. Google recommends the WebP format for fast loading. Most WordPress image optimizer plugins like Imagify now include the option to convert images to WebP.
• Use responsive images. You shouldn’t use the same image size for desktop and mobile. Instead, you should upload image sizes appropriate to each device type (desktop and mobile).

Compress Text Files

To score better for LCP,  you should also compress text files such as HTML, CSS, or JavaScript resources.

Essentially, you want to “zip” your files in a smaller and lighter format so they load faster. 

Once you reduce their size, the transfer between browser and server will be quicker. 

In turn, the browser will load those resources faster and LCP will improve.

LCP Resources

First Input Delay – Interactivity

Next, we’ll examine Google’s second Core Web Vital: First Input Delay.

At this point, your content has loaded (FCP).

But is the page interactive yet? 

Well, that’s precisely what First Input Delay measures: the time from when a user interacts with your page until the page actually does something.

Put another way; FID is page responsiveness. 

Some of the interactions that are measured for FID are:

• Clicking on a link or button
• Choosing an option from a menu
• Clicking a checkbox
• Entering text into a field

In short, when users do any of these things – your page should respond right away.

How to Measure FID

FID is a “field” metric. In other words, it scores how responsive your page is in the real world. 

Because of that First Input Delay can only be measured by a few tools that use in the field data:

Like with LCP, I recommend you use Google Search Console to identify the pages on your site with FID issues:

Then use Pagespeed Insights to understand what you need to address on each specific page. 

Note that Page Speed Insights will not give you actual FID recommendations. However, it does provide Total Blocking Time issues which closely correlate with First Input Delay. 

Improve TBT, and your FID will invariably get better.

Understanding Your FID Score

According to Google’s FID criteria, your page should respond in 100ms or less:

Here’s the breakdown of FID times by band:

• Under 100 milliseconds = Good
• 100 to 300 milliseconds = Needs improvement
• Above 300 milliseconds = Poor

Obviously, it’s a bad user experience if visitors try clicking something on a page and nothing happens. Google understands that, which is why interactivity (e.g., FID) is a core web vital. 

Still, you should remember, not all users interact with a page. 

For instance, if the page is made up of content (like a blog post or article), the only real “interaction” a user has is scrolling – which doesn’t qualify for FID.

So what causes First Input Delay (FID)?

Almost always; JavaScript.

To explain it simply:

A browser processes requests on one main thread. If that thread is occupied by heavy JavaScript files, it can’t process other requests, including requests from users.

This means if a user makes a request (like clicking a button) the browser will not process the request until the JavaScript has finished. Hence the delay.

Source: Web.dev

The longer the task, the longer the delay experienced by the user. 

On the other hand, if the browser is only processing short tasks, with frequent breaks in between, it can switch to the user’s task and respond to what they wanted.

Optimizing FID

In general, you want to break up long tasks into smaller ones and defer any JavaScript that isn’t needed until later. 

Here’s the two main way to optimize JavaScript for better FID performance.

Defer JavaScript

When you defer JavaScript, you are essentially delaying the loading of these render-blocking resources until the browser has rendered the content needed for users to interact with the page.

As a result, the loading time will improve, as well as the FID grade.

Once you have identified the JS resources to defer, add this defer attribute to the JavaScript files:

<script defer src="https://seosherpa.com/example-js-script"></script>

This attribute tells the browser to defer processing these files until the page rendering is complete.
If you are using WordPress, simply install WP Rocket, it makes this process real simple:

Break up Long Tasks

As I already explained, when the main thread is busy and blocked, the page can’t respond to user inputs – and the FID grade is affected negatively.

To solve this issue, you should split long-running scripts into smaller chunks that can each be run in less than 50ms. Splitting up long tasks ensures breaks between tasks where user inputs can be processed.

Why 50ms?

Because a “good’ score for FID is below 100ms. 

If your tasks are no longer 50ms, then you should be able to achieve that score comfortably.

FID Resources

Cumulative Layout Shift (CLS) — visual stability

Cumulative Layout Shift (CLS) is how steady a page is. In other words “visual stability”.

If elements on your page move around unexpectedly as the page loads, then you’ve got a high CLS – and that’s bad for the page experience!

From a user’s standpoint, let’s say they try to click the navigation, and the page shifts. They end up clicking something they didn’t intend to and get navigated to the wrong page. It’s massively frustrating.

Common causes of CLS include:

• Images without dimensions
• Ads, embeds, and iframes without dimensions
• Injecting content with JavaScript
• Applying fonts or styles late in the load

Unlike LCP and FID, Cumulative Layout Shift (CLS) isn’t measured in seconds. 

Instead, it measured by the degree of movement between two unstable elements in the viewport – the viewable area of the page.

The layout shift score is a product of two components: the “impact fraction” and the “distance fraction”.

The “impact fraction” is the area of the viewport that the unstable element takes up in both frames:

The “distance fraction” is the greatest distance the unstable element moves between both frames, divided by the viewport’s largest dimension (width or height):

To be honest, you don’t need to know exactly how the CLS score is calculated.

But you absolutely need to know how to find your CLS score and address poor-performing pages.

We’ll cover that next:

How to Measure CLS

In PageSpeed Insights, under Diagnostics, you can select audits relevant to CLS. This will show you a list of the elements that are shifting.

However, Page Speed Insights is not good for visualizing what’s actually moving.

For that, I recommend this Layout Shift GIF Generator tool:

You can also use WebPageTest and a mobile device simulation (I chose iPhone X), in Filmstrip view with the following options:

• Highlight Layout Shifts
• Thumbnail Size: Large
• Thumbnail Interval: 0.1 sec

Notice how the block of content below our headline changes layout at 2.4 seconds.

Layout shifts like this should be avoided.

Understanding Your CLS Score

As I explained, the Cumulative Layout Shift is the sum of all the unexpected content shifts occurring on the page. 

Here are the specific criteria Google has in place for CLS:

• Under 0.1 = Good
• 0.1 to 0.25 = Needs improvement
• Above 0.25 = Poor

In other words, you need to nail a CLS of sub 0.1 to pass core web vitals.

Optimizing CLS

Unexpected layout shifts mostly occur due to images or ads having undefined dimensions.

Or, new elements getting added to a page, above existing content that has already been loaded. 

This results in content that has already been loaded being pushed away.

And, the page moving around like CRAZY. 

Here are the top-3 things you should do to stop CLS from occurring:

Add Width and Height Size Attributes to Images and Video Elements

One of the simplest ways to fix CLS is to include the width and height attributes on your images and video elements.

In most CMS this will be set automatically:

But just in case your CMS does not do this by default, you should include the width or the height attribute aspect ratio using CSS.

Define Space and Size for Ad Slots, Embed and iFrames

There are several best practices to avoid any layout shift for ads, embeds and iFrames:

• Assign fixed dimensions to ads, so there’s enough space reserved for the element to be loaded.
• Keep the biggest possible space for ads, embeds, and iframes. If space is smaller than is needed, a layout shift will happen when the ad, embed, or iframe gets loaded.
• Keep every space reserved for elements that have not been displayed. In other words, you shouldn’t collapse any area on the viewport. Instead, include a placeholder or a fallback element.

Manage Dynamic Content

Dynamic content such as banners can also affect Cumulative Layout Shift. 

That’s why I recommend you avoid displaying new content unless it’s triggered by user interaction. 

CLS counts only the layout shifts that occur when users are not interacting with the page.

Which means:

Dynamic content triggered by users = OK

Dynamic content not triggered by users = Not OK

CLS Resources

Best of the Rest: 5 Practical Steps You Can (and Should) Take to Ace Your Core Web Vitals

Now we’ve addressed specific core web vita issues, relating to LCP, FID, and CLS (and how to fix them).

Next, I’m going to share five core web vitals best practices that you should have in place, regardless of whether your websites scores good, poor or needs improvement for core web vital metrics.

Implementing these will ensure you excel for page experience signals, now and in to the future.

Let’s jump in:

(1). Speed Up Server Response Time and Accelerate TTFB, LCP and FID

Most people assume that speeding up a server influences only Time to First Byte (TTFB). 

But, the longer it takes a browser to receive content from the server, the longer it takes to render anything on the screen. 

Which means, a faster server response directly improves not just TTFB, but every single page-load metric, including LCP and FID.

To improve server speed, the single biggest thing you can do is switch to faster hosting.

If you’re on that $9 bucks a month shared hosting plan, it’s time to move.

Cloudways is my go-to hosting recommendation these days. It’s lightning-fast and offers dedicated environments for all manner of CMS.

But there are many more options:

Whatever you opt for, make sure it’s as fast as possible.

Anything above 600 milliseconds is considered slow by Google.

(2). Leverage a Content Delivery Network (CDN) and Load Your Pages 2X Faster

Pages using a CDN load as much 2X faster than pages without a CDN.

Infact, installing a CDN is the number one thing you can do to improve initial response time.

At least if this data by Backlinko is anything to go by:

But wait, what does a CDN do?

A Content Delivery Network (CDN) improves the availability of your images by serving them from locations near to users. In other words, instead of serving your images from a central server, a CDN stores a cached version of your images in multiple geographic locations, known as Points of Presence (or POPs for short):

Because your content is served from POPs close to the user (and not on a server thousands of miles away), they load way faster!

This is especially important for core web vitals.

To get a “good” score for largest contentful paint, you need your largest content element to fully load in under 2.5 seconds.

As I already pointed out, the biggest content element on a page is very often the featured image. 

Which brings me to my next point.

(3). Implement Lazy Loading to Serve Only What’s Necessary

If you use lots of images in your posts, then there’s a high chance they’re affecting your page load time – unless you’re using lazy loading that is.

Instead of all images being loaded at once, lazy loading serves images only when they’re needed.

In other words, when the users scrolls to that point in the page:

The idea here is to shorten the length of the critical rendering path, or the length of time it takes the user to reach the page’s Largest Contentful Paint (LCP).

Google has several resources explaining how to implement lazy loading, but if you, like me, are not a developer, it’s kinda complicated.

For that reason, I recommend using a lazy loading plugin.

Here’s two to check out:

Once you’ve picked one of them, move on to core web vitals action step #4.

(4). Use Full Page Caching to Boost Your Core Web Vitals

This one is easy. 

To reduce server response time (or, Time To First Byte) install and configure a caching plugin.

I suggest:

WP Rocket, WP Fastest Cache or W3 Total Cache in that order.

My vote goes to WP Rocket because it’s easier to set up than others.

But, to be honest, it doesn’t matter much which you choose, they are all close in terms of performance:

I’ll not go into detail here, just know that caching is the idea of storing important data in an accessible spot so that it can be more quickly served to visitors.

As you see above, caching can shave off nearly half a second from load times.

Great for core web vital improvements.

(5). Load Your External Scripts Till Later

External scripts destroy your load time.

Which is why I recommend you remove all but the scripts you absolutely require on your website.

And the ones that are really necessary? You defer their loading till after the main page content.

If you use WordPress, simply install the Perfmatters plugin, then add all your scripts in the Delay Javascript section:

For me that’s scripts like Wistia which I use for video’s on my website, and Google Analytics.

And by delaying them, I shaved vital milliseconds from my load time.

Final Thoughts

If you haven’t got your core web vitals in order, don’t freak out!

Google is rolling out the page experience update gradually. 

“You can think of it [page experience] as if we’re adding a flavoring to a food we’re preparing. Rather than adding the flavor all at once into the mix, we’ll be slowly adding it all over this time period.”

In summary, you’re not likely to see a huge impact from Google’s core web vitals update initially, but it’s likely you will over time as Google dials up core web vital requirements.

Which means, whenever you are reading, start now.

The longer you leave core web vitals unattended, the more you’ll be impacted over time.

That’s why I’ve created this special core web vitals bonus for you.

It’s a simple checklist containing 7 action steps you need to take to pass core web vitals. Includes 2 strategies not contained in this post. Download it below – it’s free.