Eleventy: The Static-Site Generator I Build On

If you click "view source" on any page of any site I build, the HTML you see was produced by Eleventy, a small open-source tool that compiles templates and content into static HTML files. Eleventy is the build layer of every project I ship. It does not run in production (the visitor never touches it); it runs on my computer or on Cloudflare's build infrastructure to produce the files that then live on the edge network.

For a small-business client, the choice of build tool is invisible the way the choice of carpentry tools is invisible to a homeowner. What matters is the finished house. But the build tool shapes the lifetime cost of the site, the speed of changes, the ease of moving to another developer, and how quickly things break when the platform changes underneath. So I am going to walk through the choice once.

What Eleventy is

Eleventy (often shortened to 11ty) is a static-site generator. You write your site as a set of templates (the layout shared across pages) and content (the actual page-by-page words and structure), and Eleventy combines them into a folder of plain HTML files ready to deploy.

The output is just files. No database. No server-side logic. No PHP runtime. No JavaScript framework hydrating in the browser. Just HTML that the browser can parse and render directly, the way the web was originally designed to work.

This sounds primitive in 2026. It is also the reason the sites I build score 95 to 100 on Google PageSpeed, sit comfortably in the green band on every Core Web Vital, and never need a security patch.

Why I picked it over the alternatives

Static-site generators are a small and mature category. The leading options in 2026 are Astro, Eleventy, Hugo, Jekyll, and Next.js (in static-export mode). I have used most of them; I picked Eleventy for four specific reasons.

It is genuinely small. The framework itself is around 250 KB of JavaScript. The build is fast (a 200-page site rebuilds in two seconds). I can read the entire codebase if something behaves unexpectedly. The minimum-viable-change loop on a site is the time to save a file.

It does not impose a programming model. Astro and Next.js both want you to use components in a specific way. Eleventy does not have an opinion. I can write templates in Nunjucks (which I do), in Liquid, in Handlebars, in Markdown, in plain HTML, or mix all of them in the same project. The flexibility shows up most when I need to do something the framework's authors did not anticipate.

It produces clean HTML. Astro, Next.js, and Hugo all wrap the output in framework-specific markup, hydration scripts, or build-system breadcrumbs that bloat the bytes shipped to the browser. Eleventy outputs only what I wrote. If a page is 6 KB of HTML in source, it is 6 KB on the wire.

It is conservative about its dependencies. Eleventy itself has a short list of dependencies, and the maintainers are slow to add more. The result is a build tool that does not break every six weeks because some upstream package decided to rewrite its API. I have a build of mine running on Eleventy 0.7 in the way-back, and it still builds today.

What this means for a client

The build-tool choice produces three concrete client-facing benefits:

The site is portable. If the client ever wants to move to another developer, Eleventy is a small enough framework that the next developer can learn it in a weekend if they have not already. There are no Eleventy-specific cloud services, no proprietary cloud build steps, no licensed templates to extricate. The repo is just a folder of files.

The site keeps working over time. Eleventy projects from five years ago still build today with minimal changes. Compare to WordPress sites where the theme breaks every PHP-version update, or to React-based stacks where the framework reinvented itself between major versions.

Build times stay fast. Adding a hundred pages to a site does not slow the build noticeably. The dev loop on adding a new blog post is "save the markdown file, watch the browser refresh in two seconds." That speed compounds across thousands of small updates over the lifetime of the engagement.

How a typical Eleventy project looks

A small business website on Eleventy is a few directories of files:

• src/_includes/layouts/ — the shared layouts (header, footer, base wrapper).
• src/_includes/partials/ — small reusable HTML fragments (the contact form, the navigation, the footer).
• src/_data/ — JavaScript files exporting structured data (the site config, the navigation links, the service-area metadata).
• src/blog/posts/ — blog posts as Markdown files, one per post.
• src/ — every other page (home, about, contact, services), each as a single Nunjucks or Markdown file.
• src/assets/ — images, CSS, JavaScript that pass through to the build output.

The folder structure is the site structure. A new page is a new file. A new blog post is a new Markdown file in the posts directory. The mental model is the file system; there is no admin panel layered on top.

What this skips

By building on Eleventy, I get to skip a category of work that platforms like WordPress require:

• No theme update cycle.
• No plugin compatibility matrix.
• No PHP version migrations.
• No database migration when changing hosts.
• No admin-panel security patches.
• No "WordPress core update bricked the site" emergency calls.

The site does not have surfaces for any of those things to break, so they do not break.

What it cannot do

Honest limits:

Eleventy cannot run server-side logic. A static site is, by definition, just files. Anything that needs to happen at request time (form processing, search, dynamic content) lives outside Eleventy. I use Web3Forms for forms, Cloudflare Workers for dynamic endpoints, and Pagefind (built at deploy time, runs in the browser) for search.

Eleventy is not a CMS. Clients who want to edit pages through a web admin do not get that out of the box. For most of my clients, this is not an issue (they email me with changes and the change lands quickly), but for clients who specifically want to log in and edit pages themselves, I can layer a headless CMS like Decap or Statamic on top, or pivot to a different stack entirely.

For most service businesses, the static model is exactly right. The site changes a few times a month, the changes are small, and the email-driven update workflow is faster than logging into an admin panel.

Why this matters for the lifetime cost of the site

Hosting cost on Cloudflare Pages: free.
Plugin cost: zero.
Theme licensing cost: zero.
Database hosting cost: zero.
Performance optimization plugin cost: zero.
Security plugin cost: zero.
Backup-service cost: zero (the source is in Git; the build is reproducible).

The infrastructure cost of running a typical Eleventy site is genuinely zero. The cost of the engagement is the cost of my time, on the standard plan, and the only third-party service that costs money is the optional Web3Forms paid tier when a client exceeds 250 form submissions per month.

Compare to a typical WordPress small-business site, which often runs $30 to $80 per month in hosting + plugin licenses + premium theme + backup service + security service, and which typically needs a periodic developer engagement to handle the maintenance the platform layers create.

If your current site is on a heavier platform

The migration to a static-site generator like Eleventy is a real piece of work, but it pays back over the lifetime of the site. For sites I rebuild, the migration is just the rebuild itself. For sites that are otherwise healthy on their current platform, the migration is rarely worth doing on its own; the value comes when the rebuild is happening anyway.

If you are running a small-business site on WordPress and the maintenance overhead has become a recurring frustration, the conversation is worth having. The standard plan covers the rebuild, the migration, the new hosting, and the new analytics, all in one engagement, at one flat rate.