Client-Side Performance

Web vitals; bundle size.

Overview

Client-side performance dominates user-perceived speed even when the backend is fast. Web vitals, bundle size, and real-user monitoring define the surface to optimise.

• Web vitals. LCP, INP, and CLS. The three metrics Google uses for ranking and the three users actually feel.
• Bundle-size budgets. Per-page JavaScript budget. CI fails when a bundle grows past its budget without explicit approval.
• Lazy loading and route splitting. Components and routes load on demand. The first-screen bundle stays small.
• Real user monitoring. Field data from real visitors confirms or refutes the synthetic Lighthouse run. RUM is the truth.

The approach

Three habits keep client-side performance from drifting: budgets are enforced in CI, lazy loading is the default, and RUM data steers the optimisation backlog.

• Bundle budgets in CI. Per-page JS budget; PRs that bust it fail the build. Approval requires explicit acknowledgment, not silence.
• Lazy load by default. Components below the fold load on demand. The first-paint payload stays minimal.
• Per-route splitting. Each route ships its own bundle. Visitors download what they use, not what they might.
• RUM-driven backlog. Real user p75 numbers prioritise the next optimisation, not Lighthouse scores in isolation.

Why this compounds

Each enforced budget keeps the team out of a slow-creep regression. The discipline compounds because performance becomes part of how the team ships, not a special project.

• Better user experience. Fast pages produce measurable engagement and conversion gains. The numbers match the feel.
• SEO benefit. Web vitals are ranking signals. The discipline aligns user experience with search visibility.
• Engineering culture. Performance becomes part of every PR review. Reviewers ask “does this stay under budget?” reflexively.
• Year-one investment, year-two habit. The first budget enforcement takes effort. By year two, regressions are caught before merge.