Why I Still Build Static Websites in 2026

Every few years, web development seems to find a new way to make websites more complicated. A relatively simple site that needs to show some text, images, a contact page and a blog can quickly turn into a project involving a JavaScript framework, package manager, build pipeline, database, API, server-side rendering and a long list of dependencies.

Sometimes that complexity is completely justified. If you are building an actual web application, you probably do need many of those things. But for a lot of websites, I think we reach for them much too quickly.

In 2026, I still build a lot of my websites as static sites, including this one. Not because I want to avoid modern technology, but because for blogs, portfolios, documentation, landing pages and many business websites, static generation still gives me a very good balance between speed, simplicity, reliability and control.

What I mean by a static website

When I say static website, I don’t mean manually creating an individual HTML file for every page.

I use Hugo, a static site generator written in Go. I write most of my content in Markdown, while Hugo handles templates, navigation, categories, metadata and the rest of the site structure.

An article can essentially be just a text file:

---
title: "Why I Still Build Static Websites in 2026"
date: 2026-08-29
tags:
  - web development
  - hugo
---

Every few years, web development seems to find a new
way to make websites more complicated...

Hugo combines that content with my templates during the build and produces normal HTML files.

A simplified template might look something like this:

<article>
  <h1>{{ .Title }}</h1>

  <time datetime="{{ .Date.Format "2006-01-02" }}">
    {{ .Date.Format "2 January 2006" }}
  </time>

  {{ .Content }}
</article>

After running:

hugo

I end up with a public directory containing the finished website.

public/
├── index.html
├── blogs/
│   └── why-i-still-build-static-websites-in-2026/
│       └── index.html
├── css/
├── images/
└── sitemap.xml

That distinction is important. Hugo itself isn’t involved when somebody visits my site. It has already done its job.

When a visitor opens an article, the server can simply send them the generated HTML file. There is no need to query a database and rebuild the page on every request.

For a surprisingly large part of the web, that’s enough.

Performance comes naturally

One of the biggest reasons I continue using static sites is performance.

If a page has already been generated, there isn’t much work left to do when somebody requests it. Static HTML, CSS and images are also ideal for caching and distribution through a CDN.

My own sites use Cloudflare, where static assets can be cached and served across Cloudflare’s network. Their current Static Assets documentation describes exactly this model: HTML, CSS, images and other files can be deployed and cached across the network.

The architecture can be remarkably simple:

Visitor
   ↓
Cloudflare
   ↓
Cached HTML file
   ↓
Browser

Compare that with a typical dynamically generated page:

Visitor
   ↓
Web server
   ↓
Application
   ↓
Database
   ↓
Template rendering
   ↓
Generated HTML
   ↓
Browser

That doesn’t automatically mean every static website is fast. You can still take a perfectly lightweight site and add a 5 MB hero image, several trackers, four font families and a large JavaScript bundle.

But static sites give you a very good starting point.

I prefer starting with almost nothing and adding what the site needs rather than starting with a complicated stack and spending time trying to make it lightweight afterwards.

The HTML is already there

Another thing I like about static generation is that the content doesn’t depend on JavaScript being executed before the page becomes useful.

If you inspect the HTML of an article, the content is already there:

<main>
  <article>
    <h1>Why I Still Build Static Websites in 2026</h1>

    <p>
      Every few years, web development seems to find
      a new way to make websites more complicated.
    </p>
  </article>
</main>

There doesn’t have to be an empty root element waiting for JavaScript:

<div id="app"></div>

followed by a large bundle that needs to create the page in the browser.

There are perfectly valid reasons to build websites that way, but if the page is primarily an article, I don’t see much benefit in making the browser reconstruct something that could have been HTML from the beginning.

There is simply less to maintain

Over time, I’ve started to appreciate this almost as much as the performance.

There is no production database behind my website, no PHP installation that has to remain compatible with a CMS and no collection of plugins that need constant updates.

Most of the site is just content, templates and files stored in Git.

My publishing process looks roughly like this:

Write Markdown
      ↓
Preview locally
      ↓
git commit
      ↓
git push
      ↓
Build
      ↓
Deploy

In practice, that might be:

hugo server

while I’m writing, followed by:

git add .
git commit -m "Add new article"
git push

That’s about it.

I currently like Git-based deployments because they also give me a complete history of the website. If I accidentally break something, I can see exactly what changed instead of trying to remember what I edited through an admin panel.

Cloudflare Pages still supports Git integration, where pushes to GitHub or GitLab can automatically trigger new deployments. It also supports preview deployments for branches, which is useful when a change is larger than fixing a typo.

Static sites have fewer moving parts

A conventional CMS can involve quite a few components:

