Static site generation

Why it matters

It removes an entire category of both slowness and attack surface: there is no database query or server-side rendering step slowing down a request, and there is no admin panel or database exposed to the internet for an attacker to target, since none of that runs at request time. It also scales cheaply under traffic spikes: since every page is a pre-built file rather than a computed response, a sudden surge in visitors does not strain a database or an application server the way a dynamic site's would. It also pairs naturally with a content delivery network, since identical static files can be cached at edge locations worldwide, serving a visitor in a different region from a nearby location rather than a single distant server.

What goes wrong when it's handled badly

Teams sometimes bolt a static site generator onto a workflow that actually needs frequent, non-technical content updates, which then requires a full rebuild and redeploy for every small text change, a genuine friction point for a high-frequency publishing need. That specific mismatch, not static generation itself, is usually the real complaint, and it is solved by adding a headless CMS in front of the static build rather than abandoning the approach. A concrete example is an ecommerce catalogue with thousands of products built entirely statically without a plan for incremental rebuilds, where updating a single product's stock count requires rebuilding and redeploying the entire site, a delay that is workable at ten products and untenable at ten thousand. Planning for incremental or on-demand rebuilds from the start, rather than a full rebuild for every change, is what keeps a static architecture practical as a catalogue or content volume genuinely grows.