Add JavaScript and CSS Code Coverage Tracking Tools
Is your feature request related to a problem? Please describe.
When optimising websites, developers need to identify unused JavaScript and CSS code to reduce bundle sizes and improve page load performance. While Chrome DevTools has a Coverage panel, there's no programmatic way to:
- Capture coverage data via MCP: AI assistants and automation tools can't access coverage information to provide optimisation recommendations
- Track coverage across user interactions: Manual DevTools usage requires keeping the panel open and manually triggering coverage collection
- Get structured coverage reports: The DevTools UI doesn't provide machine-readable output for automated analysis
- Identify third-party vs. internal code waste: Understanding which unused code is from dependencies vs. application code is crucial for optimisation
Without programmatic coverage access, AI assistants can't help developers identify dead code, suggest lazy loading opportunities, or recommend bundle splitting strategies based on actual usage patterns
Describe the solution you'd like
Add two MCP tools that enable programmatic JavaScript and CSS coverage tracking:
Tool 1: coverage_start
Begins tracking which JavaScript and CSS code is actually executed/used on the page.
Parameters:
-
resetOnNavigation(default: true): Whether to reset coverage data on page navigation -
includeJS(default: true): Track JavaScript coverage -
includeCSS(default: true): Track CSS coverage
Usage:
// Start tracking both JS and CSS
coverage_start()
// Start tracking only JavaScript
coverage_start({ includeJS: true, includeCSS: false })
Tool 2: coverage_stop
Stops coverage tracking and returns a comprehensive report showing used vs. unused code.
Parameters:
-
pageSize(default: 5, max: 5): Results per page for manageable output -
pageIdx(default: 0): Page number for pagination
Outputs:
- Per-file metrics: URL, total bytes, used bytes, unused bytes, usage percentage
- Third-party detection: Automatically identifies external libraries (CDNs, node_modules, vendor bundles)
- Sorted by waste: Results ordered by unused bytes (most wasteful files first)
- Summary statistics: Total resources, bytes, overall usage percentage
- Paginated results: Token-optimized output with navigation hints
Example output:
Coverage Report
Summary
- Total resources: 15
- Total bytes: 2,450,000
- Used bytes: 1,230,000
- Unused bytes: 1,220,000
- Overall usage: 50.2%
JavaScript Coverage
| URL | Type | Total Bytes | Used Bytes | Unused Bytes | Usage % |
|---|---|---|---|---|---|
| ...vendor.js | 3rd-party | 850,000 | 200,000 | 650,000 | 23.5% |
| ...app.js | Internal | 120,000 | 118,000 | 2,000 | 98.3% |
Typical Workflow:
- Navigate to the page to test
- Call coverage_start to begin tracking
- Interact with the page (click buttons, navigate, trigger features)
- Call coverage_stop to get the report
- Analyze results to identify optimization opportunities
This enables AI assistants to:
- Recommend lazy loading for rarely-used code
- Identify oversized third-party dependencies
- Suggest code splitting based on actual usage patterns
- Provide data-driven bundle optimization advice
Describe alternatives you've considered
- Manual Chrome DevTools Coverage panel:
- Not accessible programmatically by AI assistants
- Requires manual operation and copy-paste of results
- No machine-readable structured output
- Can't be automated or integrated into workflows
- Puppeteer Coverage API directly:
- Requires developers to write custom scripts
- Returns raw data without formatting or analysis
- No third-party detection or sorting
- Difficult to use for non-technical users or AI assistants
- Webpack/Vite bundle analyzers:
- Show what's in bundles, not what's actually used at runtime
- Static analysis only, no real user interaction data
- Separate tooling outside browser environment
- Don't capture CSS coverage
- Lighthouse unused CSS/JS audits:
- Limited to initial page load only
- Doesn't track coverage across interactions
- No detailed per-file breakdown
- Part of larger audit suite, not focused coverage tool
Additional context
Use cases:
- AI-assisted bundle optimization recommendations
- Automated performance testing workflows
- Identifying candidates for lazy loading
- Detecting unused third-party dependencies
- Code splitting decision support
- Before/after optimization comparisons
Token optimization:
- Paginated results prevent massive output dumps
- Summary metrics provide overview without details
- Short URLs (truncated to last 47 chars)
- Compact table format for readability
cc @natorion
Shouldn't this be part of the already existing performance toolset instead? e.g. collecting coverage data there and creating a dedicated insight for it.
Shouldn't this be part of the already existing performance toolset instead? e.g. collecting coverage data there and creating a dedicated insight for it.
Hi @natorion, The output is becoming too context heavy for LLMs to understand. Huge dumps of data lead to hallucinations, I have forked the mcp repo and created some tool chains for dedicated insights around coverage, network chains, dependency chains to run standalone, it has helped me to create really high impact PRs for my organisation.