Check your Core Web Vitals — and what they’re costing you
Enter any public URL. You’ll get the one change that recovers the most load time, what it’s worth, and the measurements underneath.
What Core Web Vitals actually measure
Three numbers, each standing in for something a visitor can feel.
Largest Contentful Paint is the moment the biggest thing on screen — usually a hero image or a headline — finishes drawing. Until it does, your visitor is looking at a blank rectangle deciding whether to wait. Google’s bar is 2.5 seconds.
Cumulative Layout Shift counts how far the page moves after it starts appearing. You have felt this one: you go to tap a link, an ad loads above it, and you tap something else entirely. The bar is 0.1.
Interaction to Next Paint is the gap between tapping something and the page visibly reacting. Under 200 milliseconds feels instant; past half a second feels broken. This one is nearly always JavaScript.
Why this is a revenue problem before it is a ranking problem
Core Web Vitals are a ranking factor, but a weak one. Google has said as much repeatedly, and in practice content and links move rankings far more than milliseconds do. Chasing rankings is the wrong reason to care about this.
The reason to care is that people leave. Every large study that has measured it — Amazon’s, Walmart’s, Vodafone’s, Deloitte’s retail work — finds the same shape: load time goes up, conversions go down, and across the range most sites actually live in the relationship is close to linear. The figure that keeps recurring is around two percent of conversions per second of load time, which is what this tool models with, capped so it never produces a silly number.
Rankings are also a lagging, noisy signal you cannot isolate from everything else you changed that month. Conversion rate is something you can read off your own analytics next week. If your checkout takes four seconds to become usable on a phone, you are losing sales today from people who never searched for you in the first place.
That is why this tool leads with a fix rather than a score. A score compresses six measurements into one number and then tells you nothing about which of them to change.
Fix guides
- How to fix a slow LCP — Your main image or headline takes too long to appear.
- How to fix layout shift — Content jumps around while the page loads.
- How to fix slow INP — Taps and clicks take a moment to do anything.
- How to fix a slow server response — Your server is slow to start replying at all.
- How to eliminate render-blocking CSS and JS — CSS and JS files stop anything appearing on screen.
- Why you're seeing "no field data" — Google has no real-visitor data for your site yet.
Common questions
- Is this really free?
- Yes, and there's no signup, no ads and no usage cap beyond 20 checks an hour per person so one script can't drain the quota for everyone. It runs on Google's PageSpeed Insights and Chrome UX Report APIs, which are free for us to call.
- Why doesn't the result start with a score?
- Because a score doesn't tell you what to change. Every other tool leads with a number out of 100, which people then try to raise directly — usually by chasing whichever audit is easiest rather than whichever costs the most time. We lead with the single fix that recovers the most load time. The Lighthouse score is still on the page, at the bottom, where it belongs.
- What's the difference between lab data and field data?
- Lab data is one simulated load on a mid-range phone over a throttled connection. It's repeatable and it can point at specific files, which is why the fix suggestions come from it. Field data is the 75th percentile of what real Chrome users actually experienced on your site over the last 28 days. Field data is what Google uses for ranking; lab data is what tells you where to look.
- Why does it say Google has no field data for my site?
- Google only publishes field data for pages with enough real Chrome traffic to be statistically meaningful and anonymous. Most sites don't clear that bar, especially on individual URLs. It is not a penalty and it doesn't mean anything is broken — the lab results are still accurate and still tell you what to fix.
- How accurate is the revenue estimate?
- It's a model, not a measurement, and we say so on every result. It applies roughly a 2% conversion improvement per second of load time recovered, capped at 20% total, to the visitor and conversion numbers you supply. That rate is in line with published retail studies, but your own site's sensitivity to speed could easily be half or double it. Treat it as an order of magnitude for prioritising work, not a forecast.
- Do you store the URLs I check?
- Only as part of a shared result, and only for 30 days. When you run a check we save the structured result under a random ID so you can share the link; after 30 days it's deleted and the link stops working. We don't log IP addresses, we don't set tracking cookies, and there is no account to attach anything to.
- Why does it only test mobile?
- Because that's what Google ranks on and it's where the problems are. Desktop results almost always look fine — a fast machine on good wifi hides a lot. Testing the throttled mobile case is testing the case that actually loses you money.
- Do you make money from the hosting links?
- Yes, when they appear — they're affiliate links and they're labelled as such inline. They only appear when your server's response time is over 600ms, which is the point where hosting is genuinely part of the problem. If your bottleneck is images, JavaScript or layout shift, you'll never see a hosting product mentioned anywhere in your result, because moving host wouldn't help you.