Do you need a static site generator?
A static site generator takes content and templates, then builds ordinary HTML files. There is no database query or server-side rendering step when somebody opens a page—the work already happened during the build.
That makes static site generators a good fit for blogs, documentation, portfolios, and other sites where most visitors receive the same content.
What gets generated
Tools such as Jekyll, Hugo, and Gatsby separate content from presentation. A project might contain Markdown posts, layout templates, configuration, CSS, and images. The generator combines them into a directory of HTML, CSS, and JavaScript that can be served almost anywhere.
The workflow is roughly:
- Write or edit the source files.
- Run the build.
- Deploy the generated files to a web server or CDN.
You still get shared layouts, reusable components, tags, archives, and other conveniences. You just create them at build time rather than for every request.
Why static sites are appealing
Serving prebuilt files is simple. There is less infrastructure to manage, pages can be cached easily, and traffic spikes are less dramatic when a CDN can serve the same HTML repeatedly.
Deployment is also straightforward. The output is a collection of files, so updates can be uploaded to a web server or published by a hosting service whenever the source repository changes.
There is a useful security benefit too: if the public site has no database or admin login, those cannot be attacked. That does not make the site invulnerable—third-party scripts and the build pipeline still matter—but it removes a few moving parts.
Where the model becomes awkward
Static generation is less convenient when every visitor needs different, constantly changing data. Accounts, private dashboards, real-time inventory, and complex search usually require an API, server-side code, client-side JavaScript, or some combination of them.
Build time can also grow as a site gets large. Changing one template may require rebuilding thousands of pages, depending on the generator and hosting setup.
External APIs are still possible, but you need to decide when their data is fetched. Build-time data can become stale; browser-side requests add JavaScript and expose the API to the client; serverless functions bring a server-like layer back into the project.
The practical choice
I would start with a static site generator when the site is mostly published content and updates happen through a build. It keeps hosting pleasantly boring, and boring infrastructure is often a good thing.
If the main feature depends on personalised or real-time data, a dynamic application is probably the more honest starting point. Static generation is useful, but it does not need to win every architecture argument.