Static vs dynamic website: the difference, and which one you need

A static website sends every visitor a page that was built in advance. A dynamic website builds the page when the visitor asks for it, usually by running code and reading a database. That one difference decides how fast the page arrives, what can go wrong on the server, how content gets edited and where the site can be hosted. This guide explains both with real numbers from our own site, which is mostly static and partly dynamic, and ends with a simple rule for deciding which pages of yours should be which.

The difference in two sentences

A static page exists as a finished HTML file before anyone asks for it, and every visitor gets the same file. A dynamic page is put together by the server at the moment someone asks, so it can differ from one visitor to the next: a dashboard that shows your orders, a search result, a shopping cart. "Static" is about how the page is made, not how it looks; a static page can have animation, video and forms.

What a static website is

A static website is a folder of finished files: HTML pages, stylesheets, scripts and images. Any web server can send them, and so can a content delivery network, which keeps copies on servers around the world and answers from the one nearest the visitor. The pages are written by hand or, more often, produced by a static site generator such as Astro, Hugo or Eleventy, which takes templates and content and builds every page in one go.

The catch is change. When a text, a price or a blog post changes, the affected pages have to be built again and uploaded. With a developer and a Git repository that is a commit and a few minutes of build time; with a headless CMS the editor presses publish and the CMS triggers the rebuild. Either way, content does not change between builds unless something rebuilds it.

What a dynamic website is

A dynamic website runs code for each request. WordPress is the best-known example: PHP reads the post from a MySQL database, fills a theme template and sends the result, every time a page is asked for. Online shops, booking systems, client portals and anything with a login work the same way, because the page depends on who is asking and on data that changes all the time.

Running code on every visit costs time, so most dynamic sites cache: they keep a finished copy of a page and send that until something changes. A well-cached WordPress site behaves much like a static one for anonymous visitors. The difference shows up for logged-in users, for pages that cannot be cached, and on the first visit after the cache expires.

Most sites are both: our own as an example

Static and dynamic are a decision per page, not per website. This site is a good example. The last production build of the English site generated 316 pages and files in advance: the homepage, services, prices, portfolio, contact pages, every guide, and files such as the sitemap. Some of them refresh themselves in the background, the price pages every minute and the guides every hour, so a changed price shows up without a rebuild. That pattern, static pages that regenerate on a schedule, is what Next.js calls incremental static regeneration.

Only 13 page routes are rendered on every visit: the client portal, the admin panel, offers and audits that open from a private link, and the thank-you page that shows what you just sent us. Behind them sit 40 API endpoints for logins, forms, file downloads and ratings. Every page a stranger is likely to land on is static; everything that needs to know who you are is dynamic.

Speed: what we measured on our own site

We timed five pages of levelui.com on 10 October 2026, 12 rounds in rotating order, measuring how long the server took to start answering once the connection was open. The static pages started answering in a median 188 milliseconds and the dynamic ones in 363 to 371, about twice as long. One static page came straight from the hosting provider’s CDN; the other two went through to our server, which only had to send a copy it had built in advance, and they were just as fast. The portal login page and the thank-you page are marked as never to be cached, so the server built them from scratch on every request.

The absolute numbers depend on where you measure from; the gap is the time it takes to build a page rather than send a finished one. Speed counts for visitors and, through Core Web Vitals, for search, which is why the pages people arrive on from Google should be the static ones. A dynamic page can be fast too, but it has to earn it with caching and a quick server, and a static page gets it for free.

Security and maintenance

A static site has no application code running when someone visits, so there is no login form to brute-force, no database to inject into and no plugin with a security hole on the public pages. What remains is the web server or CDN, which the hosting provider keeps patched. A dynamic site has all of those, and they need updates: WordPress core, the theme and every plugin, plus the PHP version underneath. That upkeep is a large part of what a maintenance retainer for a WordPress site pays for.

Editing content

Editing is where dynamic sites have been ahead: you log in, change the text and it is live. A static site without a CMS means editing files, which suits a team that works in Git and frustrates one that does not. A headless CMS closes most of that gap: editors get a familiar admin, and publishing triggers a rebuild or a refresh of just the changed page. We compare those setups in WordPress or a headless CMS.

Which one you need

If every visitor should see the same page, make it static; make dynamic only the pages that must know who is looking. A company site, a portfolio, a landing page, documentation and a blog are static by nature. A shop’s product pages can be static with the cart and checkout dynamic. A portal, a booking system or anything behind a login is dynamic. If you are unsure, start static: adding one dynamic page later is easy, while making a slow dynamic site fast usually means rebuilding it.

For a mostly static site, Astro is our choice when the site is mainly content, and Next.js when static pages and dynamic ones live side by side, as they do here. Static files can be hosted almost anywhere, often for free, and our Hosting Setup package covers putting one on a CDN with automatic builds and a staging copy. If you want the whole site built that way, that is our web development work.

Sources and method

The page counts come from the production build log of levelui.com of 9 October 2026. Response times are our own measurement from 10 October 2026: time from the request to the first byte of the answer, after the connection and TLS handshake, 12 rounds per page in rotating order after a warm-up round, from one location.

• MDN — Introduction to the server side ↗

  A static site returns the same hard-coded content for a resource; a dynamic site can return different data for the same URL.

• web.dev — Rendering on the Web ↗

  Static rendering, server rendering and the hybrid approaches in between.

• Next.js — Incremental Static Regeneration ↗

  Static pages that regenerate in the background on a schedule or on demand.

• Astro — On-demand rendering ↗

  Astro builds static pages by default and renders individual pages on request when they need it.

• WordPress Advanced Administration Handbook — Cache ↗

  Page, object and opcode caching for WordPress, and why pages with a lot of dynamic content are harder to cache.