Core Web Vitals: How to Optimize Them for SEO

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. Core Web Vitals are made up of three metrics that measure specific aspects of page speed. 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 include things like mobile friendliness, safe browsing, HTTPS, and intrusive interstitials, i.e. popups. 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 Core Web Vitals because page speed improves conversions. In fact, Google found that when a site meets the optimal thresholds for the three Core Web Vitals metrics, users were 24% less likely to abandon page loads. On top of that, they saw a 22% decrease in news 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 three 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 DevTools. Now, there are two important things to note. Number one, the metrics are assessed at the 75th percentile of the 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 to 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 three 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 page speed 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 webpage 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 2.5 seconds. To check LCP for a page, you can use any of the aforementioned tools like PageSpeed Insights, the Lighthouse extension, or Chrome DevTools. 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 dates. 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 DevTools. 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 four 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 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. 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 the 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 of 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 three main types of resources. Images, CSS, and JS files. Let's start with images. Aside from the things that I've already mentioned like lazy loading 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. Number one, minify them. Minification removes all unnecessary characters from source code, which leads to smaller file sizes and faster load times. Number two, inline 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 number three, remove unused CSS and defer non-critical CSS. To find CSS that your page isn't using, go to Chrome DevTools, click on the vertical ellipsis, and hit Run command. Then search for Show Coverage. Click the reload button here and you'll be able to see the CSS and org.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 script 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 get 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. Alright, 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 time frame 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 Filmstrip 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 Filmstrip, 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 occur. 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 a website, but their 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 number 1 and number 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 move the content of it. 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.