Fast by Default

Speed here isn’t tuned per project; it’s a property of the architecture. The public site is plain static files served from disk with no per-request rendering, aggressive caching, and small payloads by construction. This page summarizes where the speed comes from and which knobs you control.

No per-request rendering

Your visitors are served published static files straight from disk. The authoring application never renders public pages on demand; in production it’s bound to a private loopback address, so visitors simply can’t reach it.

Caching that ships with the stock configuration

The example server config sets cache lifetimes so your deployment is fast by default:

HTML pages: a short 5-minute cache with must-revalidate, so newly built content reaches readers within minutes of a build.
Fonts: content-hashed files, cached for one year and marked immutable.
Other static assets (CSS, JS, images, icons): cached for one day.
The service worker: explicitly not cached, so a stale copy can never block updates.
Admin dashboard assets: cached for one day.

Compression (zstd and gzip) is enabled server-side in the stock configuration.

Small pages, generated wisely

The build stage does work at publish time that other systems pay for at runtime:

HTML is minified by default. Whitespace collapses in every built page (there’s a settings toggle if you need unminified output for debugging).
Images lazy-load automatically. Every image that lacks a loading hint gets loading="lazy" during the build.
Images ship with responsive derivatives. When you upload an image, scaled copies at 320, 640, and 1280 px are generated in both the original format (JPEG or PNG) and WebP, and templates receive ready-made srcset attributes so visitors only download the size they need.

Speed at authoring time too

Incremental builds by default: unchanged files are skipped by content hashing, so day-to-day rebuilds are quick; a full rebuild remains available for those days you want one.
The database never blocks the admin. SQLite runs in WAL mode (concurrent reads don’t block writes), tuned with a sizeable cache for the expected workload of one active admin session plus periodic builds.
Builds stay bounded, and stale output beats broken output: a build is capped in write volume and time (five minutes), and a build that collapses (page-count drop, link spike, timeout) is not promoted; the prior good site keeps serving.

What doesn’t slow you down

There’s no runtime JavaScript on public output; nothing to fetch, nothing to execute, nothing to defer, and no beacon to load. Content pages are just markup with optimizations baked in at build time.