performance-benchmark

Record a baseline metric on the original code, apply the change, then re-run the identical measurement under the same environment, input size, and sample conditions. Compare the two numeric results rather than relying on subjective impressions of speed.

Match the metric to the user-visible problem: LCP and Lighthouse for load experience, route transition timing for navigation, bundle size for delivery weight, and long-list scroll behavior for rendering. Avoid collapsing different problems into one generic score.

Run the same script with the same input size and environment assumptions on both revisions, then compare runtime numerically. Repo scripts like simulate-1000-users.ts can act as repeatable baseline harnesses for non-UI work.

Measure first. Compare main-package size reduction and target-page first-open latency with an ordinary subpackage plus preload, and only test an independent subpackage if bootstrap cost still dominates. Include duplication and bootstrap overhead in the comparison.

A claim of faster with no metric and no comparison point is not a benchmark. Every result needs at least one concrete metric, a baseline for comparison, and stated environment assumptions so another engineer can reproduce it.