Joan León Manual performance analysis with Chrome DevTools has a clear limit: the graphs show Long Tasks, but without knowing the codebase upfront it’s hard to tell which function is causing them. The obvious workaround, downloading the Performance Trace and passing it to an agent, doesn’t work either: a 30-second trace weighs 5.5MB and over 25,000 lines. It overflows the context window.
I built a workshop that addresses this workflow with Gemini CLI connected directly to the browser via Chrome DevTools MCP, removing the trace file as an intermediary.
The Tools: Gemini CLI, MCP, and Source Maps
Three pieces make this work:
Gemini CLI
The AI agent running in the terminal with access to the MCP protocol.
MCP (Model Context Protocol)
The protocol that gives Gemini permissions to navigate the browser, run scripts in DevTools, and access page resources.
Source Maps
The link between minified production code and readable source code. When Gemini finds an anonymous line in the profile, Source Maps tell it exactly which function originated it, in which file, and on which line.
Without Source Maps, Gemini works with the same cryptic names we’d see ourselves. With Source Maps, the diagnosis is concrete: handleFilterChange in FilterPanel.tsx:42, or useEffect in hooks.ts:128.
‼️ Exposing Source Maps in production is not a good idea. We can keep them accessible behind a VPN, which makes the workflow easier without exposing your source code.
The Workshop: From Identification to Fix
The workshop has five exercises covering the full workflow on a real project.
Exercise 1: Manual Analysis without AI
The starting point is the process we use today: open DevTools, record the profile, identify the Long Task. The exercise surfaces two concrete limitations: it’s not always possible to tell which function caused the problem just by looking at the graph, and the downloaded trace is too heavy to pass as context to an LLM.
Exercise 2: The Minified Code Problem
The page has a performance issue. The browser delivers minified code. The Performance graphs show Long Tasks but not their origin. The exercise is about exploring with Gemini which part of the cycle is failing: JavaScript? rendering? Network?
Without Source Maps, the diagnosis identifies the type of problem (JavaScript, rendering, Network) but not the code generating it. That’s the limit the next exercise addresses.
Exercise 3: Exact Discovery with Source Maps
With Source Maps available, Gemini can go from Long Task to source code. It reads the profile, identifies the bottleneck, and returns a precise diagnosis: components/Dashboard.tsx, line 67, function updateMetrics, a synchronous calculation that should be async.
Knowing the exact line generating the problem is the starting point for the next exercise, where the flow moves from diagnosis to fix.
Exercise 4: Full Automation
With the root cause identified, Gemini acts:
- Creates a branch with a semantic name for the bug
- Applies the fix (async, rendering optimization, whatever applies)
- Runs the profile again to verify the Long Task is gone
- Opens a PR with a descriptive message that documents the change for the team or other agents
The analysis and the fix happen in the same context, without switching tools. Once the fix is on the branch, Exercise 5 widens the lens.
Exercise 5: Expert Analysis with Best Practices
The specific bug is an opportunity to check whether the pattern appears in other components. Gemini analyzes whether the solution is scalable and which React or Vercel best practices apply to the case.
The result is not just a fix; it’s a code review with architectural context.
Conclusion
The combination of Gemini CLI, Chrome DevTools MCP, and Source Maps turns the performance debugging workflow into a verifiable and reproducible process. With Gemini connected directly to the browser via MCP, the agent doesn’t improvise JavaScript or interpret graphs visually: it executes, reads results, and acts on the real source code.
The full workshop is available at Web Performance Debugging with Chrome DevTools MCP and AI Agents.