Recipes

Automated Core Web Vitals audit and fix loop for a marketing site

From README links · todayPulled 1 time

Sales, Marketing & SupportSoftware & DevOps

Agent traces real pages in Chrome, finds LCP/CLS culprits, and patches the code.

What they did

A frontend engineer wired chrome-devtools-mcp into their coding agent and pointed it at the marketing site's key landing pages. They asked the agent to open each URL in a live Chrome instance, record a performance trace, and pull network and console data alongside it. The agent then correlated the trace with the page's own source: it identified the hero image as the LCP bottleneck (uncompressed, no preload, no fetchpriority), spotted a third-party chat widget injecting layout shift above the fold, and found a render-blocking analytics script in the head. Because the agent had both the browser evidence and the repo, it proposed concrete diffs — adding a preload link, switching the hero to a responsive srcset, deferring the chat widget, and moving analytics to load after interaction. The engineer reviewed each diff, ran the agent again on a local preview build to confirm the trace improved, and merged. They repeated the loop for a checkout page where a font swap was causing CLS.

How it went

The loop produced measurable improvements on the traced pages: LCP dropped from roughly 4.1s to 2.3s on the hero page and CLS fell below 0.1 after the widget and font fixes. The agent's diffs were mostly mergeable with light editing, and the before/after traces gave the engineer evidence to justify the changes in review. It worked best as a diagnosis-and-draft tool rather than an autonomous fixer — the engineer still validated every change and re-ran traces on a preview build.

Worth knowing

The MCP server exposes the full browser instance to the client, so avoid running it against logged-in sessions with sensitive data. Performance tools may send trace URLs to the Google CrUX API unless you pass --no-performance-crux, and usage statistics are on by default (disable with --no-usage-statistics or the CI env var). Only Google Chrome and Chrome for Testing are officially supported. Traces reflect lab conditions, not field data, so pair them with real-user metrics before declaring victory.

Wiring

Install Node LTS and current stable Chrome. Add the MCP server to the client config with command npx and args ["-y","chrome-devtools-mcp@latest"], optionally appending --no-usage-statistics and --no-performance-crux. The browser launches lazily on the first tool call that needs it. The agent flow is: navigate_page to the target URL, then performance trace recording, then network and console inspection, then screenshot for visual confirmation. The agent reads repo files in parallel with the trace output to map findings to source, drafts diffs, and the engineer re-runs the same trace sequence against a local preview server to verify. The chrome-devtools CLI is available as an alternative for terminal-only runs.

Try it yourself

Set up chrome-devtools-mcp in my agent config, then audit these pages for Core Web Vitals: /, /pricing, /signup. For each page: open it in Chrome, record a performance trace, capture network requests and console errors, and identify the top LCP, CLS, and TBT contributors. Cross-reference the trace with the source in this repo and propose minimal diffs (preload, srcset, defer, font-display) with file paths and line numbers. Then re-trace a local preview build to confirm the improvement. Do not commit anything; show me the diffs first.

Source

Tools in this stack

Run this stack

Install the stack into this project. It writes AGENTS.md and the manifest, merges the MCP servers into .mcp.json, and — with --yes — runs the tool installs.

npx runchr install runchr/stack-chrome-devtools-mcp-and-puppeteer
No CLI?curl -s https://api.runchr.com/api/recipes/runchr/stack-chrome-devtools-mcp-and-puppeteer/manifest

The manifest is also at api.runchr.com/api/recipes/runchr/stack-chrome-devtools-mcp-and-puppeteer/manifest.