What Problem This Solves

The first HTML web_fetch in a Gateway process spends time loading Readability's DOM dependencies. A live Gateway CPU profile showed substantial module-read, compilation, and resolution activity beneath that first extraction.

Why This Change Was Made

Use LinkeDOM's documented linkedom/worker entry, which bundles its DOM dependencies, through the existing lazy Readability loader. The dependency version, plugin boundary, sanitization, extraction modes, limits, and fallback behavior remain unchanged. The worker entry omits native Canvas support; OpenClaw removes canvas elements before Readability sees the HTML.

The measured tradeoff is approximately 30 ms less first-extraction work with some slower early Markdown calls. The complete fixed workload still finishes faster. The real Gateway proof below exercises both extraction modes; no universal or steady-state speedup is claimed.

User Impact

In the fixed comparison, median first extraction fell from 64.795 to 32.944 ms and from 62.392 to 32.595 ms in the reverse order, reductions of 49.16% and 47.76%. Including extractor module loading, cold latency improved 32.83% and 31.91%.

The same processes showed early-call regressions: article Markdown increased 0.782/0.728 ms, and formatting Markdown increased 1.506/1.644 ms. These were the second and fourth extractor calls respectively, not sustained throughput measurements. A roughly 20-fetch break-even assumes the latter penalty persists and is not established by this experiment.

Evidence

• One fixed B0/C0/C1/B1 cohort, five fresh processes for each dependency/extractor mode per phase: 40 children, no reruns or discarded samples. Complete results match across all variants: 20 dependency parses and 380 extractor results, including text/Markdown, relative links/media, malformed HTML, hidden content, canvas removal, and null results at empty/size/depth boundaries.
• All 40 native receipts show exit 0, process-family closure, and no owner problems; stdout/stderr hashes and byte counts were independently checked. Whole extractor process median wall time improved 14.03%/15.52%; kernel-child peak RSS medians decreased 3.37%/2.77%. Sampled tree RSS is too sparse for these short processes and is not used for a memory claim.
• Every measured field is retained: 3/30 cold timing comparisons, 68/108 fixture timing comparisons, 1/204 process-reported resource comparisons, and 4/60 native timing/resource comparisons were adverse. These counters overlap and are not independent experiments. Of the fixture medians, 22/36 were slower; observed extrema are not population tails.
• Existing owner/sibling tests passed 54/54 across three complete files: the Readability extractor, HTML visibility/unicode handling, and runtime extractor dispatch/cache behavior.
• Normal pnpm build passed in 273.07 seconds, including declarations and plugin outputs. The built extractor uses the lazy public worker entry. Source identity stayed unchanged; 122 observed processes and 45 groups were closed. The extractor has no sourcemap.
• Managed P2 source review was scoped-clean. Production delta is +1 line; no tests, dependency versions, configuration, or persistent-store contracts changed.

Timing, owner tests, source review, and the completed build above belong to frozen base 5b099995413589f41904cef1413c62239542aa7c plus this exact patch. The checkout has since fast-forwarded to fd22d08e2dd4d5fd9134d9a627262b665115a532; the candidate patch, affected extractor/caller/sibling sources, package file, and lockfile are unchanged. The normal 24-command changed gate passed against the new base in 238.52 seconds, without skips. A fresh normal build at clean candidate commit a30b73b470514c426fa4d6bb5bc4a054495d7b9e passed in 218.54 seconds, with unchanged source and complete closure of 118 observed processes / 44 groups. The built extractor bytes match the earlier measured entry. Live Gateway proof ran on that clean commit; no old build receipt has been relabeled.

The real OpenAI Gateway run completed all 10 turns. The original nine campaign turns passed all answer/tool checks. Both actual web-fetch results explicitly selected Readability, returned HTTP 200, and matched their persisted replies: Markdown took 228 ms; text took 188 ms. The separate text follow-up failed its frozen exact-answer oracle because it returned purpose: "documentation examples" rather than "documentation"; its tool result was successful and supported that description. The aggregate remains failed (9/10 exact-answer passes, 10/10 tool-oracle passes), with no rerun or oracle change.

Readiness was observed at 4.033 seconds; sampled process-tree RSS peaked at 1.639 GB. These are contextual observations, not attributed readiness or memory gains. Both CPU profiles have valid sample/delta arithmetic and node references, but hit-count inconsistencies are retained and no precise per-function or per-turn timing claim is made. Runtime and audit processes are closed. Required exact-head GitHub review/CI checks remain a separate landing gate.

Before publication, the unchanged source patch was merged with main d1dce5857a3accfa791e13a1673d8def5d6031ce, including upstream #139794, which repairs an unrelated history-fixture type error. Earlier measurements, local checks, and any local build/live proof retain their explicitly stated source identities. No numerical or live run was repeated or relabeled for this mechanical refresh.