Restore native boot scheduling without an extra core request

This commit is contained in:
Jonathan Sykes
2026-10-08 11:25:03 +08:00
parent 9408ee07e5
commit 4b1f5204f8
12 changed files with 136 additions and 97 deletions

View File

@@ -41,9 +41,9 @@ and is diagnostic only; the shipping fix must retain selected-layout behavior.
The modern synchronizer already uses default fetch caching. Changing it to
force-cache has no effect: every WebKit sample still transfers app.js twice.
The page and worker cannot reuse these HTTP-cache responses in this harness.
A same-build page handoff can reuse the page HTTP cache instead. Worker validation
must check both the X-Asset-Hash header and SHA-256 of the decoded bytes. It must
strip compressed transport headers before constructing the cached Response.
The next hypothesis was a same-build page handoff reusing the page HTTP cache.
The prototype checked both the X-Asset-Hash header and decoded-body SHA-256, and
stripped compressed transport headers before constructing the cached Response.
Updates and legacy migration must continue through their existing worker path.
The shipping CSS fix is a preload, not an unconditional stylesheet. Its three-run
@@ -113,3 +113,25 @@ visits. Controlled warm/offline/update pages use the worker's native exact-URL
script path, including its strengthened contract guard. A failing head-loader
test precedes this change; all 222 frontend and 184 server tests and both-engine
lazy smoke pass. Cold capture and both rollback flags are unchanged.
The final native-path review caught a new Chromium paint regression: five-run
FCP 1616/2328 ms (LTE/lossy), despite faster boot. A contemporary Phase 5 LTE
control measured 1360 ms over three runs. Lowering the new app preload priority
reduced FCP to 1396 ms (three runs). Native parser execution restores app's
original DOMContentLoaded boot boundary. A rejected no-preload controlled-page
trial worsened WebKit warm boot to 98 ms; native cache preloading remains.
The standalone helper adds a CacheStorage script read to native startup. Packing
the loader into the existing final core script, section-rail.js, measured Chrome
warm 425 ms versus contemporary Phase 5 426 ms (five runs); WebKit measured
95 ms versus 88 ms, so zero warm overhead is not yet established. The merged
three-run Chrome LTE cold trial measured FCP 1384 ms and boot 6512 ms. Core's
contract becomes 2 because an old section script lacks this loader and cannot
safely substitute for it. No Phase 5 SHELL file is removed; the experimental
Phase 6 standalone helper is removed. Native-order, exact final-script packing
and contract tests precede implementation. All 223 frontend and 184 server tests
and both-engine lazy/offline/eviction/pinning/contracts/playback smoke pass.
The intermediate native-auto-priority full dataset is retained as a rejected
trial; it is not the final acceptance result. Source directories named in trial
JSONs are dirty diagnostic worktrees of 9408ee0 with exactly the changes above.