In short
Web performance is best managed as a budget — a fixed limit on page weight, request count, and load-time metrics — enforced across images, fonts, JavaScript, and caching decisions, rather than as a one-time optimization pass done after the fact.
Why performance needs a budget, not a pass
A one-time performance optimization pass fixes today's problems and does nothing to stop tomorrow's — the next feature adds a font, an image, a script, and the site slowly regresses back to where it started. A performance budget (a hard limit on page weight, request count, or load-time metrics, checked automatically) prevents this by making regressions visible before they ship, not months later when the site has quietly become slow again.
The metrics that actually matter
- Largest Contentful Paint (LCP): how long until the largest visible element renders — the metric users experience as "is this loading."
- Interaction to Next Paint (INP): how responsive the page feels to actual interaction, replacing the older First Input Delay metric.
- Cumulative Layout Shift (CLS): how much visible content jumps around during load — a major source of accidental clicks and user frustration.
These three make up Google's Core Web Vitals and are worth tracking both in the lab (synthetic testing) and in the field (real user data) — see how to measure real-user performance for the difference.
Images: usually the biggest lever
Images are typically the single largest contributor to page weight. Serving modern formats at the correct display size, compressed appropriately, and lazy-loaded below the fold is often the highest-return performance fix available on any given page — see how to optimize images for speed and search for the specifics.
Fonts: a smaller but sneaky cost
Web fonts can block rendering or cause a visible flash of unstyled or swapped text if not handled carefully. Self-host fonts where possible (avoiding a third-party request), subset them to only the characters actually used, and use font-display: swap so text renders immediately in a fallback font rather than staying invisible while the custom font loads.
JavaScript: the cost that compounds
Unlike images, JavaScript costs happen twice — once to download, and again to parse and execute on the user's device, which is much slower on mid-range phones than on a developer's laptop. Ship only what a page actually needs, code-split by route so unrelated pages don't load each other's code, and audit dependencies periodically — a single unused library can silently add hundreds of kilobytes.
Caching: making repeat visits nearly free
Correctly configured caching (long-lived cache headers on versioned static assets, a service worker for offline-capable apps) means a returning visitor re-downloads almost nothing. This is one of the highest-leverage, lowest-effort performance wins available, and one many sites configure incorrectly or not at all — see how to cache assets for instant repeat visits for setup specifics.
Rendering strategy matters
How a page is rendered — fully static, server-rendered per request, or client-side rendered after a blank initial load — has a bigger performance impact than almost any individual optimization. A static or server-rendered page can show meaningful content immediately; a purely client-rendered page often shows a blank screen until a large JavaScript bundle downloads, parses, and runs.
Setting a performance budget
Pick concrete limits — total page weight, number of requests, or a target LCP — and enforce them in CI, failing a build that exceeds the budget rather than relying on someone remembering to check manually later. This is the difference between performance as a one-time project and performance as a maintained property of the site.
The compounding return of speed
Performance improvements rarely show up as a single dramatic win — they compound. A faster site ranks marginally better, converts marginally better, and gets abandoned less during load, and each of these compounds with the others over time. Treating speed as a feature with ongoing investment, not a one-time fix, is what separates sites that stay fast from ones that slowly don't.
Common questions
What's the single highest-impact performance fix for most sites?
Image optimization — correct format, correct size, and appropriate compression — is usually the highest-return fix, since images are typically the largest contributor to total page weight.
Why does JavaScript cost more than its file size suggests?
Because it has to be downloaded, then parsed and executed on the user's actual device — a cost that's much higher on a mid-range phone than on the developer machine it was tested on.
How do I stop performance from regressing over time?
Set a concrete performance budget and enforce it automatically in your build or CI pipeline, so a regression fails the build instead of quietly shipping and compounding over successive releases.