Static vs dynamic websites: what your project actually needs
Decide which parts of your website can be ready-made files and which need a running service, without buying more hosting than the project requires.
In this guide
A static site is often enough for pages people read. A dynamic service is needed when someone must process a request, save information, or decide what a particular visitor may see. You can combine the two: a static service page can send enquiries to a separate form service.
The useful decision is therefore not “Which kind of website is better?” It is “Which parts of my project need to do work when a visitor uses them?” Start with that question before changing your host or buying a server.
The difference, without the jargon
A static page is prepared before a visitor asks for it. The host sends ready-made HTML, CSS and other files. HTML holds the content and structure; CSS controls its appearance. You can write those files yourself or use a tool that generates them from an editor or Markdown.
A dynamic page or endpoint runs server-side code in response to a request. An endpoint is an address that a program or form sends data to. That code might check a login, read an order, save an enquiry, or return a calculated result.
“Static” does not mean motionless. A static page can have menus, a calculator that runs entirely in the browser, or an embedded booking tool. The booking tool still depends on a service elsewhere; moving its button onto a static page does not make its storage and processing disappear.
| Your requirement | What it needs | A sensible starting point |
|---|---|---|
| Service details, opening hours, portfolio, documentation | Public pages and files | Static output or an existing site builder |
| A calculator that uses only what the visitor types and saves nothing | Browser code | A static site may be enough |
| A contact form whose submissions reach your inbox | A working form receiver | Static page plus a form service, or a backend already included in your site |
| Customer login and private account data | Server-side identity and access checks | A service designed to handle accounts |
| Taking payment and recording orders | Secure checkout and order processing | Hosted commerce/checkout or a suitable existing store |
These are requirements, not a ranking of products. A paid dynamic host can be unnecessary for the first two rows. A free static host does not supply all the services in the last three.
Follow one example through the decision
Suppose you offer bicycle repairs and need a page with your services, location and an enquiry button. This is an illustrative project.
At first, visitors only need to read and contact you. Ready-made pages can show the service information. If the enquiry button opens an existing booking service, that service handles availability and appointments. Include its cost and limits when comparing your options; do not count only the website’s hosting bill.
Later, you want visitors to upload a photograph. The page can remain static, but something must receive and store the upload, limit its size, and control who can access it. First check whether the existing form or booking product supports that. A new VPS is one possible implementation, not an automatic requirement.
If customers need to log in and see their own repair history, the service must check their identity and permissions. Hiding a page link or using JavaScript to conceal text is not protection for private data. Choose a managed product or an application backend that actually provides those controls.
The decision changes because the required result changes—not because the site reaches an arbitrary number of pages.
How will you update the content?
A static site can have hundreds of regularly updated pages. A build is the step that turns source content into the files visitors receive. With a static generator, changing a source file normally requires another build and publication before visitors see it.
A content-management system may build static files, render pages on demand, or do both. Seeing an editor is not enough to identify the hosting model. Likewise, a framework such as Astro can prepare pages ahead of time or render selected routes on demand; inspect your project’s actual configuration.
Ask the person or tool producing the site: “Will you give me a folder of finished files, or will anything need to run server-side when visitors use the site?” If a server program is required, also ask which runtime it needs—for example Node.js or PHP—and which data must survive updates. Those answers are more useful than guessing from a URL or filename.
Compare the complete setup
Keep these four items in the comparison:
- Hosting fit. Does the service accept finished files, run the application you need, or offer the specific functions it uses? GitHub Pages publishes static files; it does not run a general-purpose PHP or Python web backend. Cloudflare Pages Functions provide request-time code, with a different runtime from a general VPS.
- Editing and publication. Can the person maintaining the site make a change, check it, publish it and recover the previous version?
- Data and access. Where are enquiries, uploads or orders stored? Who can retrieve them, and how will you recover them?
- Total cost and work. Include any separately required form, booking, commerce or database service, plus the time needed for updates and maintenance. Count what your existing plan already covers before adding another subscription.
Neither label guarantees speed, security or a search ranking. Images, browser scripts, server behavior and the way a page is built all matter. Compare the actual page and required features, not a promised advantage of the label alone.
Your next step
Write your visitor’s main action in one sentence: “Read our services and send a repair enquiry,” for example. Then list where each part happens: in ready-made files, in the browser, or in a named service that receives and stores data.
If everything required is already supported, keep the current setup. If one piece is missing, investigate that piece first. You have a useful hosting decision when you can name what will run, where the data will live, and who will maintain it.
Once the page is built, use the landing page launch checklist to check the visitor’s action and the result on your side.
Sources and useful links
- MDN: an introduction to server-side websites — how static files and request-time processing differ.
- GitHub Pages explained — what its static publishing service does.
- Astro’s on-demand rendering guide — why the same framework can support different rendering models.
- Cloudflare Pages Functions — an example of adding server-side work to a static-site platform.