Static site

Made in advance instead of assembled on request

There are two ways a page can reach a visitor. The server can build it on the spot, pulling the text out of a database, running the theme and whatever plugins are installed, and stitching the result together while the person waits. Or the page can already exist as a finished file, and the server simply hands it over.

The second one is a static site. Publishing a change does not mean the page gets rebuilt for every visitor from then on. It means the page gets rebuilt once, at publish time, and the new version replaces the old one on the shelf. Change your hours, republish, done.

Static does not mean frozen and it does not mean plain. A static site can carry photos, video, maps, forms, and animation. The word describes when the page gets assembled, not how it looks or how often you are allowed to change it.

The name is an accident of engineering vocabulary rather than a description of the experience. A visitor cannot tell which kind of site they are on, and the label by itself is not something you are rewarded or punished for. It is a decision about how the site is put together and kept up, made once, by whoever builds it, and felt later in load time and in the list of things that can break.

Fewer moving parts, and where that stops being enough

The practical argument is that there is less to go wrong. No database to corrupt, no plugin stack to patch on a schedule, no version of anything drifting quietly out of date behind the scenes. Pages tend to open fast because there is no work to do before sending them, and there is very little surface for anyone to attack. Upkeep on a lean site is a short list: the hosting bill, the domain renewal, edits when something about the business changes, and a check now and then that the forms are still arriving.

The honest tradeoff is that some jobs genuinely need a server thinking in real time: customer logins, live inventory, bookings against a real calendar, a checkout moving money. Plenty of sites end up a mix, with the pages that only need to load and read well kept static, and the parts that behave like an application built properly underneath. Which parts go which way is a build conversation, and our custom web design page walks through how a build gets scoped before anything is designed.

Worth saying plainly: static is not automatically better. It is well suited to the common case, which is a local service business whose site needs to explain the work, show that it was done well, and make it easy to pick up the phone.

Where static sits among the neighboring terms

A CMS is the interface you edit content in, and it can sit on top of a static site as easily as a database-driven one, so editing yourself and publishing static files are not in conflict. WordPress is the best known of the database-driven approach and brings the plugin upkeep that comes with it. Web hosting is where the finished files sit either way. And PageSpeed is usually where the difference shows up first, because a page with nothing left to assemble comes out of the gate with a head start.