chrome-devtools-mcp icon indicating copy to clipboard operation
chrome-devtools-mcp copied to clipboard

Add JavaScript and CSS Code Coverage Tracking Tools

Open yashverma2110 opened this issue 1 week ago • 3 comments

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:

  1. Capture coverage data via MCP: AI assistants and automation tools can't access coverage information to provide optimisation recommendations
  2. Track coverage across user interactions: Manual DevTools usage requires keeping the panel open and manually triggering coverage collection
  3. Get structured coverage reports: The DevTools UI doesn't provide machine-readable output for automated analysis
  4. 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:

  1. Navigate to the page to test
  2. Call coverage_start to begin tracking
  3. Interact with the page (click buttons, navigate, trigger features)
  4. Call coverage_stop to get the report
  5. 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

  1. 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
  2. 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
  3. 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
  4. 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

yashverma2110 avatar Jan 05 '26 19:01 yashverma2110

cc @natorion

OrKoN avatar Jan 07 '26 14:01 OrKoN

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.

natorion avatar Jan 08 '26 09:01 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.

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.

yashverma2110 avatar Jan 11 '26 14:01 yashverma2110