How to Improve your Core Web Vitals

When it comes to search engine optimization (SEO), we’re all somewhat beholden to the All-Mighty Google. Placing on the first page of Google has significant implications for site traffic, conversions, and overall business performance.

While there are many factors that contribute to your Google ranking factor, a newer addition to their algorithm that determines placement is Core Web Vitals. While we don’t know exactly how much weight these vitals carry when it comes to placement because Google never publishes its exact algorithm, we do know they are an important factor and need attention to optimize SEO. 

Beyond just Google telling us they are important; Core Web Vitals also ensure site visitors have a consistent user experience on your website. Research tells us that more than 55% of online shoppers between the ages of 18-24 think slow website loading times are intolerable which means failing Core Web Vitals = lost conversions and lost sales. 

What are Google Core Web Vitals 

Core Web Vitals are three different metrics that offer a trailing 28-day measurement of your website’s user experience and can be monitored through Google Analytics. Google evaluates your site’s performance on the three metrics as part of their Google page experience signals which play a factor in SEO. The three measurements include: 

• First Input Delay (FID): Measures inactivity
• Cumulative Layout Shift (CLS): Measures visual stability
• Largest Contentful Paint (LCP): Measures loading performance

It is important to note that while these are the three current measurements Google uses, these metrics may change at some point in the future as new core vitals are added and monitoring tools get more sophisticated. 

So, if the above three Core Web Vitals are what Google does care about, what don’t they care about? Sadly, Google does not care about a site’s PageSpeed Performance score. For more than a decade, developers have been working to improve this Pagespeed Performance score on their sites, but these efforts are targeting the wrong metrics. Improving Performance score is no guarantee of improved Core Web Vitals: increasing that number provides only the illusion of progress towards improving site performance. Read more about this directly from Google. 

 Passing Core Web Vitals Metrics 

Core Web Vitals measure data from real users and are based on the experience of 75% of your site visitors. To earn a passing score, you must deliver the same, consistent user experience to at least three-fourths of site visitors regardless of device or location. Passing scores for the three measurements are: 

• First Input Delay (FID) of less than 100 milliseconds 
• Cumulative Layout Shift (CLS) of less than .1
• Largest Contentful Paint (LCP)  within the first 2.5 seconds

The good news when it comes to optimizing your Core Web Vitals, is two of the three are pretty straightforward to improve. The third can be a bit tricky so let’s tackle the easiest first. 

Interested in improving your Core Web Vitals?  Learn more about solutions for a poor performing site. 

Improving First Input Delay 

FID measures the time from when your user first tries to interact with the site to when that interaction actually happens. The goal of this metric is to capture if a site has too much JavaScript that is killing performance. However, FID is always super low. If for some reason your site’s FID score is more than 100 milliseconds, one easy fix is to delay unnecessary JavaScript loading for a few seconds. 

Google seems to have taken notice, however, that this metric is super easy to pass and may not be doing a good job at capturing its intent. There is a new metric in the Google laboratory right now called Interaction to Next Paint (INP) which is a new way to track JavaScript overhead. At first look, it seems to be much more accurate and useful. Don’t be surprised if FID is swapped for INP in Google's core vital metrics in the coming months. 

Improving Cumulative Layout Shift 

This second Core Web Vital measures how much elements on the page shift as the page is rendering. Images, iframes, ads, or really any embedded elements can impact your CLS score. Cumulative layout shifts tend to happen because one of three reasons: 

1. JavaScript modifications to the page

   If everything on your page is shifting down when it loads, this is likely your issue. Two big reasons for these whole-page shifts are cookie consent bars and pop-up bots. Two easy fixes are: 

   • Put a couple of seconds delay before your consent bar or bot loads onto the screen. Users won’t even notice.
   • Create your consent bar to be a part of your site and then hide itself if it is part of the rendered content.

2. HTML without size information of the element

   This is an easy fix.  If your CLS score needs improvement, ensure all of your images have set dimensions as part of your html.

3.  Font loading

   This is the least likely to impact your CLS score, however, if you have a ton of text in a variety of different styles or sizes, and you’ve verified the previous two reasons aren’t causing your problem, you might need to make edits to minimize the number of different font choices. 

    

Improving Largest Contentful Paint 

We’ve tackled the two easiest fixes first, which leaves us with the worthy adversary that is largest contentful paint. Improving your LCP score is entirely possible, but it’s going to make you work for it. 

LCP measures the time in the loading process the largest element renders. To pass LCP, the largest element must have a loading speed of fewer than 2.5 seconds. For most sites, the largest elements are always images. 

To improve your LCP score, we must first work backward to evaluate what we can remove from the initial loading process. We must prioritize what is critical and must be loaded within the first 2.5 seconds and then what can wait until second three. Once we identify those elements, we can start to tackle improving our LCP by working through the below seven steps. 

• Critical images should be a part of your site’s html so they begin loading immediately. There is no room for delay in the 2.5 seconds.
• Lazy load non-critical images that appear below the fold. If you have a taller page, there will be more images you can lazy load but make sure you aren’t accidentally lazy loading your LCP.
• Use a browser-native attribute to lazy load your images and avoid a JavaScript or CSS headache.
• Avoid or defer megamenu images. All images in your navigation bar are a part of your html document, however, these are not critical elements and because of the way a browser reads your page (top to bottom), it is going to see those images first. You can add them dynamically after the page has loaded.
• Make sure you are loading the right imagery in the size you need for the user’s devices. Create an SRCSET to specify different image variants for different device widths to ensure you aren’t wasting valuable bandwidth sending a 2000x wide image to an outdated mobile device.
• Use an online tool to get the code needed such as http://www.responsivebreakpoints.com/
• Make sure that code is added before the browser sees the image
• DO NOT use an asynchronous JavaScript library to generate your SRCSETs on the fly otherwise, you will get a massive CLS.
• Use a content delivery network (CDN) to avoid latency. As a nice perk of using a CDN, most will handle image conversions for you, but you will still need to build your own SRCSETs.
• When possible, ensure you are delivering images in modern formats. As a general rule:
• PNG and JPG are horrendous
• Webp is pretty good
• Avif is amazing
• Be on the lookout for jpegXL…it’s coming soon!
• JavaScript is not a friend of rendering performance. If your JavaScript is not writing content to the screen, it does not belong in the early stages of the loading cycle.
• Simply changing your JavaScript to “asynchronous” or “defer” does nothing to help your LCP score. It must be delayed.
• A great tool to help you delay unnecessary JavaScript is Google Tag Manager Page Trigger. The tool helps you make informed decisions on what needs to load and when.

The Core Web Vitals environment is constantly changing. Google is continuously making minor algorithm updates. New core vitals are being developed and will launch soon. Monitoring tools are consistently improving. Browsers such as Google Chrome and Safari are getting smarter and more responsive.  

All of that is to say, core web vitals require constant vigilance. Once you get your metrics to where they need to be to pass, it’s important that you put a regular monitoring process in place. A simple daily check-in on performance will help catch if anything gets broken and avoid having to dig out of a hole if your performance dips, unnoticed. With these Core Web Vitals metrics, Google has challenged us to develop webpages that offer experiential user interaction while demanding effective website performance.  

Optimize Your Core Web Vitals Score 

If you’re looking for more information on how to earn your passing grade, check out our recent master class “Strategies to Improve Your Site Speed and Core Web Vitals”. Or, if you’re ready to take a Core Web Vital assessment off your plate, learn about our Core Web Vitals performance report.