performance_start_trace records 'CPU throttling: none / Network throttling: none' despite emulate setting throttling — measurements come back partially or fully unthrottled

[tracedef]

Description

When emulate is called with cpuThrottlingRate=4 and networkConditions="Slow 4G" and a subsequent performance_start_trace records a page load, the trace summary's metadata reports CPU throttling: none / Network throttling: none regardless of the emulation state. The recorded LCP comes back substantially faster than PSI Lighthouse 12 mobile measurements with identical configured throttling — typically 3–6× faster — suggesting the throttling either isn't propagating to the trace agent or is being applied incompletely.

Environment

• chrome-devtools-mcp version: 0.23.0 (npx chrome-devtools-mcp@latest, latest as of 2026-04-22)
• Coding agent: Claude Code (Opus 4.7)
• OS: macOS 26.4.1 (Darwin 25.4.0)
• Configuration: --channel=stable --isolated=true --viewport=1920x1080

Reproduction

Target: https://jumpermedia.co/ (a CrUX-available, real-world WordPress + WP Rocket + Cloudflare site). Mobile field LCP from CrUX is 1,712 ms; PSI Lighthouse 12 mobile lab LCP is 6,831 ms.

1. mcp__chrome-devtools__new_page url="about:blank" isolatedContext="repro-1"
2. mcp__chrome-devtools__emulate
     viewport="412x823x2.625,mobile,touch"
     userAgent="Mozilla/5.0 (Linux; Android 11; moto g power (2022)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Mobile Safari/537.36"
     networkConditions="Slow 4G"
     cpuThrottlingRate=4
3. mcp__chrome-devtools__performance_start_trace reload=false autoStop=false
4. mcp__chrome-devtools__navigate_page type="url" url="https://jumpermedia.co/"
5. (sleep ~30 seconds for full load + delay-JS firing after a synthetic interaction event)
6. mcp__chrome-devtools__performance_stop_trace filePath=/tmp/test.json

Trace summary returned:

URL: about:blank
Trace bounds: {min: ..., max: ...}
CPU throttling: none
Network throttling: none

## insight set id: NAVIGATION_0
URL: https://jumpermedia.co/
Metrics (lab / observed):
  - LCP: 1173 ms, ...

Compared to Google PSI on the same URL with identical throttling profile (Lighthouse 12 mobile = Slow 4G + 4× CPU + Moto G Power):

Lab LCP: 6,831 ms
Field LCP (CrUX p75): 1,712 ms

The DevTools-trace LCP at 1,173 ms is 17% of PSI's 6,831 ms — closer to field reality than to PSI's lab. With a different sequencing (new_page → URL → emulate → performance_start_trace reload=true) the gap widens further: the same site on the same setup produced DevTools LCP 952 ms versus PSI 6,831 ms (14% ratio).

Two distinct symptoms

1. Trace metadata reporting bug: the trace summary always says CPU throttling: none / Network throttling: none even when emulation is fully active and the page IS loading slower than unthrottled. This is cosmetic but misleading — the metadata should reflect the actual throttling state of the trace recording.

2. Throttling under-propagation: even when the sequence is about:blank → emulate → start_trace(reload=false) → navigate (which appears to apply throttling more completely than start_trace(reload=true)), the recorded LCP is still substantially faster than PSI's same-configuration measurement. CPU + network throttling appear to be applied at less than full strength relative to Lighthouse 12's profile.

Possible cause hypothesis

Similar to #1797's root-cause hypothesis (CDP session conflict around Network.emulateNetworkConditions): the trace recording may use its own CDP session that doesn't inherit the emulation state set on the primary session via the emulate tool. The reload=true variant likely triggers the trace to start before the emulation propagates; the reload=false → navigate variant lets emulation take effect on the page, but the trace's measurement layer may not honor the same throttling profile that the page sees.

Impact

For agents running performance audits on CrUX-passing real-world sites (most WordPress + WP Rocket + Cloudflare prospects), this means:

• DevTools mobile LCP and TBT cannot be cross-validated against PSI Lighthouse mobile lab data.
• Verifier-style checks comparing the two (e.g., a DevTools-mobile-LCP < 25%-of-PSI-mobile-LCP gate) false-positive on every well-optimized site.
• The trace remains useful for waterfall, third-party inventory, console errors, and insight-level findings — but the headline timing metrics are not lab-comparable.

Expectation

(a) The trace summary's throttling metadata should reflect the actual throttling applied during the recording. (b) When emulate sets CPU + network throttling, a subsequent performance_start_trace recording should produce LCP / FCP / TBT measurements equivalent to Lighthouse running with the same profile — within normal run-to-run variance, not 3–6× off.

Workaround in use

Adopting about:blank → emulate → performance_start_trace(reload=false) → navigate_page instead of new_page-with-URL → emulate → performance_start_trace(reload=true). This narrows but does not close the gap. We've stopped using DevTools mobile LCP as a cross-tool comparison metric and rely on PSI Lighthouse for canonical mobile lab data, treating the DevTools trace as a network-and-insights tool only.

Related

• lighthouse_audit always fails: Network.emulateNetworkConditions timed out (even with increased protocolTimeout) #1797 — lighthouse_audit Network.emulateNetworkConditions timeout (similar CDP-session-conflict hypothesis)
• Cannot Disable CPU Emulation in emulate_cpu Tool #245 — emulate_cpu cannot fully disable (separate issue, but indicates emulation-layer surface area)