Every Core Web Vitals report ends the same way: a list of red URLs and no clear idea what to fix first. The point of Core Web Vitals tools is not to show you a score, it is to tell you which change moves the number. Google’s current targets are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of real user visits. Here are eight tools, ranked by how well they help you prioritize.
1. PageSpeed Insights
The free starting point. It shows field data from the Chrome UX Report when your page has enough traffic, plus a Lighthouse lab test with opportunities listed. The field versus lab split is the useful part: if field data is red and lab is green, your real users have a problem your test device does not. The recommendations are generic, so treat them as hints.
Best for: a fast first check on any URL.
2. Google Search Console Core Web Vitals Report
Groups URLs with similar issues, which is how you find a template-level problem affecting hundreds of pages. It lags by weeks and offers no diagnosis, but the grouping tells you where to start. Pair it with our guide to technical SEO audit tools for what Search Console misses.
Best for: deciding which page templates to fix first.
3. Chrome DevTools Performance Panel
Free and the best tool for debugging INP. Record an interaction and you can see the long task, the event handler, and the rendering work after it. It has a learning curve, and it tests your machine, not your users, but nothing else gives you this level of cause and effect.
Best for: developers chasing slow interactions.
4. WebPageTest
Lets you test from different locations, devices, and throttled connections, with filmstrip views and a waterfall chart. It is the most credible lab tool for LCP problems, since you can see exactly which resource delayed the hero image. The interface is dense, and the free tier has limits.
Best for: diagnosing LCP and third-party script damage.
5. DebugBear
A paid monitoring tool that combines scheduled lab tests with real user and CrUX data and tracks changes over time. It explains regressions, such as which deploy made LCP worse, which is what you want when pages get slower for no obvious reason. Pricing starts around the low tens of dollars per month and rises with pages monitored, so check the current plans.
Best for: small teams that need ongoing monitoring without building it.
6. SpeedCurve
Aimed at larger teams that want performance budgets, synthetic and real user monitoring, and competitor benchmarking. It is powerful but pricier, and probably more than a marketing site needs. Worth it when speed is tied to revenue and multiple teams ship changes.
Best for: enterprise teams with performance budgets.
7. Calibre
A monitoring platform that tracks Core Web Vitals per page, runs tests on a schedule, and sends alerts when thresholds are crossed. It is cleaner for non-engineers than most alternatives, with performance budgets built in.
Best for: teams that want alerts and reporting without an engineer babysitting them.
8. The web-vitals Library Plus GA4
Google’s open-source web-vitals JavaScript library sends real user metrics to any analytics endpoint. With GA4 or a tag manager, you can segment by page, device, and traffic source. It needs setup, but it is free and gives you data from actual visitors. See our picks for GA4 reporting tools to make the data readable.
Best for: teams that already live in GA4.
Lab data versus field data, and why it matters
Most confusion around Core Web Vitals comes from mixing the two data types. Lab data comes from a controlled test, such as Lighthouse running on a simulated device and network. It is repeatable, which makes it great for debugging, but it is only one visit. Field data comes from real Chrome users over a rolling window of roughly 28 days, which is what Google uses for page experience assessment. If your lab score is great and your field data is poor, look at slower devices, slower networks, consent banners, or personalized content that your test never sees. If the reverse is true, your test setup may be harsher than reality. Always decide using field data, then use lab tools to find the cause.
A quick fix order that usually works
For LCP, find the largest element, which is usually a hero image or headline, and check four things in order: server response time, render-blocking CSS and scripts, whether the image is discoverable early in the HTML, and image size and format. For INP, look for long tasks caused by third-party scripts such as chat widgets, tag managers, and A/B testing tools, then break up heavy JavaScript. For CLS, reserve space for images, ads, embeds, and cookie banners with explicit dimensions, and avoid injecting content above what the visitor is already reading. Tackle one metric at a time and re-measure after each change, otherwise you will not know what worked.
Finally, remember that Core Web Vitals are one ranking signal among many. A fast page with thin content will not outrank a slower page that answers the query better. Review your numbers monthly, since new plugins, scripts, and design changes quietly erode performance. Fix what is failing, set alerts so it stays fixed, and then get back to content and links.
How to use these Core Web Vitals tools in order
Use Search Console to find the template with the most failing URLs, confirm the cause with PageSpeed Insights field data, then dig in with WebPageTest for LCP or DevTools for INP. Add DebugBear or Calibre once you want to stop regressions from coming back. Start with the metric that is actually failing, not the one with the scariest name. If you also want to see what visitors do on slow pages, our guide to heatmap and session recording tools is a natural next step.