The 80/20 of Web Performance for a Content Site

Most of a content site's speed comes from a short list of boring changes. Here is the 80/20 — the few things that move the needle — and why chasing anything else is usually a waste.

1. Gzip / Brotli

Compress text. One line in nginx, or on by default at most CDNs:

gzip on;
gzip_types text/css application/javascript text/html application/json image/svg+xml;

CSS and JS often shrink 70-80%. This is the biggest free win on the page.

2. Browser caching

Static assets that do not change should not be re-downloaded:

location ~* \.(css|js|png|jpg|svg|ico)$ {
    expires 7d;
    add_header Cache-Control "public";
}

Returning visitors stop paying for CSS/JS/image bytes entirely.

3. Image size

The fastest image is the one never sent. Resize to the display size, use modern formats, and add width/height so layout does not jump. For a content site, oversized images are usually the single biggest weight on the page.

4. A fast origin

Server-side render time matters. A static page or a Go-rendered page answers in single-digit milliseconds; a bloated PHP page can take 300ms+ before any byte ships. If your pages render slowly, no amount of caching fully hides it.

5. A CDN in front

Cloudflare (free tier) caches assets and terminates the connection near the visitor. For a content site, this is nearly free performance.

What you can skip

Splitting your JavaScript into micro-bundles, chasing every Core Web Vital decimal, or adopting the newest framework "for performance" — those are for after the five boring wins are done.

Measure, apply the five, measure again. The calculator below shows what the hosting behind all this actually costs.