Building a simple fast blog with a static site generator

A personal blog doesn't need a database, a plugin updater, or a server you have to patch every other Tuesday. The fastest sites in my feed are mostly flat HTML served from a content delivery network, and a static site generator is the tool that produces that HTML from plain text. If you write in Markdown, keep a handful of templates, and don't want to babysit infrastructure, the workflow is genuinely approachable.

There's also a quiet Australian case for going static. NBN connections vary wildly between a Fibre-to-the-Premises street in inner Melbourne and a fixed-wireless link outside Bendigo, so a site that ships kilobytes instead of megabytes feels noticeably snappier on a phone at a café in Fitzroy. Pair that with the country's growing coffee-and-keyboards crowd around Brisbane's Fortitude Valley and Sydney's Surry Hills, and the audience already expects pages that open before the kettle finishes boiling.

Why a static site generator suits a personal blog

Static site generators, often abbreviated to SSGs, take a folder of Markdown files, run them through a set of templates, and spit out a directory of plain HTML, CSS and JavaScript you can upload almost anywhere. There's no PHP, no Node service sitting in memory waiting for a visitor, and no MySQL to migrate when you change hosts. The output is the site. If you can drag a folder into Netlify, Cloudflare Pages, or a cheap S3 bucket, you can publish.

This shape matches how most of us actually write. A post is a text file with a bit of front matter for the title, date and tags. Drafts live in the same folder as published posts. You version everything in Git, which doubles as a backup and a complete edit history. If you stop writing for six months and come back, nothing has rotted; nothing needs a security update. The blog is just files.

The trade-off used to be that static sites felt stiff. That has largely gone away. Modern generators support drafts, pagination, tag pages, RSS feeds, image processing and full content search. For a personal site covering coffee, travel notes and the occasional rant about politics, the feature set is more than enough, whether you're writing a quick café review or working through twenty Irish history books one chapter at a time.

Picking the right generator for your workflow

Hugo is the speed demon of the family. Written in Go, it can rebuild a few thousand posts in under a second, which makes it a favourite among writers who care about iteration more than configuration. Jekyll, the old guard, is Ruby-based and still common on GitHub Pages; its plugin ecosystem is enormous if you don't mind slower builds. Eleventy (often written as 11ty) is a JavaScript option with a very gentle learning curve, and Astro has become the default for people who want sprinkles of interactivity without giving up the static-first philosophy.

A practical way to choose is to clone two starter templates and build the same five-post blog in each. Pay attention to how the content folder is organised, how layouts inherit, and how the development server handles live reload. The tool you enjoy typing into is the one you'll keep using at 11pm after a long day editing your annual book list. Pick the one with the smallest cognitive overhead rather than the one with the most GitHub stars.

Also consider language familiarity. Hugo's template syntax is its own small language; Eleventy uses familiar JavaScript or Liquid; Astro lets you drop into components when you want them. If you already write JavaScript, Eleventy or Astro will feel like home. If you'd rather never see JavaScript again, Hugo is the path of least resistance.

Setting up your writing environment and theme

The fastest way to start is with a starter theme that already has typography, syntax highlighting and an RSS feed wired up. Resist the urge to design from scratch on day one. Pick something clean, change the font to something that suits your eyes, and start publishing. The first post matters far more than the first colour palette.

Structure your content folder by year, or by section if you write about very different topics. A flat content/posts/2026/ folder is fine for a few dozen posts; if you anticipate writing for years, separate subfolders per year keep the index pages from ballooning. File names should be kebab-case slugs that match the URL you want, which means flat-white-melbourne.md becomes /flat-white-melbourne/ once the site is built.

For tooling, install a Markdown linter, set up a preview command in your editor, and add a make or npm script for build, serve and deploy. Three commands should cover ninety percent of your needs. Anything that needs more than three steps is usually a sign you've over-engineered it, which is a hazard in any hobby tech project but particularly common when following tutorials written for the Australian tech market.

Hosting and delivery that feels local

Hosting used to be the worst part. It's now the easiest. Netlify, Cloudflare Pages, Vercel and GitHub Pages all offer generous free tiers, continuous deployment from a Git repository, and global CDNs by default. Push to your main branch, the build runs, the site goes live within a minute. If you'd rather host it yourself, a small object storage bucket on AWS, Cloudflare R2 or Backblaze B2 will do the job for cents a month.

For an Australian audience, edge locations in Sydney and Melbourne matter more than they used to. The major CDNs all have points of presence in both cities now, so a reader in Adelaide will typically hit a cache in Melbourne before the request reaches origin. Still, it pays to keep your images small and your HTML lean. A typical post should be under 100KB of HTML and CSS combined; everything else should be a separate file that can be cached.

Custom domains are cheap and worth it. A .com.au or .au domain signals that you live here and write for here, even if your readers are scattered between Perth, Hobart and a few expats in Berlin. DNS is the slowest moving part of any new site, so configure it on day one and let it propagate while you write your first post.

Keeping content current without losing simplicity

The biggest fear people have about static sites is editing old posts. In practice it's a joy. You open the file, change a line, commit, push, and the site rebuilds. There's no admin panel to log into, no cache plugin to forget to clear, no staging site to maintain. If you mess something up, git revert is sitting right there.

For images, a short preprocessing script or a generator's built-in image pipeline will create thumbnails, convert to WebP, and generate srcset attributes. Don't try to be clever. Pick one format, one max width, and let the tool handle the rest. The same goes for syntax highlighting: enable it in your theme, then forget about it.

A simple editorial rhythm beats a complex CMS. Draft on Tuesday, edit on Thursday, schedule the post in your Git commit by setting the date in the front matter to a Friday. A weekly or fortnightly cadence, the kind that fits comfortably around a working week in Brisbane or Sydney, is easier to keep than a daily one. If you want readers to find your old posts, an annual index page and a tag list are usually sufficient.

Performance and search basics for Australian readers

A static site is fast by default, but a few habits keep it that way. Inline only the styles required for the first screen, defer non-critical scripts, and lazy-load anything that lives below the fold. Run your own homepage through Lighthouse or PageSpeed Insights before you publish your tenth post; the score will set the bar you aim at for everything that follows.

Search engine optimisation for a personal blog is mostly about good titles, descriptive slugs, and internal links between related posts. A post about a weekend in Lisbon can naturally link back to your reading notes, which is the kind of contextual link that travel and reading lists thrive on. Add structured data only if you're writing recipes or events; otherwise keep it simple.

Finally, an honest mention of the social side. Australian readers use the same networks as everyone else, but Bluesky and Mastodon have a notably high local presence, particularly in the design and tech corners of Melbourne and Sydney. Cross-posting short excerpts with a link back to the full post remains the cheapest distribution channel for a blog this size.

Practical habits for a long-running static blog

• Commit often, push rarely, and write your commit messages as if a stranger will read them in five years.
• Keep a single README.md in the repo with the three commands needed to build, serve and deploy the site.
• Pin the generator's version in your config so a future rebuild doesn't quietly break.
• Back up the Git repository somewhere that isn't the same provider as your primary remote.
• Treat the theme as a fork you can patch, not a dependency you must constantly update.

The first draft of this post was a single Markdown file written in a café on Lonsdale Street, and it was deployed to a global CDN before the flat white arrived. The single concrete next step is to clone an Eleventy or Hugo starter, change one line of CSS, and publish one short post before the end of the week.