What Are Core Web Vitals? Here’s What You Actually Need to Know

When I think of Core Web Vitals, I’m immediately reminded of this time when I discovered one of my websites had been taking over 30 seconds to load a simple contact page. All people wanted to do was send me an email, but they experienced the equivalent of dial-up internet in the 1990s. If only I had known about Core Web Vitals, I might have noticed this performance issue earlier.

Core Web Vitals are a series of three metrics specifically established by Google to analyze and quantify not only performance but the real-world user experience of any website on the internet. Google uses Core Web Vitals as part of its ranking criteria.

Considering Google takes Core Web Vitals into account for rankings, everyone with a website should know what these metrics are. I like to think of them as a health checkup. When I go to the doctor, she checks my blood pressure, weight, and heart rate to see my baseline health. Google uses Core Web Vitals — like cumulative layout shift, largest contentful paint, and first input delay — similarly, but for websites. And I’m here to explain how they work.

Google created Core Web Vitals to make the internet a more useful place. They’re designed to minimize poor user experiences, to help website owners improve performance, and to help Google itself choose where to rank your website.

The three Core Web Vitals, which I’ll explain in detail below, include:

• Largest Contentful Print
• Interaction to Next Paint/First Input Delay
• Cumulative Layout Shift

You’ll learn about these metrics more, but here’s the simplest way I like to describe them: Core Web Vitals quantify how users experience your website. So, if someone has to wait around for a page to load or a certain element on your homepage to show, these Core Web Vitals will explain that it’s a poor experience. Moving forward, I’ll dive deeper into what core metrics like LCP and CLS mean.

Largest Contentful Paint (LCP)

Largest Contentful Paint, or LCP, is a Core Web Vital that measures how long it takes for the largest content element on your webpage to appear visibly on a user’s screen. I like to draw parallels to a working restaurant when talking about Core Web Vitals since it allows for a more visual presentation of each metric. LCP, in the realm of a restaurant, is like the amount of time between the host seating you and your main course arriving.

The reason I say “main course” is that the “largest” contentful paint is often the highlight of a webpage. I’m talking descriptive videos, image banners, or other media meant for the user to consume right away. But, just like waiting too long to get your main course at a steakhouse, your customer becomes disappointed and maybe even leaves if that LCP time goes too high.

In general, I recommend a maximum LCP of 2.5 seconds, but for developers, that’s still considered painfully slow. Regardless, you shouldn’t rely on a visual analysis of how long it takes for your main course to appear on a website because you may not realize that it’s actually still loading in the background and could take several more seconds, essentially slowing down the entire experience.

Interaction to Next Paint (INP) — Formerly First Input Delay (FID)

Whereas LCP measures the loading time of your largest content, First Input Delay (eventually changed to “Interaction to Next Paint.” since Google now measures all interactions on a page instead of just the first interaction) puts a number on your site’s interactivity potential. The results tell you the time between a user interaction and when your site successfully responds to that interaction.

Here are examples of what INP measures:

• The time between clicking a button and seeing its results
• How long it takes for a menu to toggle open after a user scrolls over it
• The time lag between selecting an accordion tab and it expanding to show content

Going back to my restaurant comparison, INP is like the server at your restaurant. That worker responds to your requests and interacts with you — they refill your drink, bring your food, take your order, and give you the check. If the server takes a while to respond to requests, it’s similar to a page, menu, or toggle not appearing after a user pushes a website button.

Cumulative Layout Shift (CLS)

Imagine you’re sitting at a restaurant, and the server keeps rearranging your table while you’re trying to eat. They shift your drink a few inches now and then, and they switch the placement of your utensils without asking. Sounds like something that might drive you crazy, right? The same can be said for shifting online interfaces. They’re disorienting and annoying.

That’s why I recommend using Cumulative Layout Shift (CLS). This Core Web Vital measures visual stability on your website.

Your CLS score might increase (which is a bad thing) if:

• A banner image changes too frequently
• Buttons move around the page
• Text frequently adjusts to different sizes (often in a failed attempt to maintain mobile responsiveness)

Although it depends on the type of website you have, I suggest maintaining a CLS score of less than 0.1. This ensures your website minimizes movements visible to the human eye.

I still remember when Google introduced Core Web Vitals with its famous “Page Experience” update. It gave an incredible amount of ranking power to website owners who adopted good Core Web Vitals to boost their scores. In short, Google made Core Web Vitals part of its overall ranking mechanisms, meaning you could simply address any issues in those areas to beat out your competition.

What’s most interesting, though, is that Core Web Vitals had a ripple effect across the internet, and it wasn’t all about rankings.

Here’s why Core Web Vitals have mattered so much to websites:

• Mobile-first indexing: Google now puts a strong focus on trying to better index sites with strong mobile interfaces. Core Web Vitals are key for mobile interfaces since performance issues are often far worse in the mobile experience.
• Competitive advantage: If you’re in a competitive niche, it’s difficult to make your brand visible. But Core Web Vitals gives you a chance to beat out the competition even if your content is similar.
• User experience signals: Google demotes websites in its rankings for having poor user experiences. A poor user experience often correlates with sub-par Core Web Vitals. For instance, you might see low time-on-page or high bounce rates if your Core Web Vitals struggle.
• Direct rankings: Google rarely tells the world exactly how it ranks websites. That’s not true for Core Web Vitals, though. Google has specifically stated that Core Web Vitals come into play for rankings, making it one of the few concrete ranking signals I’ve ever seen.

With my own sites, I’ve experienced increases in traffic of around 10-20% after I’ve spent more time optimizing my Core Web Vitals scores. What’s cool is that you don’t even have to mess with your content strategy.

