Test results in your codebase, working with the Webperf MCP server

Test results live in a dashboard. The code that produced them lives in a repository. Somewhere between the two, a developer opens a report, reads minify CSS or Subresource Integrity required, and starts searching the codebase for whatever the finding is talking about. Ten minutes later they have a guess.

When we released the Webperf MCP server, most of the examples were questions you'd ask in a chat window. Which site regressed, what the trend looks like. This post is about a different use. Run the MCP server inside a coding assistant that also has your repository open, and the test results and the source code end up in the same session. The assistant can read a finding, fetch the measurement behind it, and search your code for the line that caused it.

What follows is the workflow we used on one of our own sites over two days, written so you can repeat it on yours.

The setup

You need three things.

The assistant sees your test results the same way it sees your files. Which model that is, and what your organisation allows it to touch, is your decision.

Step 1. Start from the latest results

The first call is get_latest_results for the site. It returns the newest run of every test type with a rating from 1 to 5 and a short report per area. Ask the assistant to list everything below 5 and you have the full list of open findings in one place, across performance, accessibility, standards and security.

The summaries name the problem, not the file. Minify CSS doesn't say which stylesheet. Content Security Policy with a rating of 4.46 doesn't say which directive costs you points. That's the gap the next step closes.

Step 2. Fetch the measurement only where it decides the fix

get_raw_check_data returns the data behind one test. It's large, so it isn't something to fetch for every test, only for the findings where the summary isn't enough to act on.

When you do fetch it, the detail is usually exact.

Step 3. Trace each finding to a line in your repository

This is where having the code in the same session pays off. With a stylesheet URL and a line number, the assistant opens the file. With an HTML tag, it searches the templates for where that tag is rendered. With a security header, it finds the middleware that sets it.

The result of steps 1 to 3 is a list of findings, each with a file and a line, or a note that it doesn't live in your code at all. That second category is as useful as the first.

Step 4. Sort by where the fix lives

Once every finding has a location, they fall into a few piles, and the piles roughly decide the order of work.

  1. In your code. A deprecated CSS keyword, an unneeded preload, a crossorigin attribute on a preconnect for resources that are fetched without CORS, an oversized image, a 404 page with too little text. These are commits. Most take minutes, and your existing test suite tells you whether you broke something.
  2. In server configuration. A missing HSTS header on a CDN subdomain, cache lifetimes. A file on the server, not in the repo, and often a different person's job.
  3. In DNS. MTA-STS and DMARC records for the email test. A few minutes in a zone editor, but with consequences that reach beyond the website. A DMARC policy of reject or an MTA-STS policy in enforce mode can stop legitimate email if you get them wrong, so those deserve a test period first.
  4. Outside your control. The analytics script on a third-party domain, its cache lifetime, its protocol support. You can note these and move on, or ask the vendor.
  5. Deferred on purpose. Bundling multiple stylesheets into one is a real gain, but it belongs with a build step you may not have yet. Deciding to wait, and writing down why, is a legitimate outcome.

The assistant can sort findings by location and estimate the size of each change. Which pile matters most to your organisation this week is still yours to decide. A CSP improvement and a DMARC policy carry different risks, and you know which one your team can absorb.

Step 5. Check the effect before you deploy

Here's a part that only works because the Webperf engine is open source. The code that rates your site is public, so the assistant can run it locally against the change you're about to make.

We used that for the Content Security Policy. Running the rating code on the live header gave exactly the score in the dashboard, 4.48. That's how you know the local run is faithful. The rating code then showed which sub-checks were costing points: a default-src 'self' where the test prefers 'none' plus explicit directives, and script-src-attr, style-src-attr and worker-src that were inherited rather than set. Running it again on the proposed header gave 4.78, before a single file was uploaded. It also showed what couldn't be fixed from our side. A nonce-based script-src caps at 4.5 in that test, and every third-party domain in the policy costs points.

The same check found something no test had flagged. The policy already blocked inline style attributes, and the templates still had 29 of them. The browser had been ignoring them all along, including the one hiding a spam-trap field in a signup form. A test score didn't surface that. Reading the policy and the templates side by side did.

Step 6. Deploy, confirm, and re-test only what changed

After deploying, compare the live site against what you expect before you spend test credits.

Then re-run only the tests your changes touch. The assistant knows which tests produced which findings, so it can give you the list of test numbers. In our case the email test went from 4.15 to 5.0 after the DNS records, and the 404, CSS and HTTP tests all moved. The Lighthouse score stayed put, because the findings that remained were the ones we'd deferred. That's the kind of before and after we wrote about in did the fix actually work.

Automated tests are not infallible

Every finding comes from an automated test, and automated tests are written by people. They encode assumptions about how websites are built, and sometimes a website is built in a way the test didn't anticipate. Now and then a finding says more about the test than about your site.

So before you change your code to satisfy a finding, it's worth asking whether the advice makes sense for your site. If following it would make things worse, or the finding contradicts what you can see in the browser, trust your own judgement and treat the finding as a question rather than a verdict.

Because the Webperf engine is open source, you don't have to guess. The assistant can read the code behind the test and show you exactly what it checks and how it rates the result. If the test turns out to be wrong, the right response is an issue or a pull request upstream, not a workaround on your site. That way the fix helps everyone who runs the same test.

The limits

The assistant reads results and code quickly, and it's wrong sometimes. Review its diffs like any other contribution. Run your tests. Check pages in a browser after a change to layout or styles, because a test suite rarely notices when a form field becomes visible.

Automated tests cover what's machine-checkable. They're a starting point and a benchmark, not a verdict on whether a page works for the people using it. What this workflow saves is the time spent getting from a finding to a line of code. The judgement about what to fix, what to defer and what to leave alone stays with the people who know the site.

The MCP server is free and MIT licensed on GitHub. Your own sites need an API key, which comes with Standard and Agency. Questions about the workflow go to hello@webperf.cloud.