Appendix B — The 90‑day roadmap¶
A sequenced plan for a team starting from a neglected large commerce site. Adjust the durations to your team size; the order is the part that matters.
Assumes roughly 1.5 engineers dedicated plus part‑time help from squad owners.
Week 0 — Before you start¶
| Deliverable | Owner | Exit criteria |
|---|---|---|
| Executive sponsor identified | You | One named person who will defend the work in planning |
| Reference sheet built | You | Lab 0.1 complete |
| The money line agreed | You + finance partner | "+1% relative conversion = $X/yr" written down and accepted |
| Success criteria pre‑registered | You + sponsor | Which metrics, on which pages, measured how |
Don't skip this. A performance program without a sponsor gets deprioritized in week 6, and one without agreed success criteria gets argued about in week 12.
Phase 1 — See (weeks 1–2)¶
Goal: you can answer "what is slow, for whom, and why" in under five minutes.
| Week | Work | Exit criteria |
|---|---|---|
| 1 | RUM with attribution (9.1) | Data flowing, dimensions verified, paths normalized |
| 1 | Lab baseline (1.4) | scripts/perf-compare.sh committed; baseline JSON dated |
| 2 | Four dashboards | Engineering dashboard used daily by at least one person |
| 2 | Third‑party inventory (2.3) | Table with bytes, ms, and a named owner per tag |
| 2 | Full audit (Appendix A) | Scored; top 20 gaps listed |
Ship nothing else in these two weeks. The temptation to "just fix the obvious image thing" is strong; resist it, because you won't be able to prove the win.
Milestone: present the baseline and the third‑party inventory to your sponsor. This meeting is where the rest of the program gets funded.
Phase 2 — Quick wins (weeks 3–5)¶
Goal: a visible, measurable improvement that buys credibility for the architectural work.
| Week | Work | Expected |
|---|---|---|
| 3 | Image pipeline (2.1): sizes, priority, AVIF, LCP image in HTML |
LCP −0.8 to −1.5 s |
| 3 | Fonts (2.2): next/font, metric fallbacks, variable fonts |
CLS −0.05, LCP −0.2 s |
| 4 | CLS sweep (6.3): banners, ads, late content | CLS → < 0.05 |
| 4 | bfcache (8.3) | Back nav −1.5 s; restore rate > 70% |
| 4 | Delivery (2.4): compression, cache headers, cache key, preconnect | TTFB −200 ms on hits |
| 5 | Third parties (2.3): facades, idle loading, dead tag removal | TBT −300 to −900 ms |
| 5 | First CI gate: bundle budget (9.2) | Gate live, PR comment working |
Milestone (end of week 5): field p75 LCP down 25–40%, CLS near zero. Publish the numbers. This is the result that makes Phase 3 possible.
Ship these behind flags where you can, and A/B at least one of them so you have a measured conversion number rather than a metric number. The image work is the easiest to A/B and usually the largest effect.
Phase 3 — Payload (weeks 6–9)¶
Goal: halve the JavaScript. This makes every later change cheaper and fixes INP for free.
| Week | Work | Expected |
|---|---|---|
| 6 | Bundle analysis (4.1); attribution table with owners | Every item > 15 KB has an owner and an action |
| 6 | Barrel imports + optimizePackageImports (4.3) |
−100 to −250 KB |
| 7 | Dependency swaps: dates, icons, carousels, animation (4.3) | −100 to −250 KB |
| 7–8 | Boundary hygiene (3.2): providers out of the root, children pass‑through, client leaves |
−150 to −300 KB |
| 8 | Code splitting (4.2): interaction splits with preload | −100 to −350 KB initial |
| 9 | RSC payload audit + boundary mappers | RSC payload < 80 KB per route |
| 9 | Gates: route mode, client boundary ratchet, third‑party origins | Three more gates live |
Milestone (end of week 9): JS per route within budget. INP will have improved 20–40% as a side effect of reduced hydration cost, without any INP‑specific work.
Phase 4 — Architecture (weeks 10–13)¶
Goal: fix TTFB structurally. One page type at a time, flagged and canaried.
| Week | Work | Expected |
|---|---|---|
| 10 | Waterfall elimination (7.1): parallelize, preload pattern, timeouts | Server time −40 to −60% |
| 10 | Streaming (3.3) on the two worst page types | TTFB −300 to −1,000 ms |
| 11 | Middleware audit (3.7) | Middleware p95 ≤ 5 ms |
| 11 | Cache layer map + shared cache handler (3.4) | ISR hit ratio > 90% |
| 12 | ISR for PLP (3.5) with event‑driven revalidation | PLP TTFB → < 200 ms |
| 12 | Cross‑user cache isolation test in CI | Test passing, blocking merges |
| 13 | PPR for PDP (3.6), behind a flag, 1% → 50% | PDP TTFB → < 150 ms |
Milestone (end of week 13): TTFB under 400 ms on cacheable routes, CDN HTML hit ratio > 90%, origin compute down 60–75%.
The isolation test is not optional and it is not a week‑13 task. Write it in week 12, before the first PPR canary. Caching personalized data is the one mistake in this course that is a reportable incident rather than a slow page.
What's after 90 days¶
INP is a longer grind than LCP — plan a full quarter for it.
| Quarter 2 | Work |
|---|---|
| Weeks 1–3 | State architecture (5.3): context splitting, URL state, external stores |
| Weeks 3–5 | Concurrency (5.5): transitions on every expensive interaction |
| Weeks 5–6 | Memoization / React Compiler (5.2) |
| Weeks 6–7 | Hydration cost (4.4); mismatch elimination |
| Weeks 7–8 | Virtualization where actually needed (5.4) |
| Weeks 8–10 | Checkout (7.4): route split, third‑party removal, form work |
| Weeks 10–12 | Memory (8.4), speculation (8.1), experimentation platform (8.5) |
| Quarter 3+ | Work |
|---|---|
| Multi‑region (8.6) — expensive, do it last | |
| Design system perf refactor (2.5) | |
| Search overhaul (7.3) | |
| The practice (9.4): ownership, scorecard, rituals |
Expected trajectory¶
Illustrative, for a neglected large commerce site (Aurora's actual path):
| Start | Wk 5 | Wk 9 | Wk 13 | Q2 end | |
|---|---|---|---|---|---|
| PDP LCP (p75 mobile) | 4.6 s | 3.1 s | 2.7 s | 2.2 s | 1.9 s |
| PLP INP (p75 mobile) | 410 ms | 380 ms | 265 ms | 240 ms | 118 ms |
| PDP CLS | 0.26 | 0.04 | 0.03 | 0.02 | 0.01 |
| PDP TTFB | 910 ms | 720 ms | 690 ms | 150 ms | 85 ms |
| PDP JS (gz) | 734 KB | 712 KB | 341 KB | 268 KB | 247 KB |
| CWV "good" sessions | 22% | 44% | 58% | 74% | 81% |
Note the shape: LCP and CLS move early and fast; INP barely moves until Q2. Set expectations accordingly — a stakeholder who expects INP to follow LCP in week 5 will think the program is failing when it isn't.
Risks and mitigations¶
| Risk | Mitigation |
|---|---|
| Quick wins get absorbed and nobody notices | Publish the week‑5 numbers loudly; A/B at least one change |
| Architectural work slips into a rewrite | One page type at a time; flag everything; hard scope |
| Cached personalized data leaks | The isolation test, written before the first canary |
| Stale prices after ISR | Event‑driven purge + cart repricing, both, before ISR ships |
| Team pulled onto features in week 7 | Sponsor agreement upfront, with the week‑5 result as evidence |
| Gates disabled during a crunch | Exception process that's faster than disabling the gate |
| Peak season freeze | Finish architectural work 6 weeks before freeze, or defer it |
The one‑page version¶
Weeks 1-2 SEE RUM, baselines, inventory, audit. Ship nothing.
Weeks 3-5 QUICK WINS Images, fonts, CLS, bfcache, delivery, third parties, first gate.
→ LCP -30%, CLS -85%. Publish. Get funded.
Weeks 6-9 PAYLOAD Barrels, dependencies, boundaries, splitting, more gates.
→ JS -60%. INP improves for free.
Weeks 10-13 ARCHITECTURE Waterfalls, streaming, caching, ISR, PPR. Flagged, canaried.
→ TTFB -80%. Origin cost -70%.
Quarter 2 INTERACTION State, concurrency, hydration, checkout.
→ INP -70%.
Quarter 3+ DEPTH Multi-region, design system, search, and the practice.
Pin that somewhere visible. The most common way this work fails is doing Phase 4 before Phase 1.