It all sounds wonderful: leave your content the way it is, yet still improve your search rankings. But I should warn you — your website is unique, so no blog post is going to tell you exactly what you need to change about your site to improve its Core Web Vitals. That’s where measurement tools come into play.

Tools to assess CWV performance:

I find it’s best to start with Google PageSpeed Insights, especially since it comes with the Chrome User Experience Report, too. But really, you should activate and explore all these tools. And do your best to focus on field data from each tool, since that uses data about users who actually interact with your website (instead of simulations or comparisons with other sites).

As I mentioned before, it’s best to run your website through tools like Google PageSpeed Insights to figure out exactly what’s needed to improve your Core Web Vitals scores. You’re best off avoiding generalized tips on how to improve your Core Web Vitals.

Having said that, I’d like to discuss the most common recommendations you’ll find from tools like Google PageSpeed Insights and Lighthouse. This way, you’ll know what they mean and how to approach them.

Optimizing LCP (Loading Performance)

When Google PageSpeed Insights, and any other tool you use, recommends that you optimize LCP, it says you should fix the loading performance of your site.

Here are some ways to do so:

1. Reduce the server response times: I usually turn to caching or a CDN to start, but sometimes it pays to opt for a faster hosting provider.
2. Optimize videos and images: My favorite way to optimize images is by using next-gen image formats like WebP instead of PNG or JPG. I also recommend compressing images and activating lazy loading.
3. Minimize render-blocking resources: JavaScript and CSS files that block rendering can severely delay LCP. To fix it, consider deferring those files or even using tactics like splitting code bundles, using async attributes, and moving critical CSS inline.

I’ve worked with clients who lowered their LCP from over five seconds to under two seconds, all by optimizing images or using a CDN. I also can’t stress the importance of automation. You can automate image optimization with caching, CDNs, lazy loading, and even the minimization of render-blocking resources with plugins.

Reducing INP/FID (Interactivity & Responsiveness)

To me, poor interactivity is often the easiest blunder to identify on a website. It makes sites feel broken, especially when I can’t click a button or a menu sends me to the wrong page.

Below, I’ve outlined some common ways to improve INP (formerly FID):

1. Minimize JavaScript execution time: I’ve seen excellent results by removing unused JavaScript and chopping up long tasks into much smaller, asynchronous tasks.
2. Use browser caching and optimize third-party scripts: Ideally, you remove all low-value third-party scripts. I also think it’s important to set appropriate cache headers when you have resources that don’t change much.
3. Implement lazy loading for resources: You don’t have to lazy load everything. I focus on “below-the-fold” content.

The effectiveness of your interactivity relies on milliseconds. A user will notice a button that takes just a few milliseconds longer to load. I’ve seen conversion rates skyrocket when I’ve simply reduced interaction delays from 400 milliseconds to about 100-150 milliseconds.

Fixing CLS (Visual Stability)

Although I can identify interactivity issues faster, nothing makes me more annoyed than visual stability problems. I’m talking about jittery images, flashing buttons, and unprompted movement from menus.

If you need to fix your CLS (Cumulative Layout Shift) scores, here are my suggestions:

1. Set explicit width and height for images and iframes: I tend to lean on aspect ratio boxes in CSS, but you’re more than welcome to use iframes or even CSS containment.
2. Use CSS animations responsibly: In my experience, it’s best to avoid layout changes that happen due to user interaction. I also suggest avoiding the “will-change” property for items you intend to animate. Here’s the golden rule, though: always go with “transform” animations instead of those that affect your layout properties.
3. Load ads and embeds in a structured way: By structure, I mean using placeholder containers, fixed-size ad containers, and reserved space for ads.

Whenever I’ve implemented these types of changes, I’ve been able to decrease CLS scores by as much as 0.30, which is huge for CLS. For instance, I’ve witnessed scores drop from very problematic 0.30+ values to below 0.05 metrics.

I’ve optimized sites using Core Web Vitals for many years. During those years, it pains me to see the same mistakes made over and over. In this section, I want to guide you away from those common pitfalls.

Here’s what to avoid:

• Overloading pages with heavy scripts: I’ve seen sites try to load heavy scripts for marketing and tracking long before any visible content appears. That’s not the way it should go. Always put your content first. Otherwise, you risk hurting your user experience. I suggest completing script audits regularly to figure out if you really need to run certain scripts before content loading, and if they need to run on every page of your site.
• Ignoring mobile performance: I would still say that most website owners I encounter primarily check how their sites run on desktop environments. They completely neglect mobile, even though Google has a mobile-first indexing system now. To avoid this issue, always run tests on mobile devices. Google PageSpeed Insights has a mobile test, and you should always test on real mobile devices, not just small windows on your desktop computer.
• Failing to test real-world user experience: Although lab tests give you important data, nothing’s as strong as field testing. This means testing on real mobile devices, using throttled connections to simulate a real-world mobile experience, and testing desktop sites on a wide range of computers.

I’ve never worked on a successful website that left performance optimization as a one-time project. You should regularly maintain website performance by using Core Web Vitals. That’s particularly true whenever updating your site.

Google constantly develops its system of Core Web Vitals as it forms a better understanding of the ideal user experience. For instance, the change from FID to INP shows Google wants a more in-depth way to measure interactivity and responsiveness. That change came in 2024.

I would argue that we’re in store for further adjustments as well. I expect new metrics related to data usage and privacy. I’d also assume Google will introduce more granular interaction metrics that measure the entirety of the user journey instead of just that first page the user lands on.

Regardless of the future, I implore you to stay ahead of the curve with performance optimization. Use Core Web Vitals to improve the performance of your site, and make it part of your regular audits. I also like to recommend automating this monitoring of Core Web Vitals to make it as easy as possible. Good luck with your optimization strategies!