Timeout issues when getting performance metrics

[umaar]

Describe the bug
Struggling to get useful performance metrics e.g. core web vitals.

To Reproduce
Steps to reproduce the behavior: follow the chat log

Expected behavior
To get core web vitals details.

Chrome version: 140

Chat log

> give me the core web vitals stats

⏺ I'll try a different approach to get the Core Web Vitals metrics by taking a fresh trace:

⏺ chrome-devtools - new_page (MCP)(url: "https://cwv-guide.vercel.app/")
  ⎿  # new_page response
     ## Pages
     0: about:blank
     … +2 lines (ctrl+o to expand)

⏺ chrome-devtools - performance_start_trace (MCP)(reload: true, autoStop: true)
  ⎿  # performance_start_trace response
     The performance trace has been stopped.
     Here is a high level summary of the trace and the Insights that were found:
     … +2 lines (ctrl+o to expand)

⏺ Let me try using JavaScript to extract the Core Web Vitals data directly from the page:

⏺ chrome-devtools - evaluate_script (MCP)(function: "() => {\n  return new Promise((resolve) => {\n    // Check if web-vitals library is available\n    if (window.webVitals) {\n
                                           const metrics = {};\n      \n      window.webVitals.onCLS((metric) => { metrics.CLS = metric.value; });\n
                                         window.webVitals.onFID((metric) => { metrics.FID = metric.value; });\n      window.webVitals.onFCP((metric) => { metrics.FCP = metric.value;
                                          });\n      window.webVitals.onLCP((metric) => { metrics.LCP = metric.value; });\n      window.webVitals.onTTFB((metric) => { metrics.TTFB =
                                          metric.value; });\n      \n      setTimeout(() => resolve(metrics), 3000);\n    } else {\n      // Fallback to performance API\n      const
                                          navigation = performance.getEntriesByType('navigation')[0];\n      const paint = performance.getEntriesByType('paint');\n      \n
                                         resolve({\n        TTFB: navigation ? navigation.responseStart - navigation.requestStart : null,\n        FCP: paint.find(p => p.name ===
                                         'first-contentful-paint')?.startTime || null,\n        domContentLoaded: navigation ? navigation.domContentLoadedEventEnd -
                                         navigation.domContentLoadedEventStart : null,\n        loadComplete: navigation ? navigation.loadEventEnd - navigation.loadEventStart :
                                         null\n      });\n    }\n  });\n}")
  ⎿  Error: Runtime.evaluate timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.

⏺ Let me try a simpler approach to get performance metrics:

⏺ chrome-devtools - evaluate_script (MCP)(function: "() => {\n  const navigation = performance.getEntriesByType('navigation')[0];\n  const paint =
                                         performance.getEntriesByType('paint');\n  \n  return {\n    TTFB: navigation ? Math.round(navigation.responseStart -
                                         navigation.requestStart) : null,\n    FCP: paint.find(p => p.name === 'first-contentful-paint')?.startTime || null,\n    LCP: paint.find(p
                                         => p.name === 'largest-contentful-paint')?.startTime || null,\n    domContentLoaded: navigation ?
                                         Math.round(navigation.domContentLoadedEventEnd - navigation.requestStart) : null,\n    loadComplete: navigation ?
                                         Math.round(navigation.loadEventEnd - navigation.requestStart) : null,\n    totalResources: performance.getEntriesByType('resource').length\n
                                           };\n}")
  ⎿  Error: Runtime.evaluate timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.

⏺ The site appears to be causing timeouts due to its intentionally slow loading patterns. Based on the network analysis I performed earlier, here are the Core Web Vitals
  characteristics for https://cwv-guide.vercel.app/:

  Core Web Vitals Stats for https://cwv-guide.vercel.app/

  Status: Unable to measure precisely due to site timeouts

It looks like it's executing client side JS to get perf metrics, I would've thought those would be available through the performance tracing tool?

