ChromeDevTools / ChromeDevTools/chrome-devtools-mcp

Add JavaScript and CSS Code Coverage Tracking Tools

Open
#731 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

collecting-feedback feature
Dominant language
TypeScript
Stars
52.3k
Forks
4.3k
Avg merge
2d 7h
Merged PRs (30d)
83

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the existing MCP tool entry points and reviewing how browser-facing tools expose parameters and structured results. Read the Puppeteer Coverage API alternative described in the issue, then define coverage_start and coverage_stop around the requested JavaScript/CSS tracking, pagination, sorting, summaries, and third-party detection. Done means both tools support the stated workflow and return the specified report data.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, javascript, typescript
Domain
devtools, performance, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.