Static vs dynamic website: differences and when to use each

Every website answers a browser request with HTML. The difference between static and dynamic is what happens on the server between the request and the response: either it just reads a file that already exists, or it runs code to build that page at that moment.

That difference drives almost everything that follows: what kind of hosting you need, how much you pay, how much work it takes to keep the site secure, and how content gets updated. And many projects today sit somewhere in between, combining the two.

What is a static website?#

MDN defines a static site as one that returns the same hard-coded content whenever a resource is requested. The server fetches the file from disk and responds with 200 OK. No back-end language runs and no database is queried.

The files can be written by hand or generated by a tool (Astro, Hugo, Eleventy, Vite, Next.js) in a build step. After the build, the result is a folder of HTML, CSS, JavaScript and images, and that folder is what goes to the server. The details are in what a static site is.

Static does not mean non-interactive. JavaScript running in the browser can open menus, filter lists and call APIs. "Static" describes the server, not the page.

What is a dynamic website?#

On a dynamic site, part of the response is generated on demand. According to the same MDN page, pages are usually created by inserting data from a database into HTML templates, and the site can return different content for the same URL depending on the user or stored preferences.

That requires code on the server (Node.js, Python, PHP, Ruby, Java and others), a process running to handle requests and, almost always, a database. In return, the site can do things a set of files cannot: login with sessions, personalized content, access control, shopping carts, search over data that changes all the time. Online stores, social networks, dashboards and WordPress are dynamic. How a site and a database fit together is covered in hosting a website with a database.

What are the differences side by side?#

A few rows need explaining:

• Speed. Reading a file is always cheaper than running code and querying a database. A well-built dynamic site can be fast, but it depends on caching and tuned queries; a static site is fast by default.
• Security. With no code on the server, there is no SQL injection, stolen session or outdated plugin to exploit. A dynamic site needs constant updates and a security checklist.
• SEO. Google processes JavaScript in three phases (crawling, rendering and indexing), and Google's own search documentation says server-side rendering or pre-rendering is still a great idea, because it makes the site faster and not every bot can run JavaScript. Both a static site and a dynamic one that builds HTML on the server meet that bar. What hurts is content that only appears after JavaScript runs in the browser.
• Cost. A static site runs none of your code and no database: a web server handing out files is enough, and that fits the simplest hosting. A dynamic site pays for RAM and CPU for the process and the database. The numbers are in how much it costs to host a website.

What does the same page look like in each model?#

In the static model, the page is an index.html file in the published folder. If it needs data that changes, the browser fetches that data from an API after loading:

<!doctype html>
<meta charset="utf-8">
<title>Status</title>
<h1>Service status</h1>
<p id="status">Loading...</p>
<script type="module">
  const res = await fetch("/api/status.json");
  const data = await res.json();
  document.querySelector("#status").textContent = data.message;
</script>

In the dynamic model, the server builds the HTML with the data before responding. A minimal example with Node.js's node:http module, with no dependencies:

import { createServer } from "node:http";

const escapeHtml = (s) =>
  s.replace(/[&<>"']/g, (c) => `&#${c.charCodeAt(0)};`);

const server = createServer((req, res) => {
  const url = new URL(req.url, "http://localhost");
  const name = url.searchParams.get("name") ?? "visitor";
  const now = new Date().toLocaleTimeString("en-US", { timeZone: "UTC" });

  res.writeHead(200, { "content-type": "text/html; charset=utf-8" });
  res.end(`<!doctype html><meta charset="utf-8">
<h1>Hello, ${escapeHtml(name)}</h1>
<p>Page generated at ${now} UTC</p>`);
});

server.listen(process.env.PORT ?? 3000);

Every visit to /?name=Ana produces different HTML, with the name and time of that request. Note the escapeHtml: any user-supplied data must be escaped before it goes into HTML, or the site is open to XSS. In the static model there is no server template to escape; in browser JavaScript, writing the data with textContent, as in the first example, avoids the same problem.

Is there a middle ground?#

Yes, and it is what most modern projects use. Three common combinations:

1. Static site + API. The front end is static, and a separate API handles login, forms and data. The site stays light and cheap, and only the API needs a server. See the API side in what a REST API is.
2. CMS + automatic build. Content lives in a CMS or in Markdown files. Each publish triggers a new build, and the published site stays static.
3. Hybrid framework. Next.js, Nuxt, Astro and similar tools decide page by page: what is the same for everyone becomes HTML at build time, and what depends on the request is rendered on the server. In that case the project needs a running server. The Next.js documentation shows that when you export static files only, features such as cookies, Server Actions and Incremental Static Regeneration stop working.

The difference between generating at build time and per request is covered in SSR vs SSG vs static sites.

When should you choose each one?#

The rule of thumb: start static and add server-side code only when something depends on each visitor or has to change without a new deploy. If the content is the same for everyone and changes a few times a day at most, a static site does the job with less cost and less risk. To put either one online, see how to host a website.

How to do this on Square Cloud#

Square Cloud hosts both models, and the middle ground, in the same account. For static, among several runtimes such as Node.js, Python and Go, there is one for static sites: nginx is always online serving the folder your build produced, none of your code runs on the server, and a new commit, upload or file manager edit goes live right away. For dynamic, use your language's runtime (Node.js, Python, PHP, Ruby, Java, Go and others), in an always-on container with no cold start or sleep mode. See the runtimes available today on Runtimes.

In the static + API setup, the front end and the API become two separate applications, each with its own *.squareweb.app subdomain with HTTPS. Each web application uses at least 512 MB of the plan's RAM, which is a pool shared between them. You deploy it yourself: ZIP upload in the dashboard, CLI, GitHub or the VS Code extension, and the squarecloud.app file is optional, because the dashboard generates it at deploy time.

Hobby, from R$12.49 per month, covers websites and includes cookieless web analytics with visits, routes and status codes. Custom domains and database hosting, which a dynamic site usually needs, start on Standard. Start with the static sites runtime or see the Sites page.