[umaar]

I ran it again from a new session and I saw

⏺ Complete Performance Metrics from MCP Chrome DevTools

  Performance Trace Results

  The performance trace encountered an error: "Cannot read properties of undefined (reading 'length')" - this appears to be a known issue with the MCP DevTools performance  analysis.

And then again:

⏺ Performance Analysis for https://cwv-guide.vercel.app/

  Core Web Vitals Results:

  ✅ Largest Contentful Paint (LCP): Not measured
  - No LCP value was captured in the current session

  ✅ First Contentful Paint (FCP): 68ms
  - Excellent - Well under the good threshold of 1.8s

  ✅ Cumulative Layout Shift (CLS): 0
  - Perfect - No layout shifts detected

  ⚠️ First Input Delay (FID): Not measured
  - Requires user interaction to measure

  Additional Performance Metrics:

  Navigation Timing:
  - Time to First Byte (TTFB): 10.9ms (Excellent)
  - DOM Interactive: 451.6ms (Good)
  - DOM Content Loaded: 1ms
  - Load Complete: 1.3ms

  Resource Performance:
  - Total Resources: 48 files
  - Total Transfer Size: 7.49 MB
  - Memory Usage: 6.24 MB JavaScript heap

  Paint Timing:
  - First Paint: 68ms (Excellent)
  - First Contentful Paint: 68ms (Excellent)

  Assessment:

  The website shows excellent performance with very fast initial paint times and no layout shifts. The large transfer size (7.49 MB) suggests there may be opportunities for
  optimization, but the fast TTFB and paint times indicate good server performance and efficient critical resource delivery.

Which feels way too positive! I guess caching.

[OrKoN]

Thanks for reporting! There was a similar report about reading length of undefined #109 (comment) but it seemed like it was caused by using an unsupported Node version. cc @jackfranklin

[OrKoN]

evaluate_script calls seem to be like the model is trying to evaluate some promises that are not resolving within the default timeout. Which MCP client/model is this? I guess the response from the tracing tool does not contain direct references to the core web vitals and so the client tries to come up with some client-side scripts and makes a mistake.

[umaar]

Tried with claude code, thanks!

[jackfranklin]

@umaar what version of Node are you using? Please can you make sure it's Node v22 or higher?

It looks like it's executing client side JS to get perf metrics, I would've thought those would be available through the performance tracing tool?

Yes, I think what is happening here is that the code we have in DevTools for the live metrics when you first open the Performance Panel is mistakenly being executed. That's not expected; I will look into this and try to fix that behaviour.

[umaar]

@jackfranklin yep it's v23.11.1 - thanks for having a look

[jackfranklin]

Thanks - I wouldn't expect to see that length error in newer versions of Node. I'll try to reproduce - looks like https://cwv-guide.vercel.app/ is the site you're trying this on?

[umaar]

Exactly, that's the site! It's worth trying it multiple times in the same session / across multiple sessions, I've noticed quite varying results. Though this does make sense:

I guess the response from the tracing tool does not contain direct references to the core web vitals and so the client tries to come up with some client-side scripts and makes a mistake.

Assuming the tracing tool does actually return CWV metrics, I wonder if the tool itself could make explicit mention to "core web vitals" which would help agents know they don't need to execute client side JS 'manually' to get those CWV metrics.

[OrKoN]

@umaar is there any chance that claude code actually runs a different node version?

[jackfranklin]

Yes, I think what is happening here is that the code we have in DevTools for the live metrics when you first open the Performance Panel is mistakenly being executed. That's not expected; I will look into this and try to fix that behaviour.

I initially thought that we were mistakenly injecting our live metrics code, but I don't think that is the case. I think Umaar is right; the AI agent is trying to execute that code to get at CWV. I'll update the description to mention CWV, I think that should help.

[jackfranklin]

I've also just recreated the .length error, and I am on Node v23, so I will investigate that too. Thanks for reporting!