Skip to content

perf(extension): overlap Jev intent with DOM settle and observe's snapshot - #2993

Draft
miguelg719 wants to merge 1 commit into
jev/6-webmcp-toolsfrom
jev/7-overlap
Draft

miguelg719 wants to merge 1 commit into
jev/6-webmcp-toolsfrom
jev/7-overlap

Conversation

@miguelg719

@miguelg719 miguelg719 commented Sep 19, 2026

Copy link
Copy Markdown
Collaborator

Stack

Stack: #2951 snapshot editable ids → #2952 library → #2953 act pipeline → #2954 observe + cache check → #2955 extract → #2988 WebMCP tools → this PR. Base: jev/6-webmcp-tools.

Why

Every act() first waits for the DOM to settle, which is a quiet window of at least 500 ms. The Jev intent request needs no page, only the instruction, yet it waited for that too. Same shape in observe(): intent was asked after the snapshot it does not depend on.

What

  • actService.ts: with Jev enabled, the DOM-settle wait is started but not awaited up front. It is passed to the pipeline as settled; cache replay and the LLM fallback await it before touching the page. With Jev off nothing changes (await as before).
  • jevAct/pipeline.ts: the intent request runs while settled is pending. snapshot() and the action helper (press / whole-page scroll never take a snapshot) await it first, so nothing reads or touches the page before the settle wait is over. A WebMCP tool call (feat(extension): experimental Jev WebMCP tool selection in act() #2988) does not wait for it at all.
  • jevAct/observe.ts: intent is asked while the snapshot is captured.
  • The per-act log gains totalMs, measured from the start of act() with settle included. durationMs was started after the settle wait, so it under-reported what a caller waits for, equally in the LLM and Jev arms.

Tried and dropped: starting the first snapshot before intent answers. Settle always outlasts the intent request, so it gained nothing, and it made press / not-an-action acts capture a snapshot they do not need.

Results

Browserbase, gemini-3.8-flash fallback, 1 trial, Jev + LLM fallback:

suite pass before this PR
act (40) 39/40 (vantechjournal, fails on every arm) 39–40/40
breadth (40, not in the stack) 37/40 39/40

The two extra breadth failures are not timing: dup_sauce_second_item_cart failed before its first act, and nav_usajobs_collapse_group landed on the Help Center root where the target section does not exist (the LLM fallback failed on it too).

Where a Jev-only act's time goes now (act suite, median of 35 acts): total 1001 ms = intent 138 ms (now inside the settle wait) + picks, action and checks 274 ms + ~560 ms that is settle and snapshot. Before, intent came after settle, so the saving is the intent request: ~140–250 ms per act. Tool acts on a local Chrome went from 672–785 ms to 244–398 ms because they skip the wait entirely.

What is left is the settle window itself: more than half of a Jev act. That is core act() behaviour shared with the LLM path, so it is not touched here.

Testing

New pipeline test: intent is requested before settled resolves and the action runs only after it. Existing "no snapshot for press / not-an-action / low-confidence" tests still hold. Full extension/protocol/sdk-ts/root suites, typecheck, lint, fmt, extensionpack --check pass locally.


Summary by cubic

Previously the Jev intent request waited for the DOM settle window even though it only needs the instruction. Now it runs while the DOM settles, making Jev acts faster while every page read and action still waits for the settle to finish.

Details

  • observe() asks its intent while the snapshot is being captured.
  • WebMCP tool calls skip the DOM settle wait entirely.
  • The per-act log now records totalMs, measured from the start of act(), while durationMs still measures only the pipeline.
  • When Jev is disabled, act() continues to await the settle wait up front.

Written for commit 577eb9f. Summary will update on new commits.

Review in cubic

@changeset-bot

changeset-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 577eb9f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant