Core Web Vitals are three measurements of what a page actually feels like to use: how long the main content takes to appear, how quickly the page responds when someone interacts with it, and how much the layout jumps around while it loads. This Core Web Vitals score calculator takes your three values, grades each one against the published thresholds, and combines them into a single weighted score so you can track progress between audits.
Arb Digital's development team uses a scoring view like this because the pass or fail verdict alone is a blunt instrument. A page failing at 4.1 seconds and a page failing at 9 seconds get the same label and need completely different amounts of work — a score shows the distance you still have to travel.
What This Core Web Vitals Score Calculator Does
Enter Largest Contentful Paint in seconds, Interaction to Next Paint in milliseconds, and your Cumulative Layout Shift value. Each is graded against the official thresholds — LCP good at 2.5 seconds or below, INP good at 200 milliseconds or below, CLS good at 0.1 or below — and converted to a 0–100 sub-score that reflects how far into the good, needs-improvement, or poor band the value sits.
The tool reports the pass or fail verdict exactly as it is defined: all three metrics must be in the good band for a page or origin to pass. It also produces a weighted composite so you can compare one audit to the next, and takes Time to First Byte and First Contentful Paint as diagnostics, since a slow LCP is very often a server problem rather than a rendering one.
How to Use It
- Get field data, not lab data. Use the Core Web Vitals report in Search Console or the field section of PageSpeed Insights. Both draw on real user measurements rather than a simulated load.
- Use the 75th percentile figure. That is the value the assessment is based on: three-quarters of visits must be at or better than the threshold.
- Enter each metric in its own unit. LCP in seconds, INP in milliseconds, CLS as an unitless number — mixing units is the most common input error.
- Add TTFB and FCP if you have them. When LCP is poor and TTFB is above roughly 800 milliseconds, the problem starts on the server rather than in the browser.
- Record the score after each change so you can see whether an optimisation moved the needle, and by how much.
The Formula: Thresholds and Weighting
The three thresholds come from Google's published definitions, documented on web.dev's Core Web Vitals overview: LCP at 2.5 and 4.0 seconds, INP at 200 and 500 milliseconds, CLS at 0.1 and 0.25. Values at or below the first number are good; between the two, needs improvement; above the second, poor.
Each metric is mapped onto a sub-score by band. A value inside the good band scores 90 to 100, scaled by how far below the threshold it sits. A value in the needs-improvement band scores 50 to 90, and a poor value scores below 50, falling toward zero as it worsens. The composite is then:
Score = 0.40 × LCP score + 0.40 × INP score + 0.20 × CLS score
Take the defaults: LCP of 3.2 seconds sits in the needs-improvement band and scores 71; INP of 240 milliseconds scores 85; CLS of 0.08 is good and scores 92. The weighted total is (0.40 × 71) + (0.40 × 85) + (0.20 × 92) = 81 — yet the page still fails the assessment, because two of the three metrics are outside the good band. That divergence between a respectable score and a failing verdict is exactly the situation this tool is designed to make visible. The 40/40/20 weighting is this calculator's own, chosen because loading and responsiveness dominate perceived experience; it is not published by Google.
Field Data and Lab Data Are Not Interchangeable
A lab test loads your page once, on one simulated device, on one simulated connection, with no cookie banner, no logged-in state, and no third-party scripts that only fire for real visitors. Field data is collected from actual visits across every device, network, and location your audience uses. The two routinely disagree, and when they do, the field data is the one that counts.
The 75th percentile is the second thing people miss. Your median visitor might load the page in 1.9 seconds while the assessment fails, because the slowest quarter of your audience — older phones, weaker networks, distant regions — is where the threshold is measured. Optimising for the experience you have on a fast laptop on office broadband is optimising for the wrong quarter of your users.
A related consequence: pages with low traffic may have insufficient field data to be assessed individually and get grouped with similar URLs instead. If your report shows a group rather than a page, improvements to any page in that group can move the whole group's numbers.
What Actually Breaks LCP
Largest Contentful Paint measures when the biggest visible element — usually a hero image, a video poster, or a large block of text — finishes rendering. Four causes account for most poor results, and they arrive in a predictable order. A slow server response delays everything downstream. Render-blocking CSS and JavaScript in the head hold up the first paint. An unoptimised hero image, delivered at full resolution in a legacy format, takes seconds to arrive. And lazy-loading applied to the hero image itself defers the exact element being measured, which is the most common self-inflicted version of this problem.
Check TTFB first. If it exceeds roughly 800 milliseconds, no amount of front-end optimisation will fix LCP, and the work belongs in caching, hosting, or database queries. On a large site, the same server improvements also raise how many pages a crawler can fetch in a given window — worth modelling with the crawl budget calculator if crawl coverage is also a concern.
INP Replaced FID, and It Is a Harder Test
Interaction to Next Paint became a Core Web Vital in March 2024, replacing First Input Delay. The change matters because FID only measured the delay before the browser began processing the first interaction, while INP measures the full latency of interactions throughout the page's life — from the tap or click, through the event handler running, to the next frame actually being painted.
Many sites that comfortably passed FID fail INP, and the usual culprit is long JavaScript tasks blocking the main thread: heavy third-party tags, oversized event handlers, and large synchronous work triggered by a click. The fixes are unglamorous but effective — break long tasks into smaller chunks, defer non-critical work until after the next paint, and audit third-party scripts that run on every interaction. Anything that keeps the main thread busy for more than fifty milliseconds at a time is a candidate.
CLS Is Nearly Always Preventable
Cumulative Layout Shift measures how much visible content moves unexpectedly while the page loads, and it is the cheapest of the three to fix because the causes are so consistent. Images and video elements without width and height attributes reserve no space until they load. Ads, embeds, and iframes injected into the flow push everything below them down. Web fonts swapping in at a different size reflow the text. Banners and notices inserted above existing content shift the entire page.
Each has a standard remedy documented in web.dev's guidance on layout shift: set explicit dimensions or an aspect ratio on media, reserve fixed space for any injected element, preload critical fonts and use a matched fallback, and never insert content above existing content unless it is a response to user interaction. Sites failing CLS badly can usually get into the good band in a single focused sprint.
How Much Do Core Web Vitals Affect Rankings?
They are part of Google's page experience signals, and Google has been consistent that helpful, relevant content outranks a fast page with nothing to say. Treating vitals as a route to outranking a better answer is a misreading. Treating them as a tie-breaker between comparable pages, and as a direct influence on conversion rate, is closer to how they behave in practice.
The conversion argument is usually the stronger business case anyway. Faster pages hold attention, reduce abandonment, and remove friction at exactly the moments where visitors decide whether to continue — effects that show up in revenue regardless of what any ranking system does with the same numbers.
Arb Digital's development team profiles real user data, fixes the server and front-end causes behind LCP and INP, and rebuilds layouts so content stops moving while it loads.
Web Development SEO ServicesCommon Mistakes to Avoid
- Optimising against lab scores when the assessment is based on field data from real visits.
- Reading the median instead of the 75th percentile, which flatters your numbers and hides the visitors who are struggling.
- Lazy-loading the hero image, which delays the exact element LCP is measuring.
- Chasing a perfect score on one metric while another stays outside the good band — the verdict needs all three.
- Treating vitals as a substitute for content quality rather than a complement to it.
Related Free Tools From Arb Digital
Model how server speed affects crawling with the crawl budget calculator, check whether a page is losing traffic for reasons unrelated to speed using the content decay calculator, and see how results-page features affect clicks with the SERP feature opportunity calculator. Test your connection with the internet speed test, and estimate the value of the traffic you are protecting with the traffic value calculator. More in the free online tools hub.
Frequently Asked Questions
Largest Contentful Paint should be 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. Values up to 4.0 seconds, 500 milliseconds, and 0.25 respectively are rated as needing improvement, and anything beyond is poor.
Yes. The assessment is a set: a URL or origin passes only when all three metrics are in the good band at the 75th percentile of real visits. Strong results on two metrics do not offset a third that is failing.
Because it reflects the experience of the slower part of your audience rather than the average. Measuring at that point ensures the majority of visits, including many on weaker devices and networks, meet the threshold.
Interaction to Next Paint became a Core Web Vital in March 2024. It measures the full latency of interactions across the page's lifetime rather than only the input delay of the first interaction, which makes it a considerably stricter test.
No. The thresholds and the pass or fail verdict follow Google's published definitions, but the 40/40/20 weighting used for the composite is this calculator's own, provided so you can track progress between audits.
Lab data comes from a single simulated load under controlled conditions. Field data is collected from real visits across many devices and networks. The Core Web Vitals assessment uses field data, so that is what you should enter here.
They form part of Google's page experience signals, but relevance and content quality remain far more influential. The stronger business case is usually conversion rate, since faster, more stable pages lose fewer visitors at the moment of decision.
Scores here are calculated from the values you enter — always confirm your current status in the Core Web Vitals report in Search Console, which uses real user data.
