Web Performance
Web performance is how fast and smooth a site feels to real users — shaped by the network, JavaScript execution, rendering, images, caching, and backend response time. It's not a vanity metric: speed drives engagement, conversions, and search ranking.
The cardinal rule is measure first. Performance work guided by guesses optimizes the wrong things; performance work guided by real-user data and a profiler delivers wins you can prove.
TL;DR
- Measure first — real-user metrics (RUM) plus lab tools.
- Ship less JavaScript (code split, drop unused deps).
- Optimize images (modern formats, responsive sizes, lazy loading).
- Cache static assets aggressively via a CDN.
- Avoid long main-thread tasks and layout thrash.
Quick Example
Route-level code splitting — the single highest-leverage way to ship less JS up front:
Core Concepts
Core Web Vitals
Also watch TTFB (server/network baseline) and JS bundle size (parse/execute cost).
Measure → change → verify
- Measure with RUM (what users experience) and lab tools (Lighthouse, DevTools).
- Pick the top 1–2 bottlenecks.
- Ship one change.
- Verify the improvement and watch for regressions.
Biggest Wins
Ship less JavaScript
Code-split by route, remove unused dependencies, and avoid heavy work on initial load. JS is expensive to download and to parse/execute.
Optimize images
Cache aggressively
Serve static assets from a CDN with long-lived, content-hashed filenames. See Caching.
Rendering & Third-Party Scripts
Third-party scripts are often the silent performance killer — audit them regularly and lazy-load non-critical ones after interaction to protect INP.
Common Mistakes
Optimizing without measuring
Trusting lab scores over field data
FAQ
What are Core Web Vitals?
Google's user-centric performance metrics: LCP (loading), CLS (visual stability), and INP (interaction responsiveness). They factor into search ranking and are the standard targets for "is this page fast?"
What is INP and how is it different from FID?
INP (Interaction to Next Paint) measures how quickly the page responds across all interactions during a visit, replacing the older First Input Delay, which only measured the first one. Poor INP usually means long main-thread JavaScript tasks.
How do I measure performance?
Combine real-user monitoring (RUM, what actual users experience) with lab tools (Lighthouse for quick iteration, the DevTools Performance panel for diagnosing long tasks). Lab data is reproducible; field data is the truth.
What's the single biggest performance win?
Usually shipping less JavaScript — code splitting and removing unused dependencies. JS dominates both download and CPU cost, especially on mid-range mobile devices.
Related Topics
- Caching — CDN and HTTP caching
- Responsive Design — Responsive images
- Vite — Build output and code splitting
- CSS Fundamentals — Cheap vs expensive style changes
- SEO for SPAs — Why Core Web Vitals matter for SEO