Performance Is a Feature

Statement

Fast and responsive UI is part of the user experience, not an optimisation task for later. Every interaction should feel instant.

What this means in practice

Performance is designed in from the start, not bolted on before release. The goal is that every click, navigation, and transition feels immediate — the UI should acknowledge user actions in under 100ms, not leave people waiting and wondering.

• Bundle size is actively managed: code-splitting, tree-shaking, and lazy loading are standard, not stretch goals.

• Render cycles are understood and controlled — unnecessary re-renders are treated as bugs, not acceptable overhead.

• Data fetching is strategic: prefetch data the user is likely to need next, cache aggressively where safe, and avoid redundant network requests.

• Optimistic UI updates are used for actions where the outcome is predictable, so the interface responds before the server confirms.

• Heavy computation is offloaded from the main thread (Web Workers, deferred processing) to keep the UI thread free for interaction.

• Performance budgets are defined for key metrics (bundle size, Time to Interactive, Largest Contentful Paint, Interaction to Next Paint) and enforced in CI.

Why this matters

Perceived performance directly shapes how users feel about the product.

• A 200ms delay between a click and visible feedback breaks the illusion of direct manipulation and makes the product feel sluggish.

• Users associate slow interfaces with low quality, regardless of how feature-rich the product is.

• Performance debt compounds: small regressions accumulate into noticeable degradation that is expensive to reverse.

• Snappy interfaces reduce user frustration, increase task completion rates, and improve overall satisfaction.

• Competitors who invest in performance set user expectations — falling behind is immediately felt.

• Treating performance as a feature means it gets resourced, measured, and prioritised like any other requirement.

Practices that meet this principle

• Set and enforce performance budgets for JavaScript bundle size, CSS payload, and key Web Vitals (LCP, INP, CLS).

• Use code-splitting and dynamic imports so users only download the code they need for the current view.

• Profile render behaviour regularly — use framework dev tools to identify and eliminate unnecessary re-renders.

• Prefetch data and assets for likely next navigations (e.g. on hover, on route proximity, or during idle time).

• Implement optimistic updates for user actions like saves, toggles, and form submissions where rollback is straightforward.

• Lazy-load images, heavy components, and below-the-fold content.

• Monitor real-user performance metrics (RUM) in production and alert on regressions.

• Include performance checks in pull request reviews — flag new dependencies, large assets, or unoptimised data fetching patterns.

• Use loading skeletons and instant visual feedback to maintain perceived responsiveness during unavoidable waits.

Validation

A project meets this principle when:

• User interactions (clicks, navigations, form submissions) produce visible feedback within 100ms.

• Performance budgets are defined, tracked in CI, and consistently met.

• Bundle sizes are actively managed with code-splitting and tree-shaking; no single route loads unnecessary code.

• Data fetching uses caching and prefetching strategies, with no redundant or waterfall requests on critical paths.

• Unnecessary re-renders are identified and resolved during development, not deferred.

• Real-user performance metrics are monitored in production and regressions are addressed promptly.

• Performance is discussed in planning and review, not only when users complain.

Potential blockers

• Third-party scripts and dependencies that add significant weight or block the main thread.

• Legacy architecture without code-splitting or lazy loading, requiring significant refactoring to retrofit.

• Lack of real-user monitoring making it difficult to detect regressions before users report them.

• Cultural perception that performance work is "nice to have" rather than a core feature requirement.