As of this month, Core Web Vitals will become a part of Google's Page Experience
ranking signals.
And seeing as it's fairly new, there's a lot of misinformation and misunderstandings
around this topic.
So in this video, I'm going to explain exactly what Core Web Vitals are,
why they're important, and how to improve them for SEO.
Stay tuned.
[music]
Core Web Vitals are made up of 3 metrics that measure specific aspects of pagespeed.
And these metrics include visual load measured by Largest Contentful Paint,
visual stability of your web pages measured by Cumulative Layout Shift, and interactivity
which is done with First Input Delay.
Now, like many other Google ranking factors, the Core Web Vitals can't be looked at independently.
They're a part of Google's Page Experience ranking signals which also includes things
like mobile friendliness, safe browsing, HTTPs, and intrusive interstitials, ie. pop-ups.
No one knows exactly how big the impact will be seeing as it's still very young.
Regardless, it's probably still worth improving your Сore Web Vitals because pagespeed
improves conversions.
In fact, Google found that when a site meets the optimal thresholds for the 3 Core Web
Vitals metrics, users were 24% less likely to abandon page loads.
On top of that they saw a 22% decrease in new site abandonments and a 24% decrease
in shopping site abandonments.
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 includes real user metrics and is generated from 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.
You can see lab data in PageSpeed Insights, with the Lighthouse Chrome Extension and
in Chrome Dev Tools.
Now, there are 2 important things to note:
#1. The metrics are assessed at the 75th percentile of users.
For example, if we look at the PageSpeed Insights report for our SEO hub page, you'll
see that all Core Web Vitals metrics had greater than 75% good loads.
So it passes the Core Web Vitals assessment.
Whereas our guide on link building doesn't pass the Core Web Vitals Assessment because
one or more metrics have less than 75% good loads.
The second thing to note is that metrics are measured by device type, meaning
mobile Core Web Vitals will be assessed separately from 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.
So we're actually working on adding Core Web Vitals in our Site Audit tool, where you'll
be able see both field and lab test data for all your pages.
And you can use Site Audit free with an Ahrefs Webmaster Tools account.
Alright, so we're ready to start analyzing and optimizing pages for the 3 metrics.
But before you get started, it's important that you handle the other basics of Google's
Page Experience signals like mobile friendliness, HTTPS, etc.
Again, Core Web Vitals are a part of the page experience ranking signals.
Also, you should take care of basic pagespeed optimizations like having good hosting, caching
your content, compressing and lazy loading your images, and setting up a CDN.
All of these things can help improve your Core Web Vitals.
Now, 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.
Alright, so with the housekeeping stuff out of the way, let's dig deeper into each metric,
recommended thresholds, and get technical with solutions to common issues.
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.
For example, the LCP for our blog post on keyword research is the featured image.
Other common areas might be 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 aforementioned 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."
So for our keyword research guide, that would be our featured image.
Now, if you're working on a dev site that's not available to the public, you may want
to use Chrome Dev Tools.
To get started right click anywhere on the page you want to test and click Inspect element.
Make sure you have the Device set 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 - in this case,
our featured image
Click it, and you'll see more details below.
Now, according to Google, the 4 most common causes of poor LCP are slow server response
times, render-blocking JavaScript and CSS, slow resource load times, and
client-side rendering.
If you've implemented the basic optimizations for pagespeed 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.
So let's say a user enters a 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 want to spend our time focusing on
what actually happens during that processing stage.
Assuming you requested an HTML file, the browser first needs to parse the contents, which basically
means to extract the code into bits and pieces.
And some of these bits and pieces are going to be links to resources like images, CSS
and JavaScript files.
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 on 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:
images, CSS, and JS files.
Let's start with images.
Aside from the things that I've already mentioned like lazyloading and compression, preloading
images can significantly reduce page load times.
And 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.
This topic goes pretty deep, so I'll leave a link to this great article on preloading
responsive images if you want to learn more.
As for CSS files, there are a few things you can do.
#1. Minify them.
Minification removes all unnecessary characters from source code which leads to smaller file
sizes and faster load times.
#2. In-line your critical CSS for above-the-fold content.
This might include your website's font, viewport settings, background color, and an H1 style
to name a few.
Doing this will allow your viewers to see content above the fold before all of those
round trips are completed in the processing stage we talked about.
And #3. 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 Run command.
Then search for Show Coverage.
Click the Reload button here, and you'll be able to see the CSS and/or JS that hasn't
been executed in red.
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.
Now, for JavaScript, you can do pretty much the same things.
Minify it where it won't break your site and remove non-critical JS.
Now, two other things worth doing is to defer or asynchronously load JS where appropriate.
And you can do this by using the defer or async attributes in your script tags.
Now, to better understand these attributes, you need to understand what happens when
JavaScript files are in your HTML code.
Assuming we have a regular tag without any attributes, the HTML file will start parsing
until it hits that script file.
Parsing is then paused while the script is downloaded and then executed.
Then the remainder of the HTML contents gets parsed.
So as a result, the JavaScript is blocking and will delay LCP.
Now, if you add the async attribute to the script tag, then the JS file can actually be
downloaded while the HTML is parsing.
And even though asynchronously loaded JS can still block LCP, it ensures that important
scripts are run earlier.
Finally, is the defer attribute.
When added, JavaScript files will be downloaded while the HTML is parsed.
But JS will only be executed after the parser has completed.
So it's not blocking.
Very generally speaking, you want to use the async attribute for scripts needed earlier
in the page load and defer anything that can wait until later.
Now, if you don't quite have the technical skills to do this on your own, then it may
be worth hiring a developer and/or technical SEO who can help.
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 had 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, but I guess that's besides the point.
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.
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.
In this case, they've added placeholder text, which eventually changes to an ad once rendered.
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 a 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, I'll leave a link to an article in
the description below.
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.
For example, if you look at this gif from Requestmetrics.com, you'll see that they've
created what appears to be a simple script.
Click the button and it stops running the heavy JavaScript.
But the time between clicking and completing the script took over 1.4 seconds, which isn't
ideal for users.
The recommended speed for FID is to stay under 100 milliseconds.
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.
Now, the main cause for slow FID is heavy JavaScript execution.
Basically, a user is trying to interact with the website, but the browser isn't able to
respond because the main thread is busy doing something else.
So the four recommendations that Google provides is to break up long tasks, optimize
your pages for interaction readiness, use a web worker, and reduce JavaScript execution time.
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.
Plus editing JS is going to be very situational for each individual person's scripts.
Instead, I'll leave a link to Google's guide on optimizing FID in the description.
So with all of this said, the big question is… do Core Web Vitals really matter that
much that you should put the time, effort, and potentially money into?
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.
And I highly doubt that Google will be penalizing Karen's fashion blog or Joey's recipe site
because their ads moved the content a bit.
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 and if you found
this video to be helpful, make sure to like, share, and subscribe for more actionable
SEO and marketing tutorials.
I'll see you in the next one.