[2026-10-27] eagle: work/projects/cpm-post-release-analysis-2026-10-27.md

work/projects/cpm-post-release-analysis-2026-10-27.md

@@ -196,3 +196,4 @@ The harness differs from macOS production in four ways:
 | 200,000 | **10.9 s, 1 lost** | 0.1 s |
 
 `reloadExtension` itself returns in ~20 ms; the delay is WebKit migrating extension data to the new origin before content scripts run. Roughly linear, ~50 µs per cache entry. Cookie seeding on 5,000 `.test` domains did not create website data records (still 2), so per-site record cost is untested. The same migration runs on every **app launch** in released builds, which links this to the P3 startup cohort. **P3 (#7493) removes it in both cases.** It explains `reload_state=response_timed_out` and extended post-reload silence; whether real caches are large enough for a full 5-minute silence is being checked at 600,000 entries.
+- **600,000 entries, released origin:** first `initResp` **32.2 s** after the reload, **5 navigations lost**; still linear (~53 µs/entry). Page loads during the migration were also slower (one took 9 s), so the migration may delay browsing generally, not only CPM. A full 5-minute silence would need ~5–6M entries by extrapolation, so this explains post-reload silences of seconds to about a minute, not the whole deadline. The same blackout hits **every app launch** on released builds. With P3, 0.1 s at every size.