A static page is an HTML, CSS, JavaScript, image, or font file that lives on disk and is served verbatim to every visitor who requests it — no template render, no database query, no per-request computation. The file is identical for every visitor, the file is cacheable at every layer (browser, CDN, edge), and the file is the right answer for a landing page, a marketing site, a blog, a docs site, a docs README, or a product page that does not change per user. The interesting part is the three things a static page actually is, the three things a static page is not, the three things the top ranking pages skip (the API boundary, the “mildly dynamic” pattern, the cost-of-compute angle), and the way a modern stack mixes static and dynamic in the same project.
The reason “static pages” is its own question and not just “static website” or “static hosting” is that the page is the unit, the page is the thing the developer thinks about, and the page is the thing the developer has to decide whether to make static or dynamic. The decision is the lever that turns a slow, expensive site into a fast, cheap one.
Table of contents
- The short version
- The three things a static page actually is
- The three things a static page is not
- The three things the top ranking pages skip
- The way static pages and dynamic pages meet at the API boundary
- The five patterns a real team uses in 2026
- The way to think about the cost
- FAQ
The short version
A static page is a file on disk that the server hands back without modification. The file is identical for every visitor, the file is cacheable at every layer, and the file is the right answer for content that does not change per user. The opposite is a dynamic page, which is generated on each request by running code (a template, a query, a runtime) and which can return different content for different users. The line between the two is not as sharp as it used to be — modern stacks mix static and dynamic in the same project, and modern “static” sites use client-side JavaScript to call an API for the dynamic parts.
The three things a static page actually is
A short, opinionated list of the three things a static page actually is. The three are the properties the developer can rely on, and the three are the properties that make a static page fast, cheap, and easy to scale.
A file on disk. A static page is a file: index.html, about.html, pricing.html, app.js, styles.css, logo.svg. The file is uploaded once, the file is served N times, and the file does not change between requests. The pattern is the right answer for any content that does not need per-user rendering, and the pattern is the reason a static page is so fast — the server is just reading a file from disk (or from a cache) and sending it back.
Identical for every visitor. A static page is the same HTML for the user in San Francisco and the user in Singapore. There is no {% if user.logged_in %} template tag, there is no WHERE user_id = ? database query, there is no per-request computation. The pattern is the right answer for any content that is the same for everyone (a marketing page, a docs page, a blog post), and the pattern is the reason a static page is so cacheable — the CDN can serve the same cached copy to every visitor.
Cacheable at every layer. A static page is cacheable in the browser (the browser caches the HTML, CSS, JS, images, and fonts), cacheable at the CDN (Cloudflare, Fastly, CloudFront, BunnyCDN cache the file at the edge), and cacheable at the origin (the server has the file in memory after the first read). The pattern is the right answer for any content with a high read-to-write ratio, and the pattern is the reason a static page scales to millions of visitors without breaking a sweat.
The three are the floor. A static page is also “buildable in advance” (a build step generates the HTML once, the server just serves the result), “edge-deployable” (the file can be deployed to hundreds of edge nodes around the world), and “version-control-friendly” (the file is just text, the file lives in Git, the file is reviewable in a pull request). The three are the ones the developer should know first, and the three are the ones the developer can rely on.
The three things a static page is not
A short, opinionated list of the three things a static page is not. The three are the misconceptions that show up in beginner Stack Overflow questions, in client meetings, and in RFPs.
A static page is not “a page with no JavaScript.” A static page can have a lot of JavaScript — a single-page application (React, Vue, Svelte) is a static page (the index.html is served statically) that loads a lot of client-side JavaScript that calls an API. The JavaScript runs in the browser, not on the server, and the JavaScript is what makes the page interactive. The misconception is that “static” means “no JS,” and the misconception is the one that comes up in every “is React static or dynamic” question.
A static page is not “a page that does not change.” A static page can change — the build step re-generates the HTML, the server picks up the new file, the CDN invalidates the cache, the next visitor gets the new content. The pattern is the right answer for any content that does not change per request (a blog post, a docs page, a product description), and the pattern is the wrong answer for any content that does change per request (a stock price, a live sports score, a personalized dashboard).
A static page is not “always faster than a dynamic page.” A static page is usually faster than a dynamic page, but a static page is not always faster. A static page that loads 3 MB of JavaScript and 50 API calls is a page that is slower than a dynamic page that renders 50 KB of HTML on the server. The performance is about the total work the browser does, and the work is the lever that turns a static page into a fast page or a slow one.
The three are the floor. A static page is also not “always the right answer” (a SaaS dashboard with per-user data is the wrong answer for a pure static page) and not “free” (CDN bandwidth, build minutes, and storage still cost money, and the cost is the lever that turns a cheap static site into an expensive one). The three are the ones the developer should know first.
The three things the top ranking pages skip
A short, opinionated list of the three things the top ranking pages for “static pages” skip. The three are the angles that turn a generic “what is a static page” article into a useful one, and the three are the ones this post is going to cover.
The API boundary. A modern “static” site is not actually static — the HTML is static, the JavaScript calls an API for the dynamic parts, and the API is a separate service that returns JSON. The pattern is the right answer for a static site that needs a user dashboard, a form submission, a search, or any per-user interaction, and the pattern is the lever that turns a static site into a real product without giving up the static page’s performance.
The “mildly dynamic” pattern. A static site that needs to be slightly dynamic (a search box, a personalized greeting, a recent-posts list) does not have to give up on static. The pattern is to ship the page as static, then add a small client-side JavaScript snippet that calls an API for the dynamic part. The pattern is the right answer for a static site that needs 1-2 dynamic features, and the pattern is the lever that turns a static site into a “mildly dynamic” one without re-architecting the whole thing.
The cost-of-compute angle. A static site is cheaper than a dynamic site because the server is not running a database query, a template engine, or a runtime for every request. The cost difference is not just “a few cents per month” — the cost difference is often an order of magnitude (a static site on a CDN is 10-100x cheaper than a dynamic site on a server with a database). The pattern is the right answer for a developer who is trying to keep the project’s burn rate low, and the pattern is the lever that turns a static site into a budget-friendly one.
The three are the angles that turn a generic “static pages” article into one the developer is going to read, share, and act on. The top ranking pages for “static pages” are usually generic explainers that cover the “what is a static page” angle and stop. The three are the angles that make this post different.
The way static pages and dynamic pages meet at the API boundary
The static page is the HTML, the dynamic page is the API. The pattern is the right answer for any modern web app that needs both performance (static) and personalization (dynamic), and the pattern is the pattern that the top hosting platforms have standardized on. The interesting part is the way the boundary is drawn, and the way the developer thinks about the split.
The static layer. The static layer is the HTML, the CSS, the JavaScript, the images, the fonts. The layer is served by a CDN (Cloudflare, Fastly, CloudFront) or a static site host (GitHub Pages, Netlify, Vercel, Cloudflare Pages, Render Static Sites). The layer is the one the user sees first, the layer is the one the user’s browser caches, and the layer is the one the user is going to interact with.
The dynamic layer. The dynamic layer is the API, the database, the workers, the auth. The layer is served by a long-lived service (FastAPI, Express, Django, Rails, Spring), the layer is backed by a database (Postgres, MySQL, Mongo, Redis), and the layer is the one the JavaScript on the static page calls when it needs per-user data.
The boundary. The boundary is the API endpoint, the boundary is the JSON contract, the boundary is the auth header, and the boundary is the rate limit. The boundary is the part the developer has to think about, the boundary is the part the developer has to version, and the boundary is the part the developer has to test. The boundary is the right answer for a modern web app, and the boundary is the lever that turns a static site into a real product.
The three layers are the floor. There is also the build step (the static files are generated at build time, the API is hit at runtime), the preview environment (a pull request gets a static preview and an API preview), and the deploy (the static layer is pushed to the CDN, the dynamic layer is pushed to the service platform). The three are the ones the developer should know first, and the three are the ones the developer can rely on.
The five patterns a real team uses in 2026
A short, opinionated list of the five patterns a real team uses for static pages in 2026. The five are the ones a developer will see most often, and the five are the ones a developer should know.
The pure-static pattern (Hugo, Jekyll, Astro, Eleventy, 11ty). A static site generator (SSG) builds the HTML at build time, the HTML is served by a static host, the pattern has zero runtime cost. The pattern is the right answer for a marketing site, a docs site, a blog, a portfolio, and the pattern is the lever that turns a “I just need a website” project into a “I just need a website” project that costs $0/month to host.
The static + API pattern (Astro, Next.js, SvelteKit, Nuxt). A static-first framework (Astro is the canonical example) generates most of the HTML at build time, the framework ships a small amount of JavaScript that calls an API for the dynamic parts. The pattern is the right answer for a site that needs 1-2 dynamic features (a contact form, a search, a user dashboard), and the pattern is the lever that turns a static site into a “mildly dynamic” one.
The single-page application (SPA) pattern (React, Vue, Svelte, Angular). A single index.html is served statically, the framework loads a lot of client-side JavaScript, the JavaScript calls an API for everything (the data, the auth, the routing). The pattern is the right answer for a SaaS dashboard, a rich web app, a project that is more “app” than “site,” and the pattern is the lever that turns a web app into a fast, responsive one (after the initial load).
The static + edge functions pattern (Cloudflare Pages, Vercel Edge Functions, Netlify Edge Functions, Fastly Compute). A static site is served by a CDN, the CDN runs a small function (a “serverless function at the edge”) for the dynamic parts. The pattern is the right answer for a static site that needs dynamic content with low latency (a personalized greeting, a geolocation-based redirect, a feature flag), and the pattern is the lever that turns a static site into a “low-latency dynamic” one.
The static + form pattern (Netlify Forms, Formspree, Basin, Getform, RunxBuild static forms). A static site is served by a CDN, the form submits to a third-party form service (or to a webhook). The pattern is the right answer for a static site that needs a contact form, a newsletter signup, a feedback widget, and the pattern is the lever that turns a static site into a “collects leads” one without adding a backend.
The five patterns are the floor. There is also the “static + comments” pattern (Disqus, Commento, Giscus), the “static + search” pattern (Algolia DocSearch, Meilisearch, Pagefind), and the “static + analytics” pattern (Plausible, Fathom, Umami). The five are the ones a developer should know first, and the five are the ones a developer will see most often.
The way to think about the cost
A static page is cheap, and the cheapness is the lever that makes the static page the right answer for the developer’s budget. The interesting part is the way the cost is structured, and the way the cost compares to a dynamic page.
The static page cost. The cost is CDN bandwidth (a few cents per GB), build minutes (a few cents per minute on a CI runner), and storage (a few cents per GB per month). A pure-static site with 100,000 page views per month on Cloudflare Pages, Vercel, or Netlify costs $0-$5/month. A pure-static site with 1,000,000 page views per month costs $5-$50/month. The cost is the right answer for a developer who wants to keep the project’s burn rate low, and the cost is the lever that makes a static site the right answer for a side project, a small business, or a startup.
The dynamic page cost. The cost is server compute (a few cents per hour for a small instance, a few dollars per hour for a large one), database storage and IOPS (a few cents per GB, a few cents per 1,000 queries), and bandwidth (a few cents per GB). A dynamic site with 100,000 page views per month on a single small instance with a small database costs $20-$100/month. A dynamic site with 1,000,000 page views per month costs $200-$1,000/month. The cost is the right answer for a SaaS dashboard or a web app, and the cost is the lever that makes a dynamic site the wrong answer for a marketing site or a blog.
The hybrid cost. A static + API site (the pattern that the modern stack is moving toward) costs the static page cost plus the dynamic page cost for the API. The hybrid site with 100,000 page views per month and 10,000 API calls per month costs $20-$50/month. The hybrid site with 1,000,000 page views per month and 100,000 API calls per month costs $200-$500/month. The hybrid cost is the right answer for a modern web app, and the hybrid cost is the lever that makes the static + API pattern the right answer for a developer who wants the best of both worlds.
The three costs are the floor. There is also the cost of build time (a large site with 10,000 pages might take 5-10 minutes to build, which costs $0.50-$2.00 per build on a CI runner), the cost of preview environments (a site with 50 pull requests per month gets 50 preview environments, which costs $5-$50/month on Vercel or Netlify), and the cost of monitoring (a few dollars per month for a basic uptime check). The three are the ones a developer should know first, and the three are the ones a developer can use to budget the project.
How this fits the rest of the stack
A static page rarely lives in isolation. The static page is usually part of a stack (an API, a database, a worker, a form) that runs on a platform. The platform that handles the static page should make the rest of the stack feel like part of the same conversation.
The services layer is the part of the platform that runs the long-lived API the static page calls. The database layer is the part that holds the data the API reads and writes. The static layer is the part that hosts the static page the user sees first. The environment variables are the part that holds the secrets the build step needs at build time.
A static site on a platform where the service, the database, the storage, and the secrets are all in the same place is a static site the team is going to be able to operate. A static site on a platform where each piece is in a different console is a static site the team is going to spend the first hour just opening the right tab.
For a team that wants to see the full cost of the project before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the static site, the worker, the bandwidth — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
FAQ
What is a static page?
A static page is a file on disk (HTML, CSS, JavaScript, image, font) that the server hands back to every visitor without running it through a database, a template engine, or a runtime. The file is identical for every visitor, the file is cacheable at every layer, and the file is the right answer for content that does not change per user.
What is the difference between a static page and a dynamic page?
A static page is identical for every visitor — the file is on disk and the server just hands it back. A dynamic page is generated on each request by running code (a template, a query, a runtime) — the page can return different content for different visitors. The line between the two is not as sharp as it used to be — modern “static” sites use client-side JavaScript to call an API for the dynamic parts.
Can a static page have JavaScript?
Yes. A single-page application (React, Vue, Svelte) is a static page (the index.html is served statically) that loads a lot of client-side JavaScript that calls an API. The JavaScript runs in the browser, not on the server, and the JavaScript is what makes the page interactive. The misconception is that “static” means “no JS,” and the misconception is the one that comes up in every “is React static or dynamic” question.
Is a static page faster than a dynamic page?
A static page is usually faster than a dynamic page, but a static page is not always faster. A static page that loads 3 MB of JavaScript and 50 API calls is a page that is slower than a dynamic page that renders 50 KB of HTML on the server. The performance is about the total work the browser does, and the work is the lever that turns a static page into a fast page or a slow one.
How much does it cost to host a static page?
A pure-static site with 100,000 page views per month on Cloudflare Pages, Vercel, or Netlify costs $0-$5/month. A pure-static site with 1,000,000 page views per month costs $5-$50/month. The cost is CDN bandwidth (a few cents per GB), build minutes (a few cents per minute on a CI runner), and storage (a few cents per GB per month).
What is the best static site generator?
It depends. Astro is the right answer for a static-first site with 1-2 dynamic features. Hugo is the right answer for a large, content-heavy site (10,000+ pages) that needs to build in seconds. Eleventy (11ty) is the right answer for a simple, no-JS static site. Jekyll is the right answer for a GitHub Pages site. Next.js, SvelteKit, and Nuxt are the right answer for a static + dynamic hybrid.
Can a static page submit a form?
Yes. The form submits to a third-party form service (Netlify Forms, Formspree, Basin, Getform), to a webhook (Zapier, Make, n8n), or to a custom API endpoint. The pattern is the right answer for a static site that needs a contact form, a newsletter signup, or a feedback widget, and the pattern is the lever that turns a static site into a “collects leads” one without adding a backend.