The CDN & Caching

Surge runs its own CDN, purpose-built for static projects. When you publish, your files propagate to edge nodes around the world, and visitors are served from close by—when your domain is delegated to Surge's name servers, even DNS resolution is geo-aware.

You can watch the network work: every publish streams CDN propagation progress, surge audit reports what each node is serving, and surge load charts where your traffic lands.

Lucid Caching

Every asset is served with the same carefully-chosen caching strategy, applied automatically:

Cache-Control: public, max-age=31536000, no-cache
ETag: "0f31201287e0e3f7e87c86ed26f2a492"

Read together, these headers tell the browser: keep this file for up to a year, but check with the server before using it. The check is an ETag validation—a tiny conditional request that returns 304 Not Modified when the file hasn't changed, or the fresh file when it has. The result:

• The browser never downloads the same bytes twice—not even HTML.
• A visitor never sees a stale file after you deploy.
• You never rename files to bust caches or fingerprint asset paths.

It's the most aggressive caching that never serves stale content—which is why there's no cache configuration on Surge at all.

Gzip

All compressible content types—HTML, CSS, JavaScript, JSON, SVG, text—are gzipped automatically at the edge. Binary formats that are already compressed (images, video, fonts) are passed through untouched. Nothing to configure, no build step.

Deploys and the cache

A deploy is atomic: the CDN cuts from the old revision to the new one all at once, and the ETag mechanism ensures browsers pick up changed files on their next request. If you ever need to force the network's hand, surge bust purges the project from every edge node's cache—but routine deploys don't need it.