In mid-June 2021, Core Web Vitals will become a part of Google's Page Experience ranking signals.
There's a lot of misinformation and misunderstandings around this topic.
So, today in today's post I will be sharing with you exactly what Core Web Vitals are, why they're important, and how to improve them for SEO.
What Are Core Web Vitals?
Core Web Vitals includes three different metrics that measure specific aspects of page speed.
- Visual load measured by Largest Contentful Paint (LCP).
- Visual stability of your web pages measured by Cumulative Layout Shift (CLS).
- Interactivity is done with First Input Delay (FID).
Now, the Core Web Vitals can't be looked at independently like other ranking signals. They're a part of Google's Page Experience ranking signals which also include things like:
- Safe browsing
- Intrusive interstitials (pop-ups)
No one can predict what impact it will make on ranking. But improving your Сore Web Vitals is worth it because page speed improves conversions.
On top of that, they saw a 22% decrease in new site abandonments and a 24% decrease in shopping site abandonments.
On top of that they saw a 22% decrease in new site abandonments and a 24% decrease in shopping site abandonments.
Main Types Of Data For Core Web Vitals
Now, before we get into the actual optimizations, you need to understand the two main types of data for Core Web Vitals metrics.
So the two types of data are field data and lab test data.
Field data consist of user metrics and is reported by the Chrome User Experience Report, also known as CrUX.
Basically, Google takes data from Chrome users who have opted-in to share information like browsing history.
They then take that data and compute the 3 Core Web Vitals metrics which are intended to understand how real-world Chrome users experience the web.
You can see a summarized view of your site's Core Web Vitals in Google Search Console and page-level metrics in PageSpeed Insights under the “Field Data” category.
Now, a huge con is that field data is based on a rolling 28-day average. Meaning, if you change something on your site, the full impact won't be reflected until around 28 days later.
This is where lab test data can help.
This data is usually generated by tools. And lab test tools are designed to run tests consistently under the same conditions.
Meaning, they won't necessarily reflect “real world” data because of factors like location and internet speeds. On top of that, bots aren't going to interact with your content, whereas humans will.
Now, there are 2 important things to note:
- The metrics are assessed at the 75th percentile of users.
- The second thing to note is that metrics are measured by device type, meaning mobile Core Web Vitals will be assessed separately from the desktop.
And since Google has switched to mobile-first indexing, we're most interested in the mobile scores from a ranking perspective.
Now, the downside to these tools is that you can only check one URL at a time. Or for tools like Google Search Console, you'll only be able to see field data.
Basics Of Google's Page Experience Signal
Before you start optimizing your pages for the 3 metrics, you must handle the other basics of Google's Page Experience signals like mobile-friendly, HTTPS, etc.
The core Web Vitals are a part of the page experience ranking signals. Also, you should take care of basic page speed optimizations like:
- Having good hosting like Bluehost.
- Caching your content.
- Compressing and lazy loading your images.
- Setting up a CDN.
All of these things can help improve your Core Web Vitals.
If you don't know how to do these optimizations and you use WordPress, then I highly recommend watching our tutorial on how to speed up a WordPress website.
So, now let's dive right in to optimize your Core Web Vitals Score.
1. Optimizing Largest Contentful Paint (LCP)
The first metric is Largest Contentful Paint or LCP, which tells us about visual loading performance.
LCP is simply the single largest visible element loaded in the viewport, which is the area of the web page that's visible to a user.
The common areas might be a featured image, a background image, the H1 tag, or even a paragraph in the content.
The recommended target is to have your LCP load in under two and a half seconds.
To check LCP for a page, you can use any of the tools like PageSpeed Insights, the Lighthouse extension, or Chrome Dev Tools.
Now, when you use PageSpeed Insights or Lighthouse, you can use lab data as you make updates because again, the field data is a rolling average of the last 28 days.
To see the largest element that was measured, scroll near the bottom of the report and click “Largest Contentful Paint Element.” That would mostly be a featured image or H1 title tag.
Now, if you're working on a dev site that's not available to the public, you may want to use Chrome Dev Tools.
How to check the LCP in Chrome Dev Tools:
- Right-click anywhere on the page you want to test.
- Click Inspect element.
- Set the device to a mobile device.
- Click on Performance.
- Hit the Record button.
- And refresh the page.
- After the refresh is done, hit Stop.
- You should then see LCP in the timing graph.
And if you hover over it, you'll see the largest visible element in the viewport. Click it, and you'll see more details below.
If you've implemented the basic optimizations for page speed like good hosting, caching, image optimizations, and the use of a CDN, then that should help with loading performance.
But if you have issues with render-blocking JS or CSS, then it gets a bit more technical. And in order to make optimizations effectively, you need to have a basic understanding of how browsers render pages.
Understanding Of How Browsers Render Pages
- So let's say a user enters an URL in their browser. The browser will then send a get request to get the contents of the requested URL.
- Then a DNS lookup happens, which basically maps out domain names to IP addresses of servers.
- Once the server IP is found, the request is sent through, a connection is made with the server, and then the server will search for the file of the URL.
- And once it finds it, it'll send that data back to the browser which will then process the file to show the web visitor the contents of the page.
Now, we won't go further into DNS or hosting because I just want you to focus on what actually happens during that processing stage.
So then all of these resources need to go through that same process which can be time-consuming if you have a lot of resources you're requesting.
To add to that, if these files need to load one by one in order to paint the contents on the screen, then your LCP is going to get destroyed.
But there are ways you can optimize this process to improve loading performance.
So let's talk about optimizing the rendering process for the 3 main types of resources:
1. Optimizing Images
Beside from the things that I've already mentioned like lazyloading and compression, preloading images can significantly reduce page load times. Preloading basically tells browsers the resources you want to load first.
For example, if you have a featured image in the viewport, then that's something you'd probably want to preload. And preloading can actually be used in CSS, JS, and fonts too.
If you want to know more on Preloading responsive images you can refer to this post by web.dev.
For CSS optimization files, there are a few things you can do:
- Minification of CSS.
- In-line your critical CSS for above-the-fold content.
- Remove unused CSS and defer non-critical CSS.
To find CSS that your page isn't using, go to Chrome Dev Tools, click on the vertical ellipses, and hit the Run command.
Then search for Show Coverage.
Click one of the URLs and you'll see the exact lines of code that haven't been executed on that page.
From here, you can remove anything that your site isn't using, or move unused code to a separate file and only load that resource on pages that need it.
Minify it where it won't break your site and remove non-critical JS.
Now, two other things worth doing are to defer or asynchronously load JS where appropriate. And you can do this by using the defer or async attributes in your script tags.
To do this, you can either hire a developer or use WordPress plugins if you use WordPress. Check out these videos above, maybe you'll find them useful.
2. Optimizing Cumulative Layout Shift (CLS)
Alight, the next metric is Cumulative Layout Shift or CLS, which measures visual stability.
CLS looks at how much visible content has shifted in the viewport and measures the distance the affected elements were shifted.
For example, if we visit this page and start scrolling down, you'll see that out of nowhere, ads start to appear, shifting the content. It's annoying, causes a bad user experience, and that's probably the reason why CLS exists.
Now, the way they used to measure this metric was to continually measure stability even after the page loaded.
But recently, Google decided to measure CLS in 5-second sessions.
And the metric they now report is the 5-second timeframe where the most shifting occurred. So it's not really cumulative anymore. Now, the recommended threshold by Google is to have a score of less than 0.1.
And you can check these in the same tools that I've already discussed.
So if we look at the example page's scores in PageSpeed Insights, you'll see that the majority of page loads are way off the mark.
Now, if you want to actually see these layout shifts, you can scroll to the bottom of the page and click on “Avoid large layout shifts” to see the exact parts that are affected.
Fixing Cumulative Layout Shift (CLS)
Now, the most common causes of CLS are images without dimensions, ads, embeds, and iframes without dimensions, dynamically injected content, and when fonts or styles are applied too late in the code.
Fixing any of these issues without dimensions is pretty easy. For images and videos, just add width and height attributes to your elements.
Alternatively, you can use CSS aspect ratio boxes.
For ads, embeds, and iframes, you can create static elements to reserve space for them.
For example, I'm sure you've seen ads that suddenly appear and push all the content down. Instead, you can define width and height attributes for the element.
Now, if you're unsure as to the exact parts of the page that are causing CLS-related issues, you can use webpagetest.org.
Just enter an URL and then run the test.
Next, find the film strip view and click it.
Make sure to set the thumbnail size to huge and the thumbnail interval to 0.1 seconds.
Finally, check the “Highlight layout shifts” box.
Now, as you scroll through the film strip, any frames with dashed borders are ones that had a layout shift.
And the parts that are highlighted in the frames are where layout shifts occurred.
If you want to learn more about optimizing CLS, you can refer to this article by web.dev.
3. Optimizing First Input Delay (FID)
Alright, the third and final metric is First Input Delay or FID, which measures interactivity.
The purpose of this metric is to get an understanding of a user's first impression of a site's interactivity and responsiveness.
It measures the time from when a user first interacts with a page to the time when the browser is able to respond to that interaction.
The recommended speed for FID is to stay under 137 milliseconds.
Issues That Causes Poor FID
Now, different types of interactions will include clicking a link or button, inputting text into a blank field, selecting a drop-down menu, or whatever.
So the four recommendations that Google provides is to:
- Break up long tasks.
- Optimize your pages for interaction readiness.
- Use a web worker.
I won't go further on this as First Input Delay is a field metric, meaning you can't get lab data for it. Google recommends using Total Blocking Time, but they measure completely different things.
Besides, editing JS is going to be very situational for each individual person's scripts.
Instead, you can refer to Google's guide on optimizing FID.
So with all of this said, the big question is: do Core Web Vitals really matter that much that you should put time, effort, and potentially money into it?
And like all answers to SEO questions, it depends.
Do I personally think that Core Web Vitals will be the difference in ranking #1 and #15?
No, I don't.
It's still very new and not all webmasters have the technical knowledge to optimize for these metrics.
Google's spoke person, John Mueller, said “Quality content still comes first.
Page experience becomes more important when there are multiple similar results.”
That's up for interpretation, but the way I see it is that Core Web Vitals will play as more of a tiebreaker than a “make it or break it” kind of ranking signal.
Let me know what you think about Google's new Core Web Vitals release. If you found this post to be helpful, check out my Core Web Vital Case Study.