Expose Server-Timing, database queries, and environment info to Chrome DevTools for agents

[adamsilverstein]

Summary

Addresses #2553

Adds an integration with the experimental Chrome DevTools third-party tools API to Performance Lab, so AI agents connected through the Chrome DevTools MCP server (with --categoryExperimentalThirdParty=true) can inspect WordPress server-side performance state while debugging a page. This is a separate approach from #2571, which exposes Optimization Detective's URL Metric; the two integrations are independent and complementary (each registers its own tool group).

Three read-only tools are registered under a "WordPress Performance Lab" tool group:

• get_server_timing_metrics - the Server-Timing metrics sent for the current page load, read client-side from the Navigation Timing API (same-origin Server-Timing headers are exposed to page JS), so this costs nothing extra server-side and composes with the existing per-metric access_cap gating.
• get_database_queries - the SQL queries executed while rendering the page (up until the end of wp_footer), including per-query duration and caller stack, plus totals. Requires the SAVEQUERIES constant; when it is not enabled the tool explains how to enable it so agents can guide the user.
• get_environment_info - WordPress/PHP versions, active theme, persistent object cache status, WP_DEBUG/SAVEQUERIES state, multisite flag, and active plugins.

Relevant technical choices

• Capability-gated, not WP_DEBUG-gated. The script module and the data blob are only output for users with a filterable capability (perflab_devtools_capability, default manage_options), following the Server-Timing access_cap model. This works on production sites for administrators and exposes nothing to unauthenticated visitors or regular users.
• The per-request data (queries, environment) is printed as an inline application/json script tag at the end of wp_footer (JSON_HEX_TAG prevents script-tag breakout), since database queries are per-request and cannot be fetched after the fact via REST.
• The JS is a plain ES module enqueued via wp_enqueue_script_module(), shipped unbuilt with a webpack-copied .min.js, matching repo conventions. Tool names/descriptions are intentionally not internationalized since they are consumed by AI agents.
• New includes/devtools/ feature area in Performance Lab following the existing load.php/helper.php/hooks.php layout.
• PHPUnit tests cover hook wiring, capability gating/filtering, module enqueueing, JSON output, environment info shape, and query mapping (including SQL truncation and malformed entries). A Playwright e2e spec dispatches a synthetic devtoolstooldiscovery event to assert the tool group contents and executes each tool, and asserts nothing is exposed to logged-out visitors.

How to test

1. npm install && npm run build:plugin:performance-lab, run a site with Performance Lab active, define SAVEQUERIES as true, and log in as an administrator in Chrome.
2. Configure the Chrome DevTools MCP server with --categoryExperimentalThirdParty=true and attach it to that browser.
3. Navigate to a frontend page and ask the agent to list third-party developer tools (list_3p_developer_tools). Expect a "WordPress Performance Lab" group with the three tools.
4. Invoke each tool via execute_3p_developer_tool:
   • get_server_timing_metrics returns the metrics enabled under Settings > Performance.
   • get_database_queries returns the page's queries (or an explanation if SAVEQUERIES is off).
   • get_environment_info returns the environment summary.
5. Log out (or use incognito): the page source contains neither perflab-devtools-data nor the devtools-discovery module.

Automated tests:

• npm run test-php:performance-lab (includes the new devtools group)
• npm run test-e2e:performance-lab

Use of AI Tools

This PR was implemented with Claude Code based on my direction and plan (review of the Chrome DevTools third-party tools API, implementation, and tests). I reviewed, refined, and tested the result.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

❌ Patch coverage is 86.30137% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.50%. Comparing base (bc9e349) to head (004ce1a).

Files with missing lines	Patch %	Lines
...ugins/performance-lab/includes/devtools/helper.php	90.00%	7 Missing ⚠️
plugins/performance-lab/includes/devtools/load.php	0.00%	2 Missing ⚠️
plugins/performance-lab/load.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk    #2579      +/-   ##
==========================================
+ Coverage   70.35%   70.50%   +0.14%     
==========================================
  Files          91       93       +2     
  Lines        7867     7940      +73     
==========================================
+ Hits         5535     5598      +63     
- Misses       2332     2342      +10     

Flag	Coverage Δ
multisite	70.50% <86.30%> (+0.14%)	⬆️
single	35.39% <58.90%> (+0.21%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.