Build1 publisher3 min readPublished
Distilling a 2 MB page to 3,000 tokens via metadata stripping, visibility filtering, and semantic flattening
Browser-use's perception pass strips scripts and hidden nodes, then paints numbered badges on a screenshot so the model clicks by index instead of by XPath. The teardown puts action precision above 95% per action.
The Engineer · Build desk
What happened
- A dev.to teardown of Browser-use describes one Playwright Chromium page put through two extractions on every step: a DOM snapshot and a high-resolution viewport screenshot.
- According to the post, a raw tree of 2 MB or more comes out as an information-dense representation of 1,500 to 3,000 tokens for the model.
- Injected JavaScript paints numbered badges onto the screenshot, and the model answers with calls like click_element(index=14) instead of predicting pixel coordinates.
- The post puts action execution precision beyond 95% for that index-based action space, and describes workflows of 10 to 30 sequential steps as the target.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A regression test that asserts on an off-screen element has to be rewritten as scroll-then-assert, since the model's context holds only what the viewport rendered at that step.
- cost Per-step distillation does not compound into per-run savings: 15,000 to 90,000 tokens of DOM text per workflow is the floor, and the annotated image is billed on top at every step.
- exposure Whoever puts the 95% figure in an adoption plan owns it at review, because a per-action rate says nothing about whether a 30-step suite comes back green.
- decision Teams holding a Playwright suite are choosing which upkeep they would rather staff: selectors that break when class names change, or badge numbering rebuilt on every observation.
The token figures in the dev.to write-up are per observation, not per task. Browser-use's distilled tree lands at 1,500 to 3,000 tokens for a raw tree of 2 MB or more [8]. The workflows the post has in mind run 10 to 30 sequential steps under an Observe-Reason-Plan-Act-Verify loop [13]. Multiply the two and one workflow spends 15,000 to 90,000 tokens on distilled DOM alone [18]. The annotated screenshot is a second input in the same context, on every one of those steps [15].
The pruning runs inside the page, in three rules. Visibility filtering evaluates computed styles and discards `display: none`, `visibility: hidden`, `opacity: 0`, and everything outside the active viewport [5]. Metadata stripping purges `script`, `style`, `link` and `meta` tags along with SVG paths [4]. Semantic flattening collapses wrapper `div` chains, keeping nodes that carry text or an `aria-label`, `placeholder`, `role` or `href` [6]. So an element mid-transition at `opacity: 0` is gone by the same rule that removes a closed menu, and a lazy-loaded table row below the fold is absent from the context until the agent scrolls.
The precision claim is per action. Referencing badge IDs instead of pixel coordinates, the post says, pushes action execution precision beyond 95% [11]. At 95% per action with independent failures, a 10-step task finishes about 60% of the time and a 30-step task about 21% [19]. Independence is the wrong assumption, and the Verify stage of the loop is there so a failed click can be seen and retried [13]. The post also credits the agent with self-healing when it meets an unexpected modal or a bot challenge [16].
The claim stacked on top of the architecture is broader than the architecture. Entering 2026, the post says, the selector paradigm has been replaced by autonomous web agents, pioneered by projects like Browser-use [14], and the support offered is the project passing 100,000 GitHub stars [1]. It does not compare a Browser-use run with a maintained Playwright suite on the same tasks [23]. That comparison is the one a QA lead needs, because the failure mode changes shape: a stale XPath fails loudly at a line number [2], while an index assigned in one observation and reused in the next points at whatever now holds that badge [22].
For the 95% to transfer to your app, you would need the model that produced it, the site list it ran against, and the definition of a correct action. The token figure has its own condition. The distilled tree is a function of how many interactive candidates survive the filter, not of how many bytes the page weighed [21]. A 2 MB page with thirty buttons in the viewport and a 2 MB page with four hundred do not both land in 1,500 to 3,000 tokens.
The grounding design itself is good craft. Coordinate prediction breaks on display scaling and viewport misalignment [12], and replacing `click at x=1240, y=850` with `click_element(index=14)` removes a whole class of arithmetic from the model's job [10]. Badges are cheap to paint, cheap to read, and verifiable in the screenshot a human reviews afterwards [9].
What to watch
- A head-to-head run of the same 10-to-30-step workflow through Browser-use and a maintained Playwright suite, reporting pass rate and token spend per run.
- Whether the project's own docs pin the stability of badge index numbering across successive observations of the same page.
- Any measured figure behind the post's claim that the agent self-heals through bot challenges, rather than a description of the behaviour.