Core Web Vitals Explained: What Your Site's Performance Score Is Actually Telling You

Most business owners have seen their website score in Google's PageSpeed Insights at some point. The number is rarely what they hoped for, and the list of recommendations underneath reads like it was written for software engineers. This article explains what the underlying metrics actually mean, why they have real consequences for both search rankings and revenue, and how to check your own site without needing a developer to interpret the results.

The three metrics are , , and . Each measures a different dimension of the user experience, not just how fast files arrive from the server.

measures how long it takes for the most prominent visible element on the page to fully load. That is usually the main image, a large heading, or a background section. Google's threshold for a good score is under 2.5 seconds. Above 4 seconds is classified as poor. When LCP is slow, visitors see an incomplete page for several seconds before anything meaningful appears. Research consistently shows that a large share of users abandon a page before it finishes loading if the wait exceeds about 3 seconds.

measures visual stability during loading. It quantifies how much visible content unexpectedly shifts position while the page is still rendering. The most recognisable experience of high CLS is trying to tap a button on a mobile site and having the page jump so that you tap something different instead. A good score is 0.1 or below. Common causes include images loaded without defined dimensions, ads or embeds that inject late into the layout, and web fonts that display placeholder text before the real font loads in.

measures how quickly the page responds to user interactions such as clicks, taps, or key presses. It captures the delay between when a user does something and when the browser visually acknowledges it. A good score is under 200 milliseconds. Slow INP makes a site feel unresponsive or broken even if it appears to have loaded. It is most often caused by heavy JavaScript running in the background that occupies the browser's main thread and prevents it from responding to input.

For businesses where the website is a primary channel for generating leads or direct sales, this is not a minor concern. A meaningful performance gap between a site and a competitor's site compounds over time. Fewer visitors reaching the contact form or checkout means fewer enquiries or purchases, consistently, every day.

It is also worth noting that mobile performance is scored separately from desktop. A site that loads quickly on a fast broadband connection may perform significantly worse on a 4G mobile connection, which is how a large share of actual visitors access it. Google's ranking algorithm uses mobile performance as the primary signal, not desktop.

There are two main tools for measuring . Neither requires technical knowledge to use, and both are free.

PageSpeed Insights is Google's official performance measurement tool. You enter a URL and receive a score from 0 to 100, along with a breakdown of each metric and the specific issues contributing to any problems. The score is divided into lab data, a simulated test run under controlled conditions, and field data, which reflects real measurements from actual users drawn from the Chrome User Experience Report. Field data is the more meaningful of the two for assessing real-world performance. The tool is available at pagespeed.web.dev and requires no account or setup.

Chrome's built-in developer tools include a Lighthouse tab that runs the same performance tests locally and provides more granular detail about what is causing each issue. To use it: open Chrome, navigate to the page you want to test, press F12 or right-click anywhere on the page and select Inspect. In the panel that opens, choose the Lighthouse tab, select Performance, and click Analyze page load. The resulting report identifies each problem down to the individual file or element responsible, which makes it useful for understanding the root cause of an issue rather than just knowing that a problem exists.

Unoptimized images are the single most common cause of slow LCP scores. A photograph exported at full resolution from a camera and uploaded without compression or resizing can be 4 to 10 times larger than necessary for web use. Modern image formats like WebP and AVIF deliver the same visual quality at significantly smaller file sizes compared to JPEG or PNG. Images should also be sized to the dimensions at which they are actually displayed rather than the original capture resolution.

Excessive JavaScript is the primary driver of poor INP scores and contributes heavily to slow LCP. Website builders including , , and ship large JavaScript bundles to the browser regardless of what is actually on the page. This code must be downloaded, parsed, and executed before the page becomes interactive. Custom-coded sites built with frameworks like allow developers to ship only the JavaScript a specific page actually needs, which is one reason performance scores tend to differ substantially between builder sites and custom builds.

Slow server response time, measured as Time to First Byte (TTFB), delays every metric that follows because no content can arrive until the server responds. Cheap shared hosting, servers located geographically far from the visitor, and unoptimized server configurations all increase TTFB. A content delivery network (CDN) can partially offset this by caching static content and serving it from a location closer to the user.

Third-party scripts are a frequently overlooked cause of performance problems. Live chat widgets, analytics trackers, cookie consent tools, marketing pixels, and embedded video or social media content all add external network requests that the browser must complete before the page is considered fully loaded. They also introduce JavaScript execution that the site owner cannot control or optimise, which can significantly worsen INP.

Consistently scoring above 90 on mobile in PageSpeed Insights requires decisions made during the initial design and development of a site, not patches applied afterward. Image handling needs to be part of the build workflow. JavaScript needs to be deliberate and scoped to what each page actually uses. Hosting infrastructure needs to be appropriate for the site's expected load. Font loading needs to be configured to avoid layout shifts.

This is one of the structural advantages of custom-coded sites over platform-based builders. When performance is treated as a requirement from the start, the technical choices made throughout development support it. Adding performance improvements to a site built on a platform that was not designed with that goal in mind is possible to some degree, but the ceiling is set by the platform. Some causes of poor scores cannot be fixed without moving away from the platform entirely.

The practical benchmark worth targeting is a score consistently above 90 on mobile in PageSpeed Insights for the pages that receive the most traffic, typically the homepage and any page with significant organic search volume. Reaching that threshold on every page of a large site is a meaningful engineering undertaking. Reaching it on the pages that matter most is achievable for most professionally built, custom-coded sites.