You do not need a performance obsession. You need a short list of defaults that keep a site fast and a check that stops a bad commit from undoing them.
Guides · Performance
A Web Performance Baseline You Can Actually Hold
The handful of things that account for most real-world site speed — and how to keep them from regressing.
7 min · updated 29 Aug 2026Ship less JavaScript
JavaScript is the most expensive thing a page can carry, per byte, because the browser has to download, parse, and execute it. For a content site, most pages should need almost none.
- Prefer static HTML; add interactivity per-component, not per-page.
- Audit the bundle — one heavy dependency (a date library, an animation kit, a full icon set) is usually the culprit.
- Load third-party scripts (analytics, chat) after interaction or on idle, never render-blocking.
Get images under control
- Serve modern formats (AVIF/WebP) with a fallback.
- Size images to their display size; do not ship a 3000px hero to a 700px column.
- Set width and height (or aspect-ratio) so the layout does not shift as they load.
- Lazy-load anything below the fold; eagerly load the one hero image.
Fonts
- Self-host the font files and preload the one used above the fold.
- Use font-display: swap so text is visible during load.
- Subset to the characters you actually use if the font is large.
Keep it from regressing
Add a Lighthouse CI or bundle-size check to the pipeline with a budget. A PR that pushes JavaScript over the threshold fails, and the regression gets discussed before it merges instead of discovered in production a month later.
Rather not do this yourself?
Hosting, launch, performance, and cloud hardening are all services here. Hand it over.