--- title: "The best Core Web Vitals tools and what each one is for" id: "538" type: "post" slug: "core-web-vitals-tools" published_at: "2026-10-06T20:00:48+00:00" modified_at: "2026-10-06T20:00:48+00:00" url: "https://danielpazwp.com/core-web-vitals-tools/" markdown_url: "https://danielpazwp.com/core-web-vitals-tools.md" excerpt: "Which Core Web Vitals tools show field data, which help you debug, and the order I use them in WordPress audits, from Search Console to DevTools traces." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/category/performance/) 8 min read # The best Core Web Vitals tools and what each one is for Which Core Web Vitals tools show field data, which help you debug, and the order I use them in WordPress audits, from Search Console to DevTools traces. Published **06/10/2026**8 min read [Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/) The Core Web Vitals tools worth using fall into two groups. Field tools report what real Chrome users experienced: the Chrome UX Report (CrUX), the Core Web Vitals report in Google Search Console, the top section of PageSpeed Insights and your own real user monitoring with the web-vitals library. Lab tools load a page under controlled conditions so you can debug it: Lighthouse, the Chrome DevTools Performance panel and WebPageTest. Google assesses your pages on field data at the 75th percentile, so use field tools to find what fails and lab tools to find out why. On WordPress, add Query Monitor for the server side. I use the same short set of tools in every audit. The tool is rarely the problem. The problem is reading a lab score as if it were the verdict. If you want the bigger picture of how LCP, INP and CLS behave on WordPress first, start with [the complete guide to Core Web Vitals for WordPress](https://danielpazwp.com/core-web-vitals-wordpress/) . ## Which Core Web Vitals tools show field data? Field data comes from CrUX. Chrome collects it from users who opted in, and CrUX reports it over a 28-day rolling window. A page passes when all three metrics are good at the 75th percentile: LCP at 2.5 seconds or less, INP at 200 milliseconds or less, CLS at 0.1 or less. Every field tool below reads from CrUX, except your own RUM, which reads from your visitors directly. ### PageSpeed Insights PageSpeed Insights mixes both kinds of data on one screen. The top block shows CrUX field data for the URL and for the whole origin, when Chrome has enough traffic to report it. Everything under it is a single Lighthouse lab run. In audits I keep meeting teams that optimized for months against the lab score while the field block, the part Google uses, never moved. I wrote a separate piece on [PageSpeed Insights vs Lighthouse and field vs lab data](https://danielpazwp.com/pagespeed-insights-vs-lighthouse/) because the confusion is that common. ### Search Console Core Web Vitals report This is the report I open first on a WordPress site. It groups URLs that have a similar experience, splits mobile and desktop, and tells you which metric fails for each group. On WordPress the groups usually line up with templates: posts, product pages, category archives. That points you to the template to fix instead of a single URL. When you ship a fix, “Validate fix” starts a 28-day monitoring period, the same window CrUX uses. If you are staring at a red report right now, read [what to do when the Core Web Vitals assessment fails](https://danielpazwp.com/core-web-vitals-assessment-failed/) . ### CrUX API, CrUX History API and BigQuery The CrUX API returns the p75 values and the good, needs improvement and poor distribution for a URL or an origin. The History API returns the same data as a weekly series going back several months, which is what I use to show whether a deploy moved the field numbers. The public BigQuery dataset is monthly and works at origin level. It is useful for comparing your site with competitors, less so for debugging a single page. ### Real user monitoring with the web-vitals library Google’s web-vitals JavaScript library measures LCP, INP and CLS in the visitor’s browser the same way Chrome reports them. Its attribution build adds the part you need to fix things: which element was the LCP, which interaction was slow and what ran during it, which element shifted. You send that to Google Analytics 4 or to your own endpoint. RUM is the only way to get numbers for pages that do not have enough traffic for CrUX, and to tag results by template, logged-in state or device class. ## Which tools help you debug a failing metric? Field data tells you that product pages fail INP on mobile. It does not tell you which script is responsible. For that you need a lab tool and a trace. ### Lighthouse Lighthouse runs one page load with simulated throttling and scores the result. In its default navigation mode nobody clicks anything, so it cannot measure INP. It reports Total Blocking Time as a lab proxy. The performance score is a weighted mix of lab metrics and is not a Core Web Vital. I use Lighthouse for regression checks and to confirm a fix works before field data catches up, never as the goal. ### Chrome DevTools Performance panel This is where I spend most of my debugging time. The live metrics view shows LCP, CLS and INP while you use the page, and it can show CrUX field data next to your local numbers. Record a trace and you see the LCP element and its timeline, the long tasks behind a slow interaction and the layout shift clusters. Turn on CPU throttling. A developer laptop hides problems that a mid-range Android phone does not. ### WebPageTest WebPageTest loads the page in real browsers from different locations and connection profiles, then gives you a waterfall and a filmstrip. I use it to answer one question very often: when does the browser request the LCP image, and what is in front of it? It is also good for comparing two versions of the same page side by side. ### Query Monitor Query Monitor is a free WordPress plugin, not a Core Web Vitals tool, but it belongs on this list. It shows database queries, slow queries, hooks and HTTP API calls, grouped by the plugin or theme that triggered them. When uncached requests have a slow server response, this is how you find out who is spending the time. Server response is part of LCP, as I explain in the article on [TTFB in WordPress](https://danielpazwp.com/ttfb-wordpress/) . ## How do the tools compare? | Tool | Data | Measures INP | Best for | | --- | --- | --- | --- | | PageSpeed Insights | Field (CrUX) and lab (Lighthouse) | In the field section only | A quick check of one URL and its origin | | Search Console report | Field (CrUX) | Yes | Which page groups fail across the site | | CrUX API and History API | Field (CrUX) | Yes | Trends and scripted monitoring | | web-vitals library | Field, your own visitors | Yes, with attribution | The exact element or interaction to fix | | Lighthouse | Lab | No, uses Total Blocking Time | Regression checks and verifying a fix | | DevTools Performance panel | Lab, your machine | Yes, for interactions you perform | Long tasks and the LCP timeline | | WebPageTest | Lab, real browsers | Not by default | Waterfalls, filmstrips, comparisons | | Query Monitor | WordPress server side | No | Slow queries and PHP behind TTFB | ## Which WordPress tools help? WordPress itself has two checks worth knowing. Since 6.1, Site Health tests whether a page cache is working, and since 6.6 it warns when autoloaded options get too large. Both are cheap ways to catch structural problems before you open a profiler. The Performance Lab plugin, from the WordPress Performance Team, lets you try performance features before they reach core. Speculative loading started there and shipped in core in 6.8. Some of its current modules, such as Image Prioritizer, use data collected from real visits to decide which images get priority and which get lazy loaded. If you want to compare it with cache and optimization plugins, I cover that in [the best plugins for Core Web Vitals](https://danielpazwp.com/core-web-vitals-plugins/) . ## In what order should you use them? 1. Open the Search Console Core Web Vitals report and note which groups fail, on which metric and on which device. 2. Run PageSpeed Insights on one representative URL from each failing group. Read the field block first, then the lab diagnostics. 3. Reproduce the problem in the DevTools Performance panel with CPU throttling. Find the LCP element, the long tasks and the shifting elements. 4. If server response is slow on uncached requests, profile with Query Monitor. 5. Ship the fix, verify it in Lighthouse or WebPageTest, then follow the field data through the CrUX API or your RUM until the 28-day window has rolled over. ## Which tool habits give you wrong answers? - Chasing a Lighthouse score of 100. The score is lab only and does not decide whether you pass. - Testing while logged in to WordPress. The admin bar loads extra assets and most page caches skip logged-in users. - Trusting a single run. Lab results vary between runs, so take several and compare the median. - Testing only on a fast desktop connection when most of your traffic is on phones. - Treating graders such as GTmetrix as a second opinion. GTmetrix runs Lighthouse in its own lab, so it shares the same blind spots. ## Frequently asked questions ### Is PageSpeed Insights enough to check Core Web Vitals? For one URL, mostly yes, as long as you read the field section and not the score. For a whole site it is not enough, because it only checks the URL you type. Use the Search Console report to see every page group. ### Why does PageSpeed Insights show no field data for my page? CrUX only reports URLs and origins with enough Chrome traffic. Low-traffic pages fall back to origin data or show nothing. Real user monitoring with the web-vitals library fills that gap. ### Do I need a paid monitoring tool? Not to start. Search Console, PageSpeed Insights, the CrUX API and the free web-vitals library cover most WordPress sites. Paid RUM products save setup time and add dashboards and alerts, which matters more as the number of templates and teams grows. If you want a quick automated first look, the [free WebOption diagnostic](https://weboption.com.br/diagnostico/) runs the basic checks. If you want me to read the field data, trace the failing templates and give you a prioritized fix list, that is what my [WordPress performance audit](https://danielpazwp.com/wordpress-performance-audit/) does. [Work with Daniel](https://danielpazwp.com/#book) [More in Performance](https://danielpazwp.com/category/performance/) [About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/) ## Related articles [All articles](https://danielpazwp.com/blog/) [Performance Oct 2026What is enterprise WordPress?](https://danielpazwp.com/enterprise-wordpress/) [Performance Oct 2026Headless WordPress: when it makes sense and when it does not](https://danielpazwp.com/headless-wordpress/) [Performance Oct 2026How to speed up Elementor: the fixes that matter](https://danielpazwp.com/speed-up-elementor/)