Operating system
↓
Web server
↓
PHP / another runtime
↓
CMS
↓
Database
↓
Theme
↓
Plugins
↓
Website

My static site is closer to:

HTML
CSS
Images

Obviously the build process has more behind it, but that complexity happens before the visitor requests the page.

The public-facing result remains simple.

Fewer moving parts also means fewer things I need to think about when I return to a project six months later.

A smaller attack surface is a useful side effect

Security isn’t the main reason I choose a static site, but removing server-side components also removes things that could potentially become vulnerabilities.

A typical CMS might have an administration area, login system, database and third-party plugins. Each component needs to be maintained and updated.

If the public website mostly consists of:

index.html
style.css
photo.webp

there is simply less functionality available to attack.

That doesn’t make a static site magically secure. Someone could still compromise the Git repository, Cloudflare account or deployment credentials. Those things still need to be protected properly.

The difference is that I don’t also have a public CMS installation and database sitting behind every page.

For a portfolio or personal website, that trade-off makes a lot of sense to me.

I don’t want JavaScript to be the default

JavaScript is useful and I use it when something genuinely needs it. What I don’t like is treating JavaScript as the default foundation for every website.

Modern HTML and CSS can do much more than they could a few years ago.

For example, something as simple as an FAQ doesn’t necessarily need a JavaScript accordion library anymore:

<details>
  <summary>Do you build websites?</summary>

  <p>
    Yes. I build fast, lightweight websites with a
    focus on performance, accessibility and SEO.
  </p>
</details>

The browser already knows how to open and close it.

The same applies to dialogs:

<dialog id="contact-dialog">
  <h2>Contact me</h2>
  <p>Let's talk about your project.</p>

  <form method="dialog">
    <button>Close</button>
  </form>
</dialog>

Or responsive layouts:

.projects {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(18rem, 1fr));
  gap: 2rem;
}

Or automatically supporting the visitor’s light or dark theme:

:root {
  color-scheme: light dark;

  --background: light-dark(#fff, #111);
  --text: light-dark(#111, #eee);
}

I don’t have any problem with JavaScript itself. I simply prefer using the browser’s native capabilities before adding another dependency.

Static doesn’t mean basic

The word “static” can make these sites sound more limited than they really are.

My pages may be generated ahead of time, but the site can still have categories, tags, RSS feeds, sitemaps, image galleries, redirects, search and thousands of pages.

Hugo can generate something like:

/
├── blogs/
├── foto/
├── projekti/
├── pakalpojumi/
├── tags/
├── sitemap.xml
└── index.xml

from content and templates automatically.

You can also add dynamic functionality without turning the entire website into an application.

For example, imagine a mostly static website with one API endpoint:

/
├── index.html
├── about/index.html
├── blogs/index.html
└── api/
    └── contact

The pages can remain static while /api/contact is handled separately.

Cloudflare now supports exactly this sort of architecture with Workers and Static Assets. A project can contain its static site alongside Worker code, and you can decide which requests should run through the Worker.

Conceptually:

/blogs/article/
      ↓
Static HTML

/api/contact
      ↓
Worker
      ↓
Server-side logic

I like this model because complexity stays where it belongs.

If 95% of a website is static content and 5% requires backend logic, I don’t need to turn the other 95% into a dynamic application.

My content is just files

This is probably one of the least exciting features of static site generators, but it is one of my favourites.

Most of my content is stored in files like:

content/
├── blogs/
│   ├── static-websites.md
│   ├── css-subgrid.md
│   └── hugo-cloudflare.md
├── foto/
└── projekti/

If I want to find something:

grep -R "Cloudflare" content/

If I want a backup, I can copy the directory.

If I want version history, Git already provides it.

If I decide that I don’t want to use Hugo anymore, the actual content doesn’t disappear with Hugo. I still have a directory containing Markdown files and images.

For example:

# My Article

This is still perfectly readable without Hugo.

It is just **Markdown**.

There is something reassuring about that.

Websites change. Hosting companies change. Frameworks appear and disappear. Plain text has a pretty good track record.

Deployments are boring, which is good

I don’t want publishing an article to be an event.

Most of the time I want to write something, check it and put it online.

My usual workflow can be as small as:

hugo

git add .
git commit -m "Publish article"
git push

The hosting platform takes care of the rest.

There is no FTP connection, no database migration and no production admin interface that I need to open just to correct a spelling mistake.

More importantly, the process is repeatable. The same source files should produce the same website.

Boring deployments are underrated.

Static sites are cheap to run

This is particularly useful for personal projects.

If all I’m doing is serving HTML, CSS and images, the infrastructure requirements are tiny. Many static hosting platforms can comfortably host small and medium sites on their free tiers.

That means I can build something, put it online and see whether anybody actually finds it useful before worrying about infrastructure costs.

I like making small websites and tools, and I don’t always know whether a project will eventually get ten visitors or ten thousand. Static hosting makes that uncertainty much easier to deal with because the baseline cost and maintenance are so low.

If the project later needs a database or backend, I can add one.

I don’t need to start there.

SEO doesn’t require a JavaScript framework

A static site generator can output all of the things I want search engines and social platforms to find directly in the HTML.

For example:

<title>
  Why I Still Build Static Websites in 2026
</title>

<meta
  name="description"
  content="Why I still prefer Hugo and static websites
  for many web projects in 2026."
>

<link
  rel="canonical"
  href="https://example.com/blogs/static-websites/"
>

Open Graph metadata is just HTML too:

<meta property="og:type" content="article">
<meta property="og:title" content="Why I Still Build Static Websites in 2026">
<meta property="og:image" content="/images/static-websites.webp">

And Hugo can generate XML sitemaps and RSS feeds automatically as part of the build.

There isn’t anything particularly clever happening here.

That’s one of the reasons I like it.

For content websites, good SEO still largely comes down to understandable HTML, useful content, sensible internal linking, accessibility and performance. You don’t need a large client-side application to achieve those things.

Static sites make me question what I actually need

This is probably the biggest influence static sites have had on the way I build websites.

Starting with almost nothing makes every new addition noticeable.

If I want to add something, I tend to ask myself whether it actually improves the site.

Do I need this?

<script src="some-library.js"></script>

Can I do it with this instead?

<details>
  <summary>More information</summary>
  <p>Here is the additional information.</p>
</details>

Do I really need a web font that adds several additional requests, or would:

font-family:
  system-ui,
  -apple-system,
  BlinkMacSystemFont,
  "Segoe UI",
  sans-serif;

work perfectly well?

Do I need several analytics and advertising scripts on a personal website?

Do I need a CMS if I’m the only person editing the site?

Not every answer is “no”, but I think asking the question produces better websites.

Every dependency has some cost. It may be performance, maintenance, privacy, complexity or simply the amount of code that somebody has to understand later.

When I wouldn’t build a static site

Static sites aren’t the answer to everything.

If I were building online banking, a social network, a real-time collaboration tool or a complicated SaaS dashboard, trying to generate everything ahead of time would obviously make little sense.

Those projects might have a request that looks more like:

User
  ↓
Authentication
  ↓
Permissions
  ↓
Application
  ↓
Database
  ↓
Personalised response

That’s an application.

But a lot of the web looks more like:

Visitor
  ↓
Article

A portfolio is mostly content. A company website is mostly content. Documentation is content. A blog is content. A product landing page is usually content.

For those projects, I think it is worth asking whether an application framework is actually solving a problem.

The web platform keeps getting better

Ironically, I think building lightweight sites is becoming easier rather than harder.

HTML and CSS keep getting features that previously needed custom JavaScript, while hosting platforms have added things like Git deployments, edge functions, global CDNs and image processing.

That means I don’t have to choose between an old-fashioned static website and a modern web application.

I can start here:

HTML + CSS

and only move towards:

HTML + CSS
     +
small amount of JavaScript
     +
API / Worker
     +
database

when the project actually requires those things.

I much prefer complexity as something that can be added gradually rather than something that comes with the initial project template.

Simple websites tend to age well

One of the things I find interesting about the web is how durable its basic technologies are.

An HTML document like this:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Hello</title>
  </head>

  <body>
    <h1>Hello</h1>
    <p>This is my website.</p>
  </body>
</html>

isn’t particularly exciting, but browsers will probably understand it for a very long time.

Frameworks change considerably faster.

That doesn’t mean frameworks are bad. They solve real problems and make many types of applications much easier to build.

But if I don’t have those problems, I would rather depend on HTML.

I don’t expect every project I create to survive for decades, but I like knowing that the foundation doesn’t depend too heavily on a particular framework, runtime or package ecosystem.

My website doesn’t need to be an app

Ultimately, that’s probably the simplest explanation for why I still build static websites.

My website exists to publish articles, projects, photographs and information about what I do. Hugo gives me enough structure to manage all of that without changing the fundamental simplicity of what gets delivered to the visitor.

At the end of the build process, my website is mostly this:

HTML
CSS
Images

and that’s exactly how I want it.

Modern web development gives us an enormous number of useful tools, but access to more technology doesn’t mean every project needs more technology.

For many websites, I still think the best architecture is surprisingly simple: generate the page ahead of time, serve it quickly, and let the browser do what it was designed to do.