Core Web Vitals: A Plain English Guide

Core web vitals are three specific measurements Google uses to judge how visitors experience a web page. They focus on loading speed, interactivity, and visual stability, which are the things real people actually notice when a page feels quick or sluggish. If you run a UK small business website, understanding these metrics matters because Google has confirmed they influence search rankings, particularly for mobile searches.

The phrase gets thrown around a lot in technical SEO circles, often wrapped in a fog of acronyms. We think the topic is far simpler than the jargon suggests. Once you know what each metric measures, where to find your scores, and what tends to cause problems, the fixes are usually within reach. You do not need to be a developer to act on most of them.

This guide walks through what core web vitals are, what good scores look like, and the practical steps you can take to improve them. We will avoid marketing fluff and stick to what genuinely moves the numbers.

What Core Web Vitals Actually Measure

Core web vitals are a set of three user-experience metrics that Google rolled out as official ranking signals in 2021. They are calculated from real user data, known as field data, gathered from Chrome browsers, as well as lab-based simulations. Both matter, but the field data is what Google uses for ranking decisions.

• Largest Contentful Paint (LCP): how long it takes for the biggest visible element on the page to appear. This is usually a hero image, headline, or video. It is a proxy for perceived loading speed.
• Interaction to Next Paint (INP): how quickly the page responds when a visitor clicks, taps, or types. INP replaced First Input Delay in March 2024 and measures the worst interaction delay across the session, not just the first one.
• Cumulative Layout Shift (CLS): how much the page layout jumps around as it loads. A common example is text suddenly shifting down because an image or advert loaded above it.

What Good Scores Look Like

Google publishes thresholds for each metric, expressed as a percentile of real user experiences. To pass, you need roughly 75 percent of page loads to meet the good threshold. Anything below that is classed as needs improvement or poor.

• LCP: good is 2.5 seconds or faster, needs improvement up to 4.0 seconds, poor above 4.0 seconds.
• INP: good is 200 milliseconds or faster, needs improvement up to 500 milliseconds, poor above 500 milliseconds.
• CLS: good is a score of 0.1 or less, needs improvement up to 0.25, poor above 0.25.

These are measured at the 75th percentile, which means 75 percent of your visitors should hit those numbers for you to be classed as good overall. If you are on the cusp, even a small change, such as compressing a hero image, can swing you from needs improvement to good.

How to Measure Your Own Core Web Vitals

You have two main options: field data based on real visitors, and lab data from a simulated visit. Both are useful but answer different questions. Field data shows how your actual audience experiences the site. Lab data helps you reproduce and debug specific issues on demand.

For field data, the easiest starting point is Google Search Console. The Core Web Vitals report under the Experience section shows which URLs on your site pass and fail, broken down by mobile and desktop. For lab data, PageSpeed Insights combines lab and field results in one place and gives specific recommendations. We have also built a small set of free diagnostic tools on our tools page that pull the same data into a simpler view, which is useful if you only have one or two pages to check.

When reading the results, pay more attention to the field data than the lab data. Field data reflects real conditions, including older phones and patchy mobile signal, which is the experience Google is actually measuring for ranking purposes. If your lab score is great but field data is poor, you almost certainly have a real-world performance problem that lab tools are not capturing.

Common Causes of Poor Scores

• Slow LCP is usually caused by oversized hero images, slow hosting, render-blocking JavaScript and CSS, missing browser caching, and slow server response times.
• Poor INP is typically caused by heavy JavaScript execution on the main thread, long-running event handlers, and third-party scripts such as chat widgets, analytics tags, and ad scripts that block the main thread.
• High CLS usually comes from images without width and height attributes, adverts or embeds that load late, web fonts that swap and reflow text, and dynamic content injected above existing content.

For most small business sites we audit, the biggest offenders are unoptimised images and a handful of third-party scripts, particularly marketing tags, chatbots, and analytics platforms. Tackling those two areas alone often moves a site from poor to good on all three core web vitals.

Practical Fixes You Can Make This Week

You do not need a full rebuild to improve core web vitals. Below are the changes that deliver the most impact for the least effort, ordered by what we would typically tackle first.

• Compress and resize your hero images. Serve images in modern formats such as WebP or AVIF and make sure they are no larger than the size they are displayed. A 3MB photograph on the homepage is a common culprit.
• Add width and height to every image. This lets the browser reserve space and prevents layout shift as images load. It is a five-minute fix in most content management systems.
• Defer non-essential JavaScript. Chat widgets, marketing pixels, and review platforms can all be loaded after the main content using the defer or async attribute.
• Use a content delivery network (CDN). This serves your site from a location closer to your visitor, which improves LCP for users outside the UK.
• Audit your web fonts. If you use custom fonts, set font-display: swap in your CSS so text shows immediately with a fallback font, rather than waiting for the custom one to load.
• Review your hosting. Cheap shared hosting often produces slow server response times that drag down LCP. If your Time to First Byte is over 800 milliseconds, the host is likely the bottleneck.

After making changes, give the data a few weeks to refresh. Field data is a rolling 28-day window, so a fix made today will not fully show up in Search Console for almost a month. Lab data in PageSpeed Insights updates much faster and is useful for sanity-checking the impact as you go.

When to Bring in Help

If you have made the changes above and your field data is still in the poor range, the problem is usually deeper, such as a theme that loads too much JavaScript, a CMS configuration issue, or a hosting environment that cannot keep up. At that point a technical audit tends to pay for itself. We look at your site end to end, identify what is actually slowing it down, and give you a prioritised list of fixes. If you would like us to take a look, you can get in touch through our contact page or read more about our SEO optimisation service to see how we approach this kind of work.

Good core web vitals are less about chasing a perfect score and more about removing the rough edges that frustrate real visitors.