What is the difference between cleaning, minifying, and compressing?

Cleaning removes code and markup that testing shows are genuinely unused. A syntax-aware minifier then strips or rewrites the safe parts of what remains (keeping required license comments). Gzip or Brotli shrinks the transferred copy further. They complement each other — but test the production build, because some whitespace, names and dynamically referenced code are significant.

Do I need a CDN for a small local site?

Often not — if measured latency, capacity and reliability already meet the site's needs, a nearby origin with good caching and compression serves a local audience well. A CDN is more likely to help with geographically distributed visitors, high origin load, or a real resilience or security need. Measure first, and weigh the added DNS, caching, privacy and operational complexity.

How do I stop visitors getting stale cached files?

Give public static assets content-versioned filenames like style.abc123.css and long cache lifetimes. When content changes, publish a new filename and update the HTML that references it — and keep the HTML itself briefly cached or revalidated, so visitors actually receive the new reference. That's cache busting.

Are your assets delivered efficiently?

Transfer size is one important part of performance: reducing unnecessary bytes helps, most visibly on slow connections — while latency, server response time, request chains and main-thread work can matter just as much. Delivering assets efficiently — smaller files, compressed in transit, cached close to the visitor — remains one of the cheapest wins available, as long as you know what it can and can't buy.

Clean first, then minify

Minification uses syntax-aware tools to strip or rewrite the safe parts of a file — unnecessary whitespace, most comments, and in JavaScript some local names — aiming to preserve behavior. It's a mechanical last step; minifying junk still ships junk, so clean up first:

Remove CSS rules, scripts and dead markup that testing shows are unused — coverage tools give the evidence, but check dynamic templates, plugin hooks and uncommon user paths before deleting, and test forms, keyboard use and responsive layouts after. "Looks unused" and "is unused" differ.
Drop tracking snippets for services you've genuinely dropped.
Where a library serves one small feature, compare its delivered cost against a few lines of native code — but keep the library when it carries accessibility, compatibility or security weight you'd be rewriting badly.

Then minify with a tool so it stays repeatable and reversible: keep a readable source and generate a minified build (esbuild, Terser, or Lightning CSS; most bundlers do it automatically), preserving required license comments. Never hand-minify. And weigh effort against payoff — on a tiny site, shaving a few KB of CSS may not justify a build pipeline.

Compress and use modern HTTP

Enable Gzip or Brotli for compressible text responses — this Apache mod_deflate example enables Gzip; Brotli needs its own module and configuration:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript text/javascript image/svg+xml
</IfModule>

Let the delivery layer negotiate the encoding, verify Content-Encoding on the public response, and don't recompress already-compressed formats (JPEG, PNG, WebP, archives). Serve over HTTP/2 or HTTP/3 where available — their multiplexing removes HTTP/1.1's per-connection request queuing, though bandwidth, prioritization and server work still apply — and verify the protocol at the public URL, since a proxy may talk a different one to your origin. Set caching headers so repeat visitors reuse unchanged assets, and add defer to suitable external scripts so they don't block HTML parsing — keeping their execution light too, because defer postpones work, it doesn't shrink it.

Move bytes closer with a CDN

Compression handles size; a Content Delivery Network handles distance. A CDN caches eligible files at distributed edge locations and routes each visitor to a suitable one — often a real latency win for distant audiences, with cache hits offloaded from your origin. The actual gain depends on routing, cache-hit rate and your origin's own speed.

It's worth considering when visitors are geographically spread, origin load is real, or you need its resilience features — and the full decision, including privacy, origin TLS and the DNS move, has its own guide: a proxy CDN sees your visitors' requests (a data-processing decision), needs the origin hop encrypted and verified too, and a DNS change must carry every existing record along, mail records included. Verify what it actually caches — proxying isn't caching — and start with versioned static assets; cache HTML only where it's public and identical for everyone. For the versioned assets, cache aggressively:

Cache-Control: public, max-age=31536000, immutable

Only for public assets whose filenames change with their content. Never apply this globally — on HTML, carts, account or admin responses, public can let a shared cache serve one visitor's page to another, and immutable on an unversioned file makes corrections near-undeliverable. HTML stays briefly cached or revalidated, so new asset references reach visitors.

Ship less, ship it compressed, and serve it close to the visitor — that's efficient delivery.

What to do

Remove unused CSS, JS and dead markup on coverage evidence, test the result, then add a minification step to the build.
Turn on Gzip or Brotli for text responses and verify the public Content-Encoding.
Serve HTTP/2/3 (verified at the public URL) and give versioned static assets long cache lifetimes — only them.
Defer suitable external scripts and keep their execution cheap; combine tiny files where sensible.
Consider a CDN for distributed audiences or real origin load — measured, and with its privacy and TLS homework done; skip it where a nearby origin already delivers.
Re-test load time before and after so you can see the win.