Set performance budgets around user-visible work

Performance work can drift into optimizing whichever score is easiest to graph. A budget is more useful when it is tied to a task: opening a product page on a mid-range phone, filtering a catalog, or saving a form over a slow connection.

Choose a user journey

Start with the routes and interactions that affect the product's primary job. Measure on representative hardware and network conditions. Track both initial rendering and interaction latency; a page that paints quickly but freezes while filtering still feels slow.

Use budgets that teams can act on

Budgets can cover JavaScript transfer size, image weight, long tasks, API response time, or a user-facing metric such as Largest Contentful Paint. Choose a small set. A limit should have an owner and a remedy, not merely create a failing check that everyone learns to ignore.

Measure the right layer

Use browser tooling to find whether the delay is network, server, image decode, layout, or scripting. In production, collect privacy-conscious field metrics by route and device class. Do not treat a single synthetic run as truth; compare repeated runs and investigate large changes rather than chasing noise.

Prevent regressions

• Serve appropriately sized images and reserve their layout space.
• Load noncritical work after the content the user needs.
• Paginate large result sets and avoid repeated client-side full scans.
• Use route-level checks in CI and inspect real-user trends after release.

Accessibility and performance often reinforce each other: clear feedback, semantic controls, and fewer unnecessary animations make interfaces easier to use across devices. A budget is not a demand to make every page minimal; it is a shared constraint that protects the experience as features accumulate.