Frontend large-session performance budgets
前端长 Session 性能预算
A fast Node conversation fold does not prove that a browser paints a long conversation or remains responsive while a response streams. Active reconnect also reconstructs a different representation from settled history: a compact prefix becomes public per-chunk Client entries. The [Session performance policy](2026-09-04-session-open-performance-gate.md) supplies an isolated CI job but does not measure these user paths
English
Problem
A fast Node conversation fold does not prove that a browser paints a long conversation or remains responsive while a response streams. Active reconnect also reconstructs a different representation from settled history: a compact prefix becomes public per-chunk Client entries. The Session performance policy supplies an isolated CI job but does not measure these user paths.
Decision
The existing serial benchmark inventory includes two frontend owners: active reconnect and a browser workflow. The browser workflow combines cold open, older-page navigation, first Trajectory activation, return to Chat, and a paced response with trusted keyboard input into one sequential scenario. These are endpoints of one workflow, not independent cold scenarios. The settled conversation-fold benchmark remains unchanged.
build:bench keeps the Node-only library and worker build. test:bench additionally builds the Web shell before running all cases; the required benchmark CI job follows the standard hosted runner reference, unconditionally provisions Chromium and its Linux dependencies on that hosted runner, and enables the existing verbose gate output so successful raw samples remain available for calibration. Browser cases reuse the shipped-composition Web scaffold with private temporary roots and an atomically assigned loopback port. Only the nondeterministic model is replaced by synthetic replay. The scaffold Host runs under the existing Vitest source resolver; measured Client rendering runs built bundles in fresh Chromium processes. Browser wall times therefore include this test Host, transport, Playwright actionability, and rendering, and are not claims about a published Host process.
The browser input contains 240 closed turns, 40 tool results, and 20 code fences, plus mixed-language prose and reasoning. Historical Assistant records carry matching compact streams built through the production accumulator with 12-character reasoning/text deltas and 8-character tool-argument deltas; empty streams would omit stored and transferred payload costs. Nine older-page actions exhaust this input from its observed 25-turn initial window; the readiness probe follows mounted turn growth rather than duplicating the pagination algorithm. Each sample uses a fresh scaffold and browser. Setup, seeding, browser launch, initial shell load, and sidebar expansion are excluded from open timing. Paging resolves exactly one current Load earlier control before timing, excluding its read-only accessibility lookup. The 875 ms paging ceiling includes actionability, the trusted click, mounted turn-tail growth and the final two animation frames; a replaced control fails. Open ends at transcript availability and an editable composer; page and navigation timings end at their target DOM state. Two animation frames include a rendering opportunity, not hardware presentation or a guarantee that every offscreen node painted.
The continuation sends 120 text deltas at 16 ms replay pacing. The input witness is installed before Enter submission from the focused composer; typing retains focus without a mouse-refocus action or a separate pre-input animation-frame wait. First/final marker lookups sample visible text inside the latest Assistant step on animation frames, avoiding selector retry backoff. Hidden text and markers in older steps cannot satisfy the observer. The first observation captures reply markers and focus in the browser; diagnostics are retrieved after typing to avoid an additional pre-input round trip. Diagnostics also capture browser-clock timestamps and focus at the first actual input event. Replay never waits for input; starvation can still fail overlap. The synchronous input witness reads that same bounded reply. Whole-history text and accessibility queries add observer CPU and garbage collection to the measured interval, so reducing that observer work is benchmark repair, not product optimization. It records Enter-to-first-visible-reply, trusted draft typing whose first actual input event observes the first reply but no completion marker, complete reply wall time through settled persistence and the new rendered turn-tail, and Chromium main-thread task duration. The complete wall budget adds the fixed 1984 ms scripted pacing to a scaled overhead allowance; input and completion have their own enforced budgets. Post-GC browser heap and DOM counts remain diagnostics because one endpoint does not prove a leak.
Reconnect uses three fresh compiled plain-Node children. Each creates a 100,000-delta reasoning prefix with distinct timestamps and two compact records before timing ClientAssistantStream.replace(). GC precedes the baseline and follows replacement while the result remains reachable; replacement time excludes both collections. The report consumes the result after collection and checks that the next dense live frame remains accepted. This measures reconstruction, not transport, rendering, or an entire reconnect workflow.
Calibration
Three-sample medians on the arm64 reference machine, Node 24.19 and Chromium 149.0.7827.55, at the PR #3537 merge, establish the baseline below. An isolated repeat follows a complete workflow smoke. Each browser sample reports raw endpoint values and every page; the paging verdict uses the median of the sample maxima. Reconnect reports all child measurements. The following historical reference table uses 8 ms replay pacing and includes a two-frame wait in first-reply timing. Its paging samples include the accessibility lookup of the older-page control. Standard-hosted open, paging, Trajectory, and reconnect expectations are recorded separately below; other source reference constants retain these allowances. The bounded-observer 261.60 ms paging median exceeds its 260 ms reference allowance but remains below its 650 ms CI limit; the shared 2× time scale and 1.25× variance allowance produce CI limits. Memory uses only variance allowance. The shared scale originates in Node CI calibration. Both actual x64 browser runs below pass the fixed budgets on unchanged benchmark code; this supplies repeated-run evidence for these runners, not a universal browser speed ratio.
| Endpoint | Measured median | Reference allowance | Historical CI limit |
|---|---|---|---|
| Browser open | 184.62 ms | 200 ms | 500 ms |
| Slowest older page | 261.60 ms | 260 ms | 650 ms |
| First Trajectory | 136.46 ms | 160 ms | 400 ms |
| First reply | 373.72 ms | 1100 ms | 2750 ms |
| Stream main-thread task | 1053.87 ms | 1800 ms | 4500 ms |
| Draft typing | 487.35 ms | 500 ms | 1250 ms |
| Complete response | 1366.36 ms | 1000 ms overhead + 992 ms pacing | 3492 ms |
| Reconnect replacement | 13.83 ms | 16 ms | 40 ms |
| Reconnect retained heap | 23.03 MiB | 24 MiB | 30 MiB |
Draft typing spans 124.97–504.96 ms across the three isolated samples; the reference remains 500 ms and the scaled CI limit covers that observed spread; the median is not a per-keystroke bound. No budget is an environment override. Temporary zero allowances exercise every rejection path; these negative controls prove enforcement, not an optimization or a historical regression. A separate control waits for the final reply marker before typing and fails the actual-input overlap assertion. The compact synthetic JSONL is 3,262,577 bytes; all three corrected samples report an overlapping trusted input event and end after the 241st rendered turn-tail.
Actual CI runs
Run 34020120425, benchmark job 101451135853 passes the complete benchmark inventory. The runner is VM-7-113-ubuntu-ci-19 in dsh-selfhosted-ci, using x64 Node 24.19.0 and Chromium 149.0.7827.55. Attempt 2, benchmark job 101453296071 (run 34020120425) also passes the complete inventory at the same commit, on VM-7-113-ubuntu-ci-25 with the same Node and Chromium versions. The following medians use three fresh samples per scenario in each run and leave the local reference table and source budgets unchanged.
| Endpoint | First CI median | Second CI median |
|---|---|---|
| Browser open | 303.066 ms | 284.726 ms |
| Slowest older page | 432.979 ms | 413.798 ms |
| First Trajectory | 298.608 ms | 267.372 ms |
| First reply | 740.265 ms | 658.906 ms |
| Stream main-thread task | 1614.594 ms | 1035.385 ms |
| Draft typing | 932.746 ms | 142.148 ms |
| Complete response | 1677.882 ms | 1641.702 ms |
| Reconnect replacement | 29.232 ms | 31.674 ms |
| Reconnect retained heap | 23.028 MiB | 23.028 MiB |
All six browser samples report inputOverlapped: true and finish after the 241st rendered turn-tail. Post-GC browser heap is approximately 52.94 MiB in the first run and 53.00 MiB in the second, with 17,064 DOM elements in both; these remain diagnostic endpoints. Both runs support the existing budgets on these runners, not a universal 2× browser speed ratio. Draft-typing medians vary from 932.746 ms to 142.148 ms because the endpoint measures the entire typed draft, including scheduling and Playwright actionability, rather than a per-key latency guarantee. These are self-hosted measurements, not standard-hosted calibration; no product optimization is claimed.
Standard hosted expectations and input scheduling
Reconnect uses a 50 ms reference-machine allowance through the shared 2× CI time scale and 1.25× headroom, giving a 125 ms ceiling. Two isolated three-sample runs on Linux x64 EPYC 7763 / Node 24.18.0 measure 47.13 and 43.08 ms medians. Hosted Node 24.21.0 runs 36619857675 and 36621172285 measure 55.47 ms on Xeon 8573C and 65.69 ms on EPYC 9V74 with two available CPUs; their measured production path is unchanged. The latter run is 1.39–1.53× the local reconnect medians; its preparing-write and preparing-bash medians are 1.54–1.55× and 1.34–1.42× their local counterparts. The shared 2× factor covers these observed ratios; the raw samples do not isolate hardware from Node-version or scheduling effects. Both local and hosted reconnect runs retain 23.03 MiB, so the 30 MiB memory ceiling is unchanged. The same time assertion accepts recorded hosted medians, rejects the 65.69 ms median at the former 63 ms ceiling, and rejects synthetic 126 and 150 ms values at 125 ms. This is budget calibration, not a product speedup or a passing future CI verdict.
Run 34033336246, job 101487216170 on standard hosted Ubuntu with two CPUs records reconnect replacements of 46.574411, 46.067910, and 44.193704 ms, with 23.028 MiB retained heap. Browser open records 681.276514 and 541.051233 ms before the third sample fails input overlap; both exceed the historical 500 ms limit. Repeated hosted open measurements below set its expectation and ceiling. Deterministic controls pass these recorded values and reject values above the new ceilings through the same assertions as the measured verdicts. Complete repeated hosted verdicts remain required; the two open values are not a three-sample median.
A local diagnostic with temporary 3× Chromium CPU throttling reproduces the overlap failure: the first marker becomes visible at 1321 ms, two animation frames finish at 1370 ms, and the composer click finishes at 1660 ms; the actual input is trusted but already sees DONE. Removing the frame wait and installing the witness before Send still leaves a run with first visibility at 1415 ms and click completion at 1726 ms, after the original 992 ms scripted stream. The fixed 16 ms cadence keeps the same 120 deltas and payload, providing 1984 ms of scripted pacing for this workload. Only that pacing term changes in the complete-wall allowance (4484 ms); input, first-reply, and main-thread overhead allowances remain unchanged. With the same diagnostic slowdown, three 16 ms samples reach first visibility at 1307/1479/1599 ms and accept trusted input before DONE; their post-DONE controls reject it. The diagnostic is not a CPU-ratio calibration. Each measured sample still requires trusted input while FIRST is present and DONE absent; a post-measurement trusted key after DONE must fail that same assertion. Host settlement and the 241st rendered turn-tail remain completion witnesses.
Run 34034524861, job 101490135303 records three complete browser samples with trusted input overlap and passing post-DONE rejection controls. Slowest-page samples are 843.941625/672.834329/684.461818 ms (median 684.461818); first-Trajectory samples are 605.788061/367.754027/485.931656 ms (median 485.931656). Their endpoint-specific hosted expectations are 700 and 500 ms, with the same 1.25× headroom producing 875 and 625 ms limits. Recorded-median controls reject the historical 650/400 ms limits, accept these hosted limits, and reject one millisecond above each limit through the measured verdict's assertion. Open, first reply, main-thread task, input, and complete-wall medians are 713.910/1486.206/2806.415/947.398/2986.983 ms; only the open limit is recalibrated by the repeated measurements below. This run supplies calibration data, not a passing benchmark verdict; a complete hosted repeat remains required.
Run 34036109842, job 101494445658 records open samples of 875.306861/1083.683529/814.700998 ms, with a median of 875.306861 ms versus 713.909727 ms in the preceding hosted run. The endpoint-specific expectation is 900 ms, rounding up the larger repeated median rather than adding an epsilon to the 875 ms limit; unchanged 1.25× headroom gives 1125 ms. The same enforced assertion accepts the recorded median, rejects it at both historical 500 and 875 ms limits, and rejects a synthetic 1126 ms value at the current limit. All three samples retain trusted input overlap and post-DONE rejection; every other frontend median remains within its unchanged limit. This calibration does not claim a green CI run.
A controlled mouse-refocus delay waits for the real DONE marker without pausing replay: the mouse path rejects a trusted input after DONE, while Enter submission and keyboard-only draft input pass all three samples under the same control. The delay is diagnostic-only. A clean three-sample run on arm64 Node 24.19.0 / Chromium 149.0.7827.55 reports first-reply/input/complete-wall medians of 288.823/418.868/2567.328 ms, with actual overlap and post-DONE rejection in every sample. This proves removal of the mouse-action scheduling dependency, not the cause of a particular hosted stall; all workload constants and budgets remain fixed.
The current Trajectory acceptance limit is 650 ms, represented by a 520 ms target with the shared 1.25× headroom. Run 35095609422 records medians of 666.651723 ms and 630.843184 ms on its original attempt and retry. This explicit 4% relaxation of the former 625 ms limit accepts the retry median but still rejects the original median; it is a budget decision, not a measured product speedup. Recorded retry samples exercise the accepted range, and the same verdict assertion rejects 651 ms. Other endpoint budgets and workload parameters remain unchanged.
Older-page control preparation
Older-page measurements wait for a uniquely named attached control before capturing it. Availability and read-only accessibility lookup are preparation; visibility, enabled/stable actionability, the trusted click, turn-tail growth and the final two frames remain timed. The historical 260 ms reference allowance, 261.60 ms median and 700 ms hosted expectation include the lookup that this endpoint excludes.
Local samples with lookup excluded are 141.202083/126.114041/140.003334 ms, median 140.003334 ms. Hosted run 37272669722, benchmark job 111642813553 records 524.083466/355.648835/349.959862 ms, median 355.648835 ms, under the same 875 ms ceiling. These are observed samples, not a new calibration; the 700 ms expectation and 875 ms ceiling remain conservative retained limits pending repeated hosted measurements of this endpoint. The earlier same-checkout 887.624/441.989 ms CI medians include lookup and establish retry-cleared failure, not the composition of the first miss.
Trajectory readiness polling
Trajectory activation samples its visible searchbox and a visible record inside [data-trajectory-scroll] on animation frames. Playwright's selector polling uses increasing delays up to 500 ms, so DOM readiness can precede the observer by hundreds of milliseconds. The trusted tab click, its actionability checks and the final two-frame wait remain timed; workload and the current 650 ms budget are unchanged.
A controlled macOS arm64 diagnostic on Node 24.19.0, Chromium 149.0.7827.55 and Playwright 1.61.1 makes the searchbox and record ready after 300 or 350 ms. Selector waits take 793.082/791.053 ms and observe readiness 493.5/439.2 ms late; frame sampling takes 307.324/357.423 ms and observes it 8.1/7.9 ms late. This isolates conditional observer delay, not product latency or the cause of the first #4119 CI miss.
Complete local 240-turn runs produce Trajectory samples of 157.795/146.737/148.571 ms before the observer change and 130.184/191.247/157.543 ms afterward, with medians 148.571 and 157.543 ms. Both runs pass every fixed endpoint budget; no local speedup or hosted calibration is claimed. The readiness regression rejects a hidden searchbox or record despite a visible unrelated table row; restoring the original selector waits makes that test fail.
Alternatives considered
Use the Node fold as paint evidence. Rejected because it never performs DOM mutation, layout, or browser scheduling. The focused reconnect case likewise makes no GUI speed claim.
Promote the entire manual browser diagnostic into CI. Rejected because its 1,000-session sidebar and 100-turn soak cover a much broader workload. The bounded required case reuses its shipped scaffold and measurement approach without importing a test module or changing the manual inventory.
Coalesce active reconnect chunks. Rejected as a benchmark shortcut: Client entries expose per-member ordering and timestamps to conversation definitions. The benchmark retains that production behavior; reducing retained entries requires a separate semantic design, not copied product algorithms or a synthetic approximation.
Search the entire loaded history for every stream marker. Rejected because Playwright injects text and accessibility scans into the same renderer whose CPU the benchmark measures. Scoping queries to the composer and latest Assistant preserves visible completion checks without making observer cost proportional to loaded history.
Raise the Trajectory budget or retry failed samples. This retains the measured selector backoff and can accept slower product behavior. Frame-based readiness removes that observer delay without changing the budget.
Measure stream CPU alone. Rejected because transport stalls and final-settlement delays can leave main-thread CPU low. The independent input, first-reply, and complete-wall budgets cover those waits.
Consequences
The benchmark layer changes no product implementation or user-visible behavior. It adds approximately fifteen seconds of local browser/reconnect execution plus Web build and browser provisioning to the existing isolated CI lane. A fresh browser discards previous caches, but each workflow deliberately retains its own loaded history and previously activated Trajectory during continuation.
The baseline is independently mergeable and protects current performance; optimization layers tighten budgets only with repeated measurements and focused semantic tests. It does not cover sidebar cardinality, an hours-long soak, GPU presentation, real model latency, a published Host launch, or reconnect rendering. The Web browser lane retains its separate threshold-free manual diagnostics and functional browser tests; calibrated required measurements belong to this benchmark lane. The existing Session performance note remains active because it owns Node calibration and persistence rationale; this note extends rather than supersedes it.
中文
问题
Node 对话折叠很快，并不能证明浏览器能绘制长对话或在流式回复期间保持响应。活跃重连还会重建与已结算历史不同的表示：紧凑前缀变成公开的逐 chunk Client 条目。Session 性能策略提供隔离的 CI job，但不测量这些用户路径。
决策
现有串行基准清单包含两个前端所有者：活跃重连和浏览器工作流。浏览器工作流在一个顺序场景中组合冷打开、更早分页导航、首次激活 Trajectory、返回 Chat，以及伴随真实键盘输入的有节奏回复。这些是同一工作流的测量终点，而不是相互独立的冷场景。已结算对话折叠基准保持不变。
build:bench 保留仅 Node 的 library 与 worker 构建。test:bench 额外构建 Web shell 后再运行所有用例；必需的基准 CI job 遵循标准托管运行器说明，在该托管运行器上无条件安装 Chromium 及其 Linux 依赖，并启用现有门禁详细输出，使成功用例的原始样本可用于校准。浏览器用例复用产品组合的 Web scaffold，使用私有临时目录和原子分配的回环端口。只有不确定的模型被合成重放替代。scaffold Host 通过现有 Vitest 源码解析器运行；被测 Client 渲染在全新 Chromium 进程中执行构建后的 bundle。因此浏览器壁钟时间包含测试 Host、传输、Playwright 可交互性等待及渲染，不代表发布版 Host 进程。
浏览器输入包含 240 个已关闭轮次、40 个工具结果和 20 个代码块，以及混合语言正文和推理。历史 Assistant 记录携带匹配的紧凑 stream，通过生产 accumulator 按 12 字符推理/文本 delta 和 8 字符工具参数 delta 构建；空 stream 会遗漏存储与传输负载成本。从观察到的初始 25 轮窗口开始，九次更早分页操作读完该输入；就绪探针跟踪已挂载轮次增长，不复制分页算法。每个样本使用全新 scaffold 和浏览器。环境准备、数据播种、浏览器启动、初始 shell 加载及侧栏展开不计入打开时间。分页计时前解析恰好一个当前的 Load earlier 控件，将只读的无障碍查找归入准备。875 ms 分页上限仍包含可操作性等待、受信任的点击、已挂载 turn-tail 增长及最后两次动画帧；控件被替换时失败。打开测量在对话可用且输入框可编辑时结束；分页与导航测量在目标 DOM 状态出现时结束。两次动画帧包含一次渲染机会，不代表硬件显示或保证每个屏幕外节点都已绘制。
续接以 16 ms 重放间隔发送 120 个文本 delta。输入观察器在从已聚焦输入框按 Enter 提交前安装；键入保留焦点，不执行鼠标重新聚焦，也不单独等待输入前动画帧。首段/最终标记查找在动画帧上采样最新 Assistant step 内的可见文本，避免选择器重试退避。隐藏文本和较早步骤中的标记均不能满足观察条件。首次观察在浏览器内记录回复标记与焦点；诊断在键入后取回，避免增加输入前的通信往返。诊断还记录首个实际输入事件的浏览器时钟时间戳与焦点。重放从不等待输入；响应阻塞仍可能导致重叠失败。同步输入证据读取同一个受限回复。全历史文本与无障碍查询会向测量区间加入观察器 CPU 和垃圾回收成本，因此减少此类观察工作属于基准修正，而非产品优化。它记录 Enter 提交到首段可见回复的时间、首个实际输入事件观察到首段回复且完成标记尚未出现时的真实草稿键入、直到持久化结算并渲染新 turn-tail 的完整回复壁钟时间，以及 Chromium 主线程任务时间。完整壁钟预算在缩放后的额外开销额度上加固定的 1984 ms 脚本节奏；输入和完成均有独立执行的预算。强制 GC 后的浏览器 heap 和 DOM 数量仍仅供诊断，因为单个终点不能证明泄漏。
重连使用三个全新编译后的纯 Node 子进程。各进程在计时 ClientAssistantStream.replace() 前创建包含不同时间戳、两条紧凑记录和 100,000 个 delta 的推理前缀。在基线前执行 GC，并在结果仍可达时于替换后再次 GC；替换时间不含两次回收。报告在回收后消费结果，并检查下一个稠密序号的实时 frame 仍被接受。这测量重建，不测量传输、渲染或完整重连工作流。
校准
在 arm64 参考机器、Node 24.19、Chromium 149.0.7827.55 和PR #3537 合并结果 上，三个样本的中位数建立下表基线。完整工作流 smoke 后执行一次隔离重复测量。每个浏览器样本报告原始终点数据和每一页；分页判定使用各样本最大值的中位数。重连报告全部子进程测量。下列历史参考表使用 8 ms 重放节奏，首段回复计时包含两帧等待。其中的分页样本包含较早分页控件的无障碍查找。标准托管打开、分页、Trajectory 和重连预期在下文单独记录；其他源码参考常量保留这些额度。受限观察器的分页中位数 261.60 ms 超过 260 ms 参考额度，但仍低于 650 ms CI 限制；共享的 2× 时间倍率和 1.25× 方差余量产生 CI 限制。内存仅使用方差余量。共享倍率源自 Node CI 校准。下述两次实际 x64 浏览器运行在基准代码不变的情况下均通过固定预算；这提供这些 runner 的重复运行证据，而非普遍适用的浏览器速度比。
| 终点 | 实测中位数 | 参考额度 | 历史 CI 限制 |
|---|---|---|---|
| 浏览器打开 | 184.62 ms | 200 ms | 500 ms |
| 最慢更早分页 | 261.60 ms | 260 ms | 650 ms |
| 首次 Trajectory | 136.46 ms | 160 ms | 400 ms |
| 首段回复 | 373.72 ms | 1100 ms | 2750 ms |
| 流式主线程任务 | 1053.87 ms | 1800 ms | 4500 ms |
| 草稿键入 | 487.35 ms | 500 ms | 1250 ms |
| 完整回复 | 1366.36 ms | 1000 ms 额外开销 + 992 ms 节奏 | 3492 ms |
| 重连替换 | 13.83 ms | 16 ms | 40 ms |
| 重连保留 heap | 23.03 MiB | 24 MiB | 30 MiB |
三个隔离样本中的草稿键入时间为 124.97–504.96 ms；参考额度保持 500 ms，缩放后的 CI 限制覆盖观察到的波动；中位数不是单次按键上限。预算不能通过环境变量覆盖。临时零额度覆盖每条拒绝路径；这些负向对照证明预算执行，而非优化或历史回归。另一项对照在键入前等待最终回复标记，实际输入重叠断言因此失败。紧凑合成 JSONL 为 3,262,577 字节；三个修正样本均报告重叠的真实输入事件，并在第 241 个 turn-tail 渲染后结束。
实际 CI 运行
运行 34020120425，基准 job 101451135853 通过完整基准清单。runner 为 dsh-selfhosted-ci 中的 VM-7-113-ubuntu-ci-19，使用 x64 Node 24.19.0 和 Chromium 149.0.7827.55。第 2 次执行，基准 job 101453296071 (run 34020120425) 在相同 commit 上也通过完整清单，runner 为 VM-7-113-ubuntu-ci-25，Node 和 Chromium 版本相同。下列中位数来自每次运行中每个场景的三个全新样本，本地参考表和源码预算保持不变。
| 终点 | 首次 CI 中位数 | 第二次 CI 中位数 |
|---|---|---|
| 浏览器打开 | 303.066 ms | 284.726 ms |
| 最慢更早分页 | 432.979 ms | 413.798 ms |
| 首次 Trajectory | 298.608 ms | 267.372 ms |
| 首段回复 | 740.265 ms | 658.906 ms |
| 流式主线程任务 | 1614.594 ms | 1035.385 ms |
| 草稿键入 | 932.746 ms | 142.148 ms |
| 完整回复 | 1677.882 ms | 1641.702 ms |
| 重连替换 | 29.232 ms | 31.674 ms |
| 重连保留 heap | 23.028 MiB | 23.028 MiB |
六个浏览器样本均报告 inputOverlapped: true，并在第 241 个 turn-tail 渲染后结束。强制 GC 后浏览器 heap 首次运行约为 52.94 MiB，第二次约为 53.00 MiB，两次 DOM 元素均为 17,064 个；这些仍为诊断终点。两次运行支持这些 runner 上的现有预算，而不证明普遍适用的 2× 浏览器速度比。草稿键入中位数从 932.746 ms 变化到 142.148 ms，因为该终点测量整个草稿键入，包含调度和 Playwright 可交互性等待，而非单次按键延迟保证。这些是自托管测量，而非标准托管校准；不声称产品优化。
标准托管预期与输入调度
重连使用 50 ms 参考机器额度，通过共享的 2× CI 时间倍率与 1.25× 余量得到 125 ms 上限。Linux x64 EPYC 7763 / Node 24.18.0 上两轮独立三样本运行的中位数为 47.13 和 43.08 ms。托管 Node 24.21.0 运行 36619857675 与 36621172285 均有两个可用 CPU，分别在 Xeon 8573C 和 EPYC 9V74 上测得 55.47 与 65.69 ms；两次被测的生产路径没有变化。后一轮为本地重连中位数的 1.39–1.53×，其中 preparing-write 与 preparing-bash 中位数分别为本地对应值的 1.54–1.55× 和 1.34–1.42×。共享 2× 系数覆盖这些实测比例；原始样本未区分硬件、Node 版本或调度各自的影响。本地和托管重连都保留 23.03 MiB，因此 30 MiB 内存上限不变。同一个时间断言接受托管记录中位数，在旧 63 ms 上限下拒绝 65.69 ms 中位数，并在 125 ms 上限下拒绝合成的 126 与 150 ms 值。这是预算校准，不代表产品提速，也不代表后续 CI 已通过。
运行 34033336246，job 101487216170 在双 CPU 标准托管 Ubuntu 上记录重连替换时间 46.574411、46.067910 和 44.193704 ms，保留 heap 为 23.028 MiB。浏览器打开记录 681.276514 和 541.051233 ms，第三个样本因输入重叠失败而中止；两个值均超过历史 500 ms 上限。下文的托管打开重复测量决定其预期与上限。确定性对照通过这些记录值，并使用与测量判定相同的断言拒绝超过新上限的值。仍需完整的托管重复运行判定；这两个打开值不是三样本中位数。
临时使用 3× Chromium CPU 降速的本地诊断复现重叠失败：首个标记在 1321 ms 可见，两次动画帧在 1370 ms 结束，输入框点击在 1660 ms 完成；实际输入是真实事件，但已看到 DONE。移除帧等待并在发送前安装观察器后，一次运行仍在 1415 ms 才看到首个标记，点击在 1726 ms 完成，晚于原先 992 ms 的脚本流。固定 16 ms 节奏保留相同的 120 个 delta 和负载，为该工作负载提供 1984 ms 脚本节奏。完整壁钟额度仅改变该节奏项（4484 ms）；输入、首段回复及主线程额外开销额度不变。在相同诊断降速下，三个 16 ms 样本在 1307/1479/1599 ms 达到首段可见状态，并接受 DONE 之前的真实输入；其 DONE 之后的对照拒绝该输入。该诊断不是 CPU 比率校准。每个测量样本仍要求真实输入发生时 FIRST 存在且 DONE 不存在；测量后在 DONE 之后发送的真实按键必须无法通过同一个断言。Host 结算和第 241 个已渲染 turn-tail 仍是完成证据。
运行 34034524861，job 101490135303 记录三个完整浏览器样本，均具有真实输入重叠，并通过 DONE 之后的拒绝对照。最慢分页样本为 843.941625/672.834329/684.461818 ms（中位数 684.461818）；首次 Trajectory 样本为 605.788061/367.754027/485.931656 ms（中位数 485.931656）。两者的终点专属托管预期分别为 700 和 500 ms，相同的 1.25× 余量产生 875 和 625 ms 上限。记录中位数对照拒绝历史 650/400 ms 上限，接受这些托管上限，并通过测量判定所用断言拒绝超过各上限一毫秒的值。打开、首段回复、主线程任务、输入及完整壁钟的中位数为 713.910/1486.206/2806.415/947.398/2986.983 ms；仅打开上限根据下文的重复测量重新校准。该运行提供校准数据，不代表基准判定通过；仍需完整的托管重复运行。
运行 34036109842，job 101494445658 记录打开样本 875.306861/1083.683529/814.700998 ms，中位数为 875.306861 ms，前一次托管运行的中位数为 713.909727 ms。该终点的预期为 900 ms，向上取整较大的重复测量中位数，而非向 875 ms 上限增加微量余量；不变的 1.25× 余量产生 1125 ms 上限。同一个强制断言接受记录中位数，在历史 500 和 875 ms 上限下均拒绝它，并在当前上限下拒绝合成的 1126 ms 值。三个样本均保留真实输入重叠与 DONE 之后的拒绝；其他所有前端中位数均在不变的上限内。此校准不代表 CI 运行通过。
受控的鼠标重新聚焦延迟等待真实 DONE 标记，不暂停重放：鼠标路径拒绝 DONE 之后的真实输入，而 Enter 提交与纯键盘草稿输入在相同对照下通过全部三个样本。该延迟仅用于诊断。在 arm64 Node 24.19.0 / Chromium 149.0.7827.55 上，不含延迟的三个样本报告首段回复/输入/完整壁钟中位数 288.823/418.868/2567.328 ms，每个样本均满足实际重叠并拒绝 DONE 之后的输入。这证明移除了鼠标操作调度依赖，并不证明某次托管停顿的原因；全部工作负载常量和预算保持固定。
当前 Trajectory 验收上限为 650 ms，由 520 ms 目标与共享的 1.25× 余量表示。运行 35095609422 的首次执行与重试分别记录中位数 666.651723 ms 和 630.843184 ms。相较于原先的 625 ms 上限，这次明确的 4% 放宽接受重试中位数，但仍拒绝首次中位数；这是预算决策，不代表测得产品提速。记录的重试样本覆盖新增的接受区间，同一个判定断言拒绝 651 ms。其他终点预算与工作负载参数保持不变。
较早分页控件准备
较早分页测量先等待具有唯一名称的控件挂载，再捕获该控件。可用性与只读的无障碍查找归入准备；可见、启用及稳定等可操作性检查、受信任的点击、turn-tail 增长和最后两帧仍计时。历史 260 ms 参考额度、261.60 ms 中位数及 700 ms 托管预期包含当前终点已排除的查找。
排除查找后的本地样本为 141.202083/126.114041/140.003334 ms，中位数 140.003334 ms。托管运行 37272669722 的 benchmark job 111642813553 记录 524.083466/355.648835/349.959862 ms，中位数 355.648835 ms，仍通过相同的 875 ms 上限。这些是观察样本，不是新校准；700 ms 预期与 875 ms 上限作为保守的现有值保留，待此终点的重复托管测量核验。先前相同 checkout 的 887.624/441.989 ms CI 中位数包含查找，只建立重跑可清除的失败，不分解首次超限的组成。
Trajectory 就绪轮询
Trajectory 激活在动画帧上采样可见搜索框与 [data-trajectory-scroll] 内的可见记录。Playwright 选择器轮询使用逐步增加、最高 500 ms 的延迟，因此 DOM 可能比观察器早数百毫秒就绪。真实 tab 点击、其可交互性检查与最后两帧等待仍计时；工作负载与当前 650 ms 预算不变。
在 macOS arm64、Node 24.19.0、Chromium 149.0.7827.55 和 Playwright 1.61.1 上，受控诊断使搜索框与记录在 300 或 350 ms 后就绪。选择器等待耗时 793.082/791.053 ms，晚 493.5/439.2 ms 观察到就绪；动画帧采样耗时 307.324/357.423 ms，晚 8.1/7.9 ms 观察到就绪。这隔离了有条件发生的观察器延迟，不代表产品延迟，也不能证明 #4119 首次 CI 超限的原因。
完整本地 240 轮运行在修改观察器前得到 Trajectory 样本 157.795/146.737/148.571 ms，修改后为 130.184/191.247/157.543 ms，中位数分别为 148.571 和 157.543 ms。两次运行均通过所有固定终点预算；不声称本地提速或托管环境校准。即使存在可见的无关表格行，就绪回归测试仍拒绝隐藏的搜索框或记录；恢复原选择器等待会使该测试失败。
考虑过的替代方案
用 Node 折叠作为绘制证据。 拒绝，因为它不执行 DOM 修改、布局或浏览器调度。聚焦重连用例同样不声称 GUI 提速。
把整个手动浏览器诊断提升到 CI。 拒绝，因为其 1,000 Session 侧栏和 100 轮 soak 覆盖更广的工作负载。受限的必需用例复用其产品 scaffold 和测量方式，不导入测试模块，也不改变手动清单。
合并活跃重连 chunk。 不能作为基准捷径：Client 条目向对话定义公开每个成员的顺序和时间戳。基准保留该生产行为；减少保留条目需要独立的语义设计，而非复制产品算法或使用合成近似。
每次流式标记查找都搜索全部已加载历史。 拒绝，因为 Playwright 把文本与无障碍扫描注入同一个被测 CPU 的渲染进程。将查询限定在输入框和最新 Assistant 中，可保留可见完成检查，同时避免观察器成本随已加载历史增长。
提高 Trajectory 预算或重试失败样本。 这会保留已测得的选择器退避，并可能接受更慢的产品行为。基于动画帧的就绪观察移除该观察器延迟，不改变预算。
只测量流式 CPU。 拒绝，因为传输停顿和最终结算延迟可能不增加主线程 CPU。独立的输入、首段回复和完整壁钟预算覆盖这些等待。
影响
基准层不改变产品实现或用户可见行为。它在现有隔离 CI lane 中增加约十五秒的本地浏览器与重连执行，以及 Web 构建和浏览器安装成本。全新浏览器丢弃此前的缓存，但每个工作流刻意在续接期间保留自身已加载历史和曾激活的 Trajectory。
基线可独立合并并保护现有性能；优化层只有在重复测量与聚焦语义测试支持下才收紧预算。它不覆盖侧栏数量级、数小时 soak、GPU 显示、真实模型延迟、发布版 Host 启动或重连渲染。Web 浏览器车道保留独立的无阈值手动诊断与功能浏览器测试；经校准的必需测量由本基准车道负责。现有 Session 性能记录保持活跃，因为它拥有 Node 校准和持久化理由；本记录扩展而不替代它。