Rubric: Performance Architect
Purpose
Use this rubric to evaluate whether an engineer can own frontend performance as a system capability.
Capability rubric
| Capability | Level 3 | Level 4 | Level 5 |
|---|---|---|---|
| Cost modeling | Explains bytes, requests, main-thread work, layout, hydration, and third-party cost. | Builds route-level cost maps and prioritizes work by user impact. | Teaches cost modeling and embeds it into design review. |
| Web Vitals | Understands LCP, INP, CLS, and p75 measurement. | Segments metrics by route, device, network, release, and experiment. | Runs performance governance across a product portfolio. |
| Profiling | Uses DevTools and React profiles to diagnose common slowness. | Correlates traces, RUM, bundle analysis, and component profiles. | Builds repeatable diagnosis playbooks for teams. |
| Rendering/data tradeoffs | Avoids obvious hydration and waterfall mistakes. | Shapes route rendering, streaming, caching, and data-fetching around budgets. | Creates shared rendering strategy standards. |
| Budgeting | Defines simple budgets. | Enforces budgets in CI and review with exception policy. | Connects budgets to product OKRs and release risk. |
| Third-party governance | Audits script cost. | Defines ownership, loading strategy, kill switches, and monitoring. | Manages third-party risk as a platform process. |
| Incident response | Can investigate regressions. | Runs performance incidents with rollback and postmortem actions. | Turns incidents into platform investments. |
Required evidence
- A budget for at least three routes.
- A before/after trace for one slow route or interaction.
- A third-party script register.
- A CI or review gate proposal.
- A performance incident or simulated incident report.
Minimum passing standard
For performance architect readiness, level 4 is required in Web Vitals, profiling, budgeting, and rendering/data tradeoffs. Level 5 should be expected only for people shaping standards across multiple teams.
Calibration scenarios
| Scenario | Strong level 4 behavior |
|---|---|
| Mobile INP regression on a table route | Correlates RUM by route/device/release, captures trace, identifies main-thread work, sets interaction budget, and adds regression guard. |
| LCP regression after hero redesign | Separates image, font, server, cache, and render costs; validates with field data rather than only Lighthouse. |
| Third-party script slows a lead funnel | Uses third-party register, kill switch, route budget, and conversion plus Web Vitals segmentation. |
| RSC migration reduces JS but worsens task completion | Balances bundle cost with cache, mutation, loading, and workflow metrics. |
Not-yet-ready signals
- Recommends memoization before measuring.
- Uses average metrics instead of p75/p95 cohorts.
- Treats Lighthouse as enough evidence for production decisions.
- Ignores third-party scripts, fonts, images, and experiments.
- Cannot explain rollback criteria for a performance change.
Exercises
- Create a performance budget for three routes with different user journeys.
- Capture one trace for a slow interaction and write the bottleneck explanation.
- Build a third-party script register and identify one script to defer, remove, or isolate.
- Write a performance incident summary with detection, mitigation, root cause, and prevention controls.