The speed of AI operating Chrome DevTools MCP is very slow and consumes a lot of tokens. #1809

Agreeing with @OrKoN — browser actions themselves are usually fast; most wall time and tokens come from the LLM ↔ MCP loop (planning + stuffing large tool results back into context).

Things that usually help in practice:

1. Prefer structured snapshots over screenshots** when you only need to click/type. Screenshots and full-page dumps burn a lot of tokens per turn.
2. Narrow the surface: ask the agent for a specific element/region instead of re-taking a full-page snapshot every step. Avoid “inspect everything again” after each click.
3. Shrink the tool surface in the client: disable MCP tools you do not need (network/console/performance dumps, etc.). Large tool schemas alone cost tokens every request.
4. Use a faster model for the click-navigate loop; reserve a stronger model only when reasoning fails. Mixing one “always max” model makes every trivial click expensive.
5. Fewer round-trips: give the agent a short multi-step plan (“go → fill → submit → assert”) so it does not re-plan from scratch after every single tool call.
6. Keep one browser session instead of relaunching Chrome / reconnecting MCP mid-task.

If it is still slow after that, the useful signal is which specific tool dominates latency/size, plus whether the host is re-sending the full history each turn. That is usually an agent/client config issue more than a Chrome DevTools MCP bug.

A practical way to reduce both latency and token use is to treat the MCP loop as a state-diff workflow, not a full re-inspection workflow.

What has worked well for me with a persistent/remote CDP Chrome session:

1. Keep one Chrome session and target the same pageId instead of relaunching/re-discovering tabs.
2. Use take_snapshot with verbose: false for interaction. Only take screenshots when visual pixels are actually needed.
3. After a click/navigation, inspect only the new state. Avoid a fresh full-page snapshot after every trivial action.
4. For forms, batch fields (fill_form) instead of one tool call per input.
5. For console/network work, request a small page size / narrow resource type first; fetch a specific message/request only when needed.
6. Prefer direct navigation to known URLs over UI traversal when the destination is deterministic.
7. Give the agent a short execution contract such as navigate -> snapshot -> fill/click -> verify, so it does not repeatedly re-plan the whole task.
8. Separate the fast browser loop from heavy reasoning: use the stronger model only for diagnosis/decision points, not every click.

For remote use, keeping Chrome alive behind CDP also removes repeated authentication/setup cost, but CDP exposure should be protected (bind locally or put it behind an authenticated tunnel; do not expose the debugging port directly to the Internet).

So I would profile two things separately: tool latency and tool-result size. In many cases the browser call itself is fast; the expensive part is repeatedly feeding large snapshots/screenshots/network dumps back into the model context.