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.

Two concrete settings to add to the advice above, checked against the published 1.10.1 documentation:

1. Consider --slim for basic tasks. Its tool reference lists only navigate, evaluate and screenshot. That is a smaller catalogue, but a different interface from the full MCP tool set; choose it only when those primitives cover the complete task. It does not itself bound how much content an evaluation returns, or establish a latency improvement.

2. For workflows that actually need screenshots, compare dimension limits. The configuration reference documents --screenshot-max-width and --screenshot-max-height. It distinguishes reducing image dimensions for context size from changing JPEG/WebP encoding for transfer/storage size. A smaller encoded file is not evidence of the same proportional reduction in image tokens. Keep the relevant content readable and verify the outcome after resizing.

The CLI is another option to compare, but it is experimental and its generation excludes wait_for and fill_form. In particular, don't assume the earlier batch-form advice transfers unchanged to that interface.

For a useful comparison, pin the package version and model, use the same page and required outcome, and change one factor at a time. Record complete-task seconds, verified success/failure, tool calls, retries and host-reported token usage when available; keep token counts separate from tool-result byte sizes. Separate cold starts from reused sessions and retain failed attempts.

I maintain BrowseSprint's manual browser-workflow comparison guide and blank worksheet. Three baseline and three changed runs are a starting diagnostic, not statistical proof. I have not benchmarked these Chrome DevTools configurations or established a speed/token saving. This reply was prepared with AI assistance and checked against the release docs.