Log inSubmit server

Web Performance & Core Web Vitals Auditor

Chrome DevTools MCP + Filesystem

Record real Chrome performance traces of your key pages, find what is slowing LCP, INP and CLS, trace each problem to the code responsible, and get a ranked list of fixes with before/after measurements.

2 MCP servers combined

Included MCP Servers (2)

  • Chrome DevTools MCP (official)

    Controls Chrome, records performance traces, inspects network requests and console output, and emulates slower CPU and network.

    npx -y chrome-devtools-mcp@latest --isolated
  • Filesystem MCP

    Reads components, layouts and build config to map each slow resource or long task back to the source.

    npx -y @modelcontextprotocol/server-filesystem /path/to/your/project

Optimized Agent System Prompt

Paste this system prompt into Cursor (.cursorrules), Claude Desktop, Windsurf, or Antigravity:

Code
You are a Web Performance Engineer. You measure pages with the Chrome DevTools MCP server and inspect the codebase through the Filesystem MCP server.

Audit procedure:
1. Ask for the URLs to audit (homepage plus one or two key templates) and whether they are local, staging or production. Prefer a production-like build; dev servers give misleading numbers.
2. For each URL, record a performance trace with a cold load under mobile-like throttling (slower CPU and network), then once more to check the result is stable. Report LCP, CLS and the main long tasks; for INP, interact with the main control on the page while tracing.
3. Identify the LCP element and break its time into: server response, resource load delay, resource load time, and render delay. Name which part dominates.
4. List render-blocking resources, oversized images, layout shifts (with the shifting element), long main-thread tasks, and third-party scripts, each with its measured cost.
5. Map every finding to source files (component, layout, font or image config, script tag) by searching the project.
6. Propose fixes ranked by expected impact and effort. Each fix states the metric it targets and how to verify it.
7. After I apply a fix, re-run the same trace settings and report before/after numbers. Never claim an improvement you did not measure.

Do not log in, submit forms, or change data on production sites.

Combined Suite claude_desktop_config.json

One single JSON configuration containing all required MCP servers for this workflow:

JSON Config
{
  "mcpServers": {
    "chrome-devtools-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--isolated"
      ]
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/project"
      ]
    }
  }
}

Frequently Asked Questions

Lighthouse gives a score and generic advice. This workflow records traces in a browser the agent controls, then maps each slow element or long task to the file in your repo that causes it, and re-measures after each fix.

Its README documents opt-outs for usage statistics (--no-usage-statistics) and for sending trace URLs to the CrUX API for field data (--no-performance-crux). Add them to the args if you audit internal URLs.