Updated Aug 8, 2026
4 best Claude MCPs & ChatGPT plugins for Core Web Vitals & page experience (2026)
Core Web Vitals live in three places. Lab traces. Real-user field data. And the business impact when slow pages meet real demand. These MCPs put page experience inside your AI tool. Pick by which of the three you need to see.
Ranked on
- First-party grounding Does it answer from accounts you own: Search Console, analytics, ads, logs? Or from a third-party index and modeled estimates?
- Governed analyses & statistics Does the server run defined analyses with significance gates? Those gates stop a thin sample reading as a confident answer. Or does it hand your assistant raw rows to assemble and judge itself?
- Provenance on every answer Does each answer carry its scope and a freshness date? Can you click back to the source?
- Lab, field, or both Does the server return Lighthouse lab runs, real-user field data, or both? Check whether field data needs a snippet or a traffic threshold. One thing holds for every lab-based tool here. Lab runs report TBT in place of INP, because INP needs real interactions to measure.
- Single page or whole site Does the tool measure one URL per run, or cover every crawled page? Check whether it keeps results, so you can compare runs over time.
Our entry is in this list. We publish it, and rank 1 is ours, so read the criteria first and the competitor entries on their own terms. Each is described from its public documentation, with what it does better than us stated where it does.
How this was checked
- Verification window
- Aug 2 to Aug 8, 2026
- Read for every entry
-
- each vendor's own product documentation
- release notes and changelogs
- published pricing and metering pages
- documented client-support matrices
If a vendor's own docs don't mention a feature, we mark it "not documented." That's a gap in what's published, not a verdict that the feature is missing. Where their docs contradicted a claim we carried, we changed the claim.
What is in, and what is not
Qualified for this list
- The server had to return page-experience or Core Web Vitals measurements through documented MCP tools. Lighthouse lab runs, real-user field data, or crawl-time performance results all count.
- Its documentation had to be publicly reachable and dated. That way the lab-versus-field question and any account, plan or quota requirement could be verified rather than inferred.
Looked at and left out
- An official Google PageSpeed Insights or CrUX MCP, Google publishes no first-party PSI or CrUX MCP server; only community wrappers exist.
- Lighthouse MCP Server (danielsogl), Community Lighthouse wrapper; covered by the self-hosted entry rather than listed separately.
- General browser-automation MCPs (Playwright, Puppeteer), They drive browsers but document no Core Web Vitals or Lighthouse output.
The ranking
-
1
Quattr MCP + plugin Ours, bias disclosed Best for: page experience tied to search impact
58 governed analyses over your first-party data. Governed means pre-built analyses with locked definitions. Quattr runs its own Lighthouse tests. Those results are read beside the rankings, clicks and named goals they affect. Verdicts are significance-gated. If a source is missing, it refuses and gives the reason.
- Quattr-run Lighthouse data joined to search impact. No local tooling to operate.
- Significance tests return a verdict on whether a change is real. Refuses causal claims from a trend line.
- Interactive cards carry scope, freshness, and deep-links. An ⚠ Observational chip marks numbers as observed, not causal.
- A skills plugin for Claude runtimes, in private beta
Consider
- The page-experience analyses are fixed. You compose questions against them. There are no arbitrary trace or waterfall queries.
- Reads the accounts you connect. There is no third-party index. Page experience for domains you don't own is out of scope.
- The documented Core Web Vitals refresh is roughly biweekly. It will not reflect a fix you deployed this morning.
Verified against Quattr MCP documentation, Aug 2026
-
2 Chrome DevTools MCP
Best for: lab traces from the source
Chrome's official DevTools MCP lets your agent drive and inspect a live Chrome. It records performance traces and pulls Performance Insights out of them. Insights are DevTools' own named findings from a recorded trace. A Lighthouse audit tool sits beside them. CrUX real-user data can be fetched alongside the lab traces.
- Trace-based insights plus a Lighthouse audit tool in one official Google server
- Blends CrUX field data with lab traces. Free, open source, no API key.
Consider
- The lighthouse_audit tool covers accessibility, SEO, best practices and agentic browsing. It states that it excludes performance. Performance goes through the trace tools.
- Officially supports Google Chrome and Chrome for Testing only. Other Chromium-based browsers may work, but that is not guaranteed.
- Google's own disclaimer: it exposes browser content to the MCP client. So avoid sharing sensitive or personal information.
Verified against GitHub README, tool reference and Chrome for Developers launch post, Aug 2026
-
3
DebugBear MCP Best for: synthetic + RUM monitoring
DebugBear's hosted MCP has the same surface as their API. It sets up page monitoring and runs quick tests. It queries synthetic test results and real-user Core Web Vitals metrics.
- Synthetic lab tests and real-user CWV metrics in one server
- Full API parity. Agents configure monitoring, not just read results.
Consider
- Real-user metrics need DebugBear's tracking snippet installed on your site. Without it, the MCP returns synthetic lab tests only.
- Real-user data consumes a monthly page-view quota. The docs present sampling as the way to reduce it.
- Which plan tier MCP access requires is not documented. Nor is any rate limit on MCP calls.
Verified against DebugBear MCP and real-user monitoring documentation, Aug 2026
-
4
Sitebulb MCP Best for: crawl-time performance hints
Sitebulb's MCP is read-only by intent, and it serves finished crawl audits. You get site scores and Hints by category, performance included. Per-issue sample URLs, audit-to-audit diffs and score trends come with it. Hints are Sitebulb's pre-checked, prioritised issue checks, so you only review what fired. Cloud and Desktop crawls are both supported.
- Read-only by design. Nothing can start or change a crawl.
- Audit diffing and site-score trending built for ongoing monitoring
Consider
- Performance figures are Web Vitals lab data. Sitebulb's headless Chrome collects them as it crawls. That is lab data, not real-user field data.
- Reads finished audits only. A crawl still running returns an error, not partial data. The MCP cannot start a crawl.
- Any single Hint returns up to 50 example URLs, not the full list.
Verified against Sitebulb MCP support articles and performance product page, Aug 2026
Side by side
Every entry against the same five criteria. Not documented means the vendor's own material does not address it, a gap in what is published, not a judgement about what the product can do.
| Product | First-party grounding | Governed analyses & statistics | Provenance on every answer | Lab, field, or both | Single page or whole site |
|---|---|---|---|---|---|
| Quattr MCP + plugin page experience tied to search impact | Reads accounts you connect: Search Console, Ads, analytics. No index for other domains. | Governed and fixed. Significance gating tests whether a change is real or noise. | Every card carries scope chips: as-of date, observational badge, and deep-links back. | Lighthouse-sourced. Docs do not state whether real-user field data is included. | Site-wide: grades, distributions, weakest pages and device splits across connected properties. |
| Chrome DevTools MCP lab traces from the source | Your own browser session. Drives a local Chrome that you control. | Fixed insight set: named Performance Insights. No statistical testing documented. | Raw trace and report files, saved locally via filePath and outputDirPath. | Both. Lab traces recorded locally, with CrUX field data fetched alongside. | Single page per run. Point-in-time trace, no stored history documented. |
| DebugBear MCP synthetic + RUM monitoring | Your DebugBear account: monitored pages you configure and your own real-user data. | Mirrors its own Node and HTTP API. No significance testing documented. | Not documented | Both. Synthetic lab tests plus real-user metrics after installing its tracking snippet. | Monitored pages you configure. Real-user data covers wherever the snippet loads. |
| Sitebulb MCP crawl-time performance hints | Your completed Sitebulb crawls: Cloud or Desktop audits you already ran. | Read-only by design. Cannot start or change a crawl. No significance testing documented. | Reads finished audits only. Returns up to 50 example URLs per hint. | Lab only. Web Vitals lab data collected by headless Chrome during the crawl. | Whole site. Lighthouse performance tests run for every URL in the crawl. |
Self-hosted servers, and why they are not ranked
Google publishes no PageSpeed Insights or CrUX MCP of its own, so every route to those two datasets is a community wrapper. Several are MIT-licensed and easy to run. priyankark/lighthouse-mcp, danielsogl/lighthouse-mcp-server and ruslanlap/pagespeed-insights-mcp all put Lighthouse or PSI behind MCP tools. None of them is a product with a support desk. Note too that a free local option is already ranked second. Chrome DevTools MCP runs on your machine and drives a browser you control.
Reach for one of these when you want a Lighthouse or PSI number for a URL without an account anywhere. Reach for one when you are wiring page-speed checks into something else you are already building. Getting a score out of one is a few lines of configuration.
The limits you hit are Google's, not the wrapper's, and they are worth knowing before you pick this path. CrUX only reports pages that clear an undisclosed popularity threshold. The low-traffic URLs you most want to fix are frequently absent. What it does return is a 28-day rolling average rather than today. Reading CrUX needs a Google Cloud API key. It is capped at 150 queries per minute per project, which shapes how fast you can sweep a site. Google has also documented plans to stop returning CrUX field data through the PageSpeed Insights API, moving field reads to the separate CrUX API. A wrapper that reads field data via PSI today is on a clock.
Those constraints belong to the APIs, which is exactly why this class is not a row in the table. They are equally true of every wrapper. Scoring one row would have graded Google's API design and called it a server's. The criteria above ask what a publisher documents about its own product, and an open-source wrapper has no publisher in that sense. What to check on a specific project is narrow. Which key it wants. Whether it reads field data through PSI or the CrUX API. And what it writes to disk when it saves a report. Read the tool list before you connect, here as everywhere. A server can ask for more than read access whatever its README says.
Test one of these in an afternoon
- Pick one slow page you already know about. Run it through each server you are evaluating.
- Then ask each one the same question. Is this a lab run, or real-user field data? And over what window?
- A trustworthy answer names the measurement type. It gives the date or window it covers. It links back to the source report.
- Then ask about a low-traffic page. The right answer is that there is no field data for that URL. A guess is the wrong answer.
Anticipated questions
Is this list biased?
Do these read lab data or field data?
Do I need Chrome installed for these?
Change history
- Aug 19, 2026 Fact-audit pass. This list's Aug 17 pass was prose-only, so its claims were re-verified for the first time since Aug 8. Corrected a stale release-stage claim: Chrome DevTools MCP was described as in public preview since September 2025. Chrome for Developers announced Chrome DevTools for agents, which the MCP server is now part of, as a stable 1.0 release on May 19, 2026, and the package itself has been shipping non-prerelease 1.x versions since. The September 2025 launch post still reads public preview because it is a dated post that was never rewritten, which is how the claim survived. Also completed the lighthouse_audit category list, which named three of the four categories the tool documents; agentic browsing was missing. Everything else re-verified and unchanged: that tool still states it excludes performance, official support is still Google Chrome and Chrome for Testing only, and the browser-content disclaimer still stands; Google still publishes no first-party PageSpeed Insights or CrUX MCP server, so every route to those datasets is still a community wrapper; the three wrappers named are all still MIT-licensed, checked in their repositories rather than by GitHub's licence field; CrUX still reports a 28-day rolling average and is still capped at 150 queries per minute per project; and Google's plan to stop returning CrUX field data through the PageSpeed Insights API is still a documented plan rather than a completed change, so the clock described is still running. Separately, a style pass brought em-dash density under three per five hundred words. Every dash in the side-by-side table and one FAQ question became a period, a colon or a comma. No claim, ranking or criterion changed in that pass.
- Aug 17, 2026 Moved community and self-hosted servers out of the scored table: a category has no single documentation set, so per-criterion scoring could not be true or false. The class is now covered in prose, and the ranked count drops to four. Rewrote the prose for readability against the house voice guide. No ranking, criterion or verified claim changed in that pass.
- Aug 8, 2026 Re-verified every written entry against vendor documentation. Added documented considerations to each one including our own, ranking criteria specific to this list with a definition apiece, the verification window and sources, inclusion criteria, and a side-by-side table.
- Aug 2, 2026 First publication of the twelve lists.
Request a demo Take a test drive All 12 lists
Third-party details as of Aug 8, 2026; marks belong to their owners. Spot an error? Tell us and we'll fix it: info@quattr.com