Frontend Performance

The performance a user actually feels happens in the browser: how fast the page appears, becomes usable, and responds to clicks. A fast backend behind a heavy frontend still feels slow. Keep what you ship to the browser small, load it smartly, and measure with the metrics that reflect real experience.

Backend performance (Performance & Resource Use) is about throughput and resources. Frontend performance is about how fast the page feels on real devices and networks, which are often slower than a developer's laptop. The biggest factors are how much JavaScript and how many assets you ship, how and when they load, and avoiding work that blocks rendering or interaction.

The industry standard is Core Web Vitals: how quickly the main content appears (LCP), how soon the page responds to input (INP), and how much the layout jumps around (CLS). You do not need to memorise them. Just ship less, load it lazily, and measure.

Ship less, load it smartly

• DoKeep the JavaScript and asset bundle small. Code-split and lazy-load so users download only what the current page needs, not the whole app upfront.
• DoOptimise images and media (right size, modern formats, lazy-load below the fold). They are usually the heaviest thing on a page.
• DoAvoid layout shift: reserve space for images, ads, and async content so the page does not jump as it loads.
• ConsiderCaching static assets aggressively with fingerprinted filenames, and serving them from a CDN where it helps (see Caching Strategy).
• AvoidPulling in large libraries for a small need, or shipping the same heavy dependency several ways. Check bundle size before adding to it (see Dependency & Supply-Chain Security).

Keep it responsive and measured

• DoKeep the main thread free. Do not do heavy work that blocks the page from responding to clicks and input.
• DoFetch only the data the view needs, page large lists, and avoid chains of dependent requests (see API & Contract Design).
• DoMeasure real-world performance (Core Web Vitals or real-user monitoring), not just a fast local run on a fast machine.
• ConsiderTesting on a throttled connection and a mid-range device to see what real users experience.
• AvoidOptimising render code too early. Fix the big wins first (bundle size, images, requests), guided by measurement (see Performance & Resource Use).

Self-review checklist

• AskHow much JavaScript and how many assets does this page download, and does it need all of it now?
• AskAre images sized and optimised, and does the layout stay stable as things load?
• AskDoes the page stay responsive to input, or is the main thread blocked?
• AskHave I measured this on a realistic device and network, not just my machine?