Small Static

Keeping a small site fast and easy to find

2026-10-14T00:00:00Z

A static site starts out fast. It stays fast if you avoid adding weight you do not need, and it gets found if you publish a few small files that machines know how to read. This post is the checklist I use.

Set a page weight budget

Decide how heavy a page is allowed to be and check it now and then. For a text blog, 100 KB for the HTML, CSS and fonts together is generous. This site inlines its CSS, uses the reader's system fonts, and ships no JavaScript of its own, so a post is about 15 KB before images.

The usual causes of a slow blog are easy to spot:

Web fonts. Each weight and style is another file. If you want a custom font, host one variable font file yourself and preload it. Or use the system font stack and skip the download.
Large images. Resize them before you commit them. Add width and height so the page does not jump while they load, and loading="lazy" for anything below the first screen.
Third-party scripts. Analytics, embeds and chat widgets often weigh more than the rest of the page. Load the ones you keep with async so they never block the text.

Make it readable without effort

Speed is not only bytes. A line length of 60 to 75 characters, a font size of at least 17 pixels and enough contrast between text and background make a page faster to read. Support dark mode with the prefers-color-scheme media query, so the site follows the reader's system setting with no toggle to build.

Publish files that machines read

A few small files do most of the work of being found:

A sitemap. sitemap.xml lists every page with its address and date. Search engines use it to find new posts sooner. Submit it once in Google Search Console and Bing Webmaster Tools.

A feed. An Atom or RSS feed at feed.xml lets readers follow the blog in a feed reader. It is still how many people keep up with small sites, and it costs nothing to generate.

Good titles and descriptions. Each page needs a unique <title> and a meta description of one or two sentences. These are what people see in search results, so write them for people.

llms.txt. This is a newer convention: a Markdown file at the root of the site that lists the pages with a short summary of each, for AI tools that read the web. Its companion, llms-full.txt, holds the full text of every page in one file. This starter writes both at every build from the finished HTML, so they never fall out of date.

Let readers ask

llms-full.txt has a second use. The Ask button on this site sends a reader's question, together with the matching parts of that file, to a language model and shows the answer with links to the posts it came from. It is one script tag loaded with async, so it does not slow the first paint, and it only fetches the text when someone opens the box.

Check it now and then

Run Lighthouse in Chrome's developer tools on your home page and one post every few months. It measures speed, accessibility, best practices and search basics, and it tells you exactly what to fix. A small static blog should score at or near 100 in all four without special tricks.

Writing in Markdown, publishing with git

2026-09-23T00:00:00Z

The workflow for this blog fits on an index card: write a Markdown file, commit it, push it. A build server does the rest. Here is what each step looks like in practice, and the few habits that keep it smooth.

One file per post

Each post is a file in src/posts/. The file name becomes the address, so markdown-and-git.md is published at /posts/markdown-and-git/. Pick the name with care, because changing it later breaks links.

At the top of the file is a short block called front matter:

---
title: Writing in Markdown, publishing with git
description: How a post goes from a text file to the live site.
date: 2026-09-23
tags: [writing, workflow]
---

The title and description show up in the post list, in search results and in the feed. The date sets the order. Tags group posts on the tags page. Everything below the second --- is the post itself.

Drafts

A draft is a post that is not ready to be seen. The simplest way to keep one is a git branch: write on a branch called draft-whatever, and merge it when it is done. The live site is built from the main branch only, so nothing leaks.

If you prefer to keep drafts next to the finished posts, add draft: true to the front matter and tell Eleventy to skip those files in production. Either way works. The branch is harder to publish by mistake.

Images

Put images next to the post or in one images folder, and keep them small. A photo straight from a phone is often 4 MB. Resized to 1600 pixels wide and saved as WebP or a compressed JPEG, it is closer to 200 KB and looks the same on screen. Always write alt text that says what the image shows, not what it is called.

Publishing

When the post is ready, commit it and push:

git add src/posts/markdown-and-git.md
git commit -m "Post: writing in Markdown"
git push

The push starts a build on the host. On GitHub Pages that is a workflow file in .github/workflows/. Netlify, Vercel and Cloudflare Pages watch the repository and build on their own. A minute later the post is live.

Fixing a typo from a phone

Because the posts are text files on GitHub, you can edit one in the GitHub web editor or app, commit there, and the same build runs. This is the feature I did not expect to use and now use every week.

Keep the habits small

Write the description before the post; it forces you to know what the post is about. Read the post once in the browser before you push, since Markdown hides some mistakes until it is rendered. And commit often. A git history is the best undo button a writer has ever had.

Why I moved my blog to a static site

2026-09-02T00:00:00Z

For six years my blog ran on a hosted CMS. It worked, mostly. Then the bill went up, a plugin I relied on stopped getting updates, and I spent a Sunday restoring the database after a bad upgrade. That was the week I started moving it to a static site.

What "static" means here

A static site is a folder of finished HTML files. A program called a static site generator builds that folder from your writing, once, on your own machine or on a build server. When a reader asks for a page, the host sends the file that is already there. Nothing is assembled per visit, so there is nothing to crash per visit.

The generator I use is Eleventy. Others like Hugo, Jekyll and Astro work the same way. The choice matters less than people think. What matters is that the output is plain files you can move anywhere.

What I gained

It costs nothing to host. GitHub Pages, Netlify, Cloudflare Pages and Vercel all serve a small static site for free. My old host charged twelve dollars a month for the same traffic.

It is fast without trying. There is no database query and no server-side rendering between the reader and the page. The home page of this blog is under 20 KB, and it loads in well under a second on a slow phone connection.

There is less to attack. No login page, no admin panel, no plugin with a known hole. The worst thing someone can do is read the posts, which is the point.

The writing is mine. Every post is a Markdown file in a git repository. I can read them with any text editor, search them with grep, and keep them long after any particular tool is gone.

What I gave up

Some things need extra work on a static site. Comments need a third-party service or a mailing address. Search needs an index built at build time. A contact form needs a form service. None of these were hard to add, but they are not free in the way a CMS makes them feel free.

The other cost is the build step. You change a file, then the site has to be rebuilt and uploaded. In practice a push to GitHub does both in under a minute, so I no longer notice it.

Would I do it again

Yes. The site has been on a static host for over a year. It has not gone down, it has not needed an update, and it has not cost anything. The time I used to spend on maintenance now goes into writing, which was the reason I had a blog in the first place.