BROWSER WORKFLOW NOTES / 001
Why is Codex browsing slow?
Measure the wait before choosing a fix.
A slow browser task can spend time loading a site, reading its state, waiting for a model decision, acting on the page or repeating a failed step. These causes can overlap. A long total does not prove that your connection, the browser or the model is the main problem.
Start with one public page and one precise outcome: for example, open a product page and return its displayed price. Compare a manual attempt with the agent attempt. Keep the model, page, browser session and login state comparable. Record failures as well as successful runs.
1. Match the symptom to a check
| What you observe | Check next |
|---|---|
| The same page is slow manually | Page loading, connectivity and site errors. A manual delay is evidence to investigate the site or connection; it does not rule out additional agent delays. |
| The page is ready, but the next action takes time | Model decisions, tool scheduling and sequential tool calls. Record the gap; do not label all of it model inference unless your trace exposes that boundary. |
| The agent reads the whole page after every small action | Repeated page-state extraction and unnecessary context. Request only the fields needed for the outcome, with a fresh state check after changes. |
| Every step waits for a fixed delay | In code you control, wait for the target content or element to be ready. Playwright clicks already check visibility, stability, event reception and enabled state. |
| The same failed click keeps repeating | Changed page state, overlays or an unavailable target. Inspect the visible blocker before retrying. Stop at required authentication or verification. |
| Typing and scrolling are slow even without a browser task | Treat this as a separate application or device symptom first. A page-reading plugin has not been shown to fix it. |
The element readiness check above is documented in Playwright's auto-waiting guide. The other checks are our suggested diagnostic workflow, rather than confirmed causes for your setup.
2. Keep a small comparison sheet
Use the same public outcome for a baseline and one changed approach. Record total seconds, success or failure, tool calls, retries and any navigation or extraction timings your tools actually expose. Leave unavailable measurements blank. When stages overlap, do not add their durations as if they happened sequentially.
Download the blank browser task CSV worksheet
For a quick local comparison, repeat each approach three times and report all three results. This is a starting check, not a statistical proof. Keep cold starts separate from reused sessions. Include failed and timed-out attempts; a faster successful run can hide a lower success rate.
Change one factor at a time: the requested output fields, a content-ready wait, or the number of sequential tool round trips. A smaller output is useful only if it still completes the same outcome correctly.
3. A worked timing example
This invented, fully sequential trace illustrates the arithmetic. It is not a BrowseSprint benchmark or a measurement of Codex.
| Stage | Seconds |
|---|---|
| Navigation and page readiness | 10 |
| Page-state extraction | 8 |
| Model decisions | 24 |
| Retries | 8 |
| Total | 50 |
Halving extraction from 8 to 4 seconds changes the total to 46 seconds: 4 seconds saved, or 8%. It does not halve the whole task. This calculation assumes every other stage stays unchanged. A real comparison must measure them again.
4. Choose a change that fits the cause
For an agent you build, reducing sequential model requests may remove round-trip delay. Independent reads can sometimes run together; steps that depend on a prior result must remain ordered. OpenAI's API latency guide describes fewer requests and parallel work as optimization principles. Applying them to a particular browser workflow still needs measurement; the API guide does not promise a Codex app speedup.
If you already use Microsoft's Playwright MCP, structured accessibility snapshots are already part of the tool. Its maintainers also describe CLI plus skills as a concise option for coding agents and MCP as useful for persistent exploratory work. Compare compatible approaches on your complete outcome instead of assuming that a new interface will be faster.
A local extension may improve page access or reduce repeated extraction. It does not by itself change cloud model inference. BrowseSprint has no released plugin or verified speed gain. We are researching which repeated browser tasks justify a prototype.
Common questions
- Why can Codex take a long time to open one page?
- One request can include navigation, waiting for page content, reading the page, deciding what to do and retrying a failure. The total alone does not identify which step is slow. Compare the same public page manually and record the agent's observable steps.
- Does a browser extension make the model think faster?
- An extension can change local page access or the tool workflow. That does not establish faster cloud model inference. A useful test measures a complete task, success rate and retries with the same model and comparable conditions.
- Should I replace Playwright MCP to get faster browsing?
- Measure your existing workflow first. Playwright MCP already offers structured accessibility snapshots. Its maintainers describe CLI plus skills as an option for coding agents that need concise tool interactions, while MCP supports persistent exploratory workflows. Compatibility and measured task results should decide the choice.
- Can I install BrowseSprint now?
- No. BrowseSprint is an independent research project, not an available plugin or an OpenAI product. The guide and blank measurement worksheet are available now; prototype compatibility and speed gains have not been verified.