BM-001 — Web Performance Gates · bm-001-web-perf
Owner directive (2026-07-10), canonical. "Make canonically optimal performance for any type of Environment (…) after the loading the experience is as fluid and light as scientifically possible" [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:459] — "doesnt matter the device, 15 years old mobile, if they can run HD on Netflix with perfect flow and zero lag/fps/processing, this architecture should be possible." [src: :463] — "perfomance awesome, you may have loading, no worries, but the experience should be pristine" [src: :652]
Content
BM-001 is the set of hard gates every page of the HOS-Instance (spatial-site and functional pages alike) must pass before a delivery is accepted. The numeric gates are squad-eggtech's (RUN-017) quantitative encoding of the owner's qualitative mandate above; they may only be tightened, or recalibrated with measured evidence logged in the run heartbeat (sop-003-run-dispatch). Loading may be long (owner allows it [src: :652]); all gates below apply post-load.
Hard gates
| Gate | Desktop | Old-phone / mobile | Notes |
|---|---|---|---|
| Post-load FPS (EMA) | ≥ 55 | ≥ 30 | exponential moving average over the active scene; measured via rAF instrumentation (cb-patterns-royal-orbit raf-guard pattern) |
| LCP | ≤ 2.5 s | ≤ 2.5 s | Largest Contentful Paint, cold cache, per route |
Critical JS — route / | ≤ 200 KB gz | ≤ 200 KB gz | critical path only; deferred chunks excluded |
| Critical JS — routes 2–5 | ≤ 120 KB gz each | ≤ 120 KB gz each | the four secondary pages of okrs-2026-h2 KR1 |
| JS heap (steady state) | ≤ 300 MB | ≤ 180 MB | after 2 min of scroll interaction, no growth trend (leak = fail) |
| Scroll long-task | ≤ 4 ms p95 | ≤ 4 ms p95 | per scroll-driven handler (cb-lenis / cb-gsap work must stay inside this) |
| Lighthouse — Performance | ≥ 90 | ≥ 90 | mobile emulation for the mobile column |
| Lighthouse — Accessibility | = 100 | = 100 | parity with the RUN-015 bar |
| Lighthouse — Best Practices / SEO | ≥ 95 / ≥ 90 | ≥ 95 / ≥ 90 |
Measurement procedure
- Run gates on the two reference tiers: a desktop profile and a throttled old-phone profile (CPU 4× slowdown, mid-tier GPU) — the owner's "15 years old mobile" bound [src: :463].
- Collect via DevTools traces + Lighthouse (
nw-devtools-149in the equipped gear-sets); FPS EMA and heap via the page's own QA hooks. - Record each gate's value in the run heartbeat; the dispatch accepts or refuses the delivery on these numbers (sop-003-run-dispatch step 5).
- A red gate blocks the row; the responsible datan retries under the academy rule (sop-001-loop-execution).
Verdict rule
All gates green on both tiers → the delivery is release-eligible and counts toward okrs-2026-h2 KR2. Any red gate → the delivery is refused; partial passes are not recorded as passes.
Composition
- uses: cb-vite (bundle-size discipline) · cb-lenis / cb-gsap (scroll work under the long-task gate) · sop-003-run-dispatch (accept/refuse mechanics)
- used-by: gear-sets (
page-authoring,scroll-motion,build-toolinggates) · squad-eggtech (owner of the gates) · squad-instance (deliveries measured against them) · okrs-2026-h2 (KR2) · pb-001-spatial-site-loop (row acceptance criteria)
See also
- bm-002-splat-budget — the splat-specific budget that composes with these gates
- bp-001-spatial-site — the blueprint whose stages cite these gates