Overview

Yes, the title is an Aerosmith reference. If you’re too young to get it, just know that in 1993 Steven Tyler was screaming about living on the edge and it was a whole thing. I’m now old enough that referencing a 33-year-old rock song in a blog post about web infrastructure feels appropriate.

When I first decided I wanted a personal site, I didn’t have a ton of time to invest in building something from scratch. I was busy with other things and just wanted to get something up and running. WordPress was the obvious choice. Spin up a managed host, pick a theme, start writing. It took maybe an afternoon to have a site live on the Internet. Good enough, ship it, move on.

But pretty quickly, the cracks started showing. The Gutenberg block editor felt clunky for writing technical content. Inserting code blocks was a pain, formatting never quite looked right, and I constantly felt like I was fighting the editor instead of just writing. I just used the prebuilt templates as-is because I had other priorities. The result was a site that looked generic and never really felt like mine.

Every year when that renewal invoice hit for $50 USD, I’d ask myself the same question: why am I paying this much for something I don’t even like using? My blog doesn’t have user accounts, shopping carts, or dynamic server-side logic. It’s just text and images. There had to be a better way.

Turns out there is. I moved everything to a fully static site architecture using Astro and Jekyll with KeyStatic as my content management layer, all deployed on Cloudflare Pages. The result is a site that loads faster, costs nothing to host, and gives me far more control over how everything looks and behaves.

The Problem with WordPress

Don’t get me wrong. WordPress is an incredible platform. It powers a huge chunk of the Internet and for good reason. But for a personal technical blog, it’s overkill in ways that actually work against you.

I was on WordPress.com specifically, Automattic’s hosted platform. They run about 30 data centers across 6 continents with over 10,000 physical servers. When someone visits your site, the request gets routed to your site’s primary data center where PHP runs, WordPress core executes, and MySQL gets queried to assemble the page. For a blog post that hasn’t changed in six months, that’s a lot of unnecessary computation happening on every request.

Here’s the kicker: WordPress.com’s Site Accelerator CDN, the feature that caches and serves your static assets from edge servers, is only available on the Business and Commerce plans. On the Personal and Premium plans, you don’t get it. Every page view was a full round-trip to whatever Automattic data center my site was assigned to. No edge caching, no CDN, just a raw origin server hit every time.

The customization story is what really got to me. Want to change how code blocks render? You’re constrained to whatever the theme exposes in its settings panel. I lived this for years and never got the site looking the way I wanted.

Visitor every request no CDN on Personal plan WordPress.com Data Center PHP ~50ms exec WordPress MySQL ~20ms query Mem- cached Total: 200-800ms per page view

Figure 1: The WordPress.com request path on a Personal plan. Without the Site Accelerator CDN (only available on Business/Commerce plans), every page view is a direct round-trip to an Automattic data center. PHP executes, WordPress assembles the page, and MySQL is queried.

Why Static Sites Win for Blogs

A static site generator flips the model entirely. Instead of building each page on every request, you build the entire site once at deploy time. The output is just HTML, CSS, and maybe some JavaScript. Flat files that any web server can deliver without thinking about it. No database queries, no PHP execution, no server-side processing at all.

This matters for two reasons. First, it’s fast. There’s nothing to compute at request time, so latency is basically just network round-trip time plus however long it takes to transfer a few kilobytes of HTML. Second, and more importantly for my setup, it means the entire site can be cached and served from a CDN’s edge network.

Cloudflare’s Edge Network

Cloudflare operates data centers in over 330 cities across 125+ countries, interconnected with more than 13,000 networks. They claim that 95% of the world’s Internet-connected population is within 50 milliseconds of a Cloudflare server. If you want a deeper look at how Internet routing and peering actually work at this level, I wrote about it in Beyond the Last Mile: How Internet Routing Shapes Red Team Ops.

When your site is fully static, Cloudflare doesn’t just proxy the request to your origin server. It caches the entire site at the edge and serves it directly from whichever PoP is closest to the visitor. Someone in Tokyo gets my post from Tokyo. Someone in Sao Paulo gets it from Sao Paulo. The HTML never travels back to some origin server in Virginia.

With a truly static site on Cloudflare Pages, there’s no origin to pull from in the traditional sense. The built files are deployed directly to Cloudflare’s edge network. The CDN isn’t a caching layer in front of your server. It is the server.

Cloudflare Network Upper-Tier Cache Tokyo visitor ~8ms (cache hit) Tokyo PoP London visitor ~5ms (cache hit) London PoP NYC visitor ~3ms (cache hit) NYC PoP Lima visitor ~15ms Lima PoP cache miss internal pull ~20-40ms Upper-Tier PoP Upper-Tier PoP

Figure 2: Cloudflare Pages with Tiered Cache. Most visitors get a cache hit at their nearest PoP in single-digit milliseconds. On a cache miss, the lower-tier node pulls from a nearby upper-tier Cloudflare data center (an internal hop, not a round-trip to an external origin). Assets are cached per-PoP with a one-week TTL.

The Stack: Astro, Jekyll, and KeyStatic

My site uses a somewhat unconventional combination of tools that plays to each one’s strengths.

Jekyll handles the blog portion of the site. It’s been around since 2008, it’s battle-tested, and it does one thing well: it takes Markdown files with YAML front matter and turns them into blog posts. The templating is straightforward, the Markdown rendering is solid, and there’s no unnecessary complexity. For a technical blog where I’m mostly writing prose with code blocks and the occasional image, it’s exactly the right tool.

Astro handles the rest of the site: the portfolio, landing pages, and anything that benefits from a more modern component-based architecture. By default, Astro ships zero JavaScript to the client. Components render to HTML at build time and that’s what gets served. If you need client-side interactivity somewhere, you opt into it per-component. Less JavaScript means smaller payloads means faster loads from edge locations.

KeyStatic provides a content management interface so I’m not always editing raw Markdown files in a text editor. It gives me a clean editing experience with live preview while still storing everything as flat files in the git repository. No database, no separate CMS server. Just a UI layer on top of the same Markdown and YAML files that Jekyll and Astro consume. Every post is a commit, every edit has a history, and I can still drop into my editor and work with the raw files whenever I want.

Author git push GitHub webhook Cloudflare Pages Build Jekyll Astro HTML CSS/JS deploy Tokyo PoP London PoP NYC PoP Sydney PoP 330+ more

Figure 3: The deployment pipeline. A git push triggers a Cloudflare Pages build, which runs Jekyll and Astro and deploys the static output to 330+ edge locations automatically.

One of the things that surprised me most about Cloudflare Pages was how easy the CI/CD setup is. You connect your GitHub repo, tell it the build command and output directory, and that’s it. Every push to main triggers an automatic build and deployment to 330+ edge locations. No GitHub Actions workflows to write, no build scripts to maintain, no deployment infrastructure to manage. Cloudflare even handles branch previews automatically, so you can check a draft post on a preview URL before merging to production. For a static site like this, it’s hard to imagine a simpler deployment setup.

Full Control Over Presentation

With WordPress, you’re always working within the constraints of whatever theme you’ve chosen. Want to change the layout of your post headers? You’re digging through PHP template partials. Want custom syntax highlighting? Hope your theme supports it, or get ready to fight with plugin CSS specificity.

With a static site, the HTML and CSS are yours. All of it. Want a specific background color on code blocks? Write the CSS and it’s done. Want a custom component for displaying CVE information? Just build it. No theme abstraction layer, no plugin conflicts, no wondering whether a WordPress update is going to break your customizations.

For a technical blog where I care about how code renders and how diagrams display, having direct control over every element on the page is a massive improvement.

AI as a Force Multiplier

With the current state of AI coding tools, the barrier to customizing a static site has basically collapsed. I use Claude Code with Opus 4.6 extensively, and it’s reached the point where it’s practically eliminating the need for a traditional CMS altogether.

Want to restyle the blog layout? Describe what you want and Claude Code builds it. It reads the existing codebase, understands the templates and styling, and makes changes across multiple files in one shot. What used to be an afternoon of digging through documentation and Stack Overflow is now a five-minute conversation.

The whole point of a CMS was that you shouldn’t need to write code to manage a website. But when an AI can write and modify code faster than you can navigate a WordPress admin panel, that advantage evaporates.

In practice, my writing workflow is Claude Code in one window and a browser with the local dev server in the other. I describe a change, it makes it, I refresh and see the result. It’s effectively a WYSIWYG editor, except instead of dragging blocks around in a clunky UI, I’m just saying what I want in plain English.

The Cost Comparison

I was spending about $50/year on WordPress hosting. That’s not a lot of money, but it bothered me knowing there was a better option. I’d always known a static site on something like Cloudflare Pages would be the right architecture for a blog like this, but when I originally set things up I just wanted to get writing and didn’t have the time to build something from scratch. WordPress was the quick path to having a live blog. Once I finally had the time to revisit the setup, it was hard to justify continuing to pay for PHP execution and MySQL queries to serve pages that hadn’t changed in months.

With Cloudflare Pages, hosting is free. A .com domain through Cloudflare Registrar (which charges wholesale with zero markup) runs about $10.44/year. So the total cost went from ~$60/year to ~$10/year, and the only expense is the domain registration you’d be paying regardless.

This isn’t a knock on WordPress. They provide real value with managed updates, security monitoring, backups, and a massive plugin ecosystem. If you need a dynamic CMS with e-commerce or server-side logic, WordPress is still a solid choice. The point is that for a static blog, you’re paying for infrastructure you don’t need. The site ended up faster, more customizable, and architecturally simpler as a bonus.

Migrating the Content

One question people always ask about switching away from WordPress is how painful the content migration is. In my case, it was surprisingly easy thanks to AI tooling.

I had Claude Code browse my live WordPress site, read each post, and rewrite the content into properly formatted Markdown files with YAML front matter. It handled the text, headings, links, and formatting in one pass. No manual copy-pasting, no janky WordPress export XML that needs a dozen cleanup scripts.

The bigger win was with code blocks. On WordPress I’d gotten so frustrated with the code formatting that some of my posts had screenshots of code instead of actual text. Claude Code OCR’d those images and converted them into real inline code blocks with proper syntax highlighting. Posts that previously had unselectable, unsearchable code screenshots now have actual <code> blocks that render correctly with Prism.js. That alone was worth the migration.

Trade-offs

It’s not all upside. There are real trade-offs to this approach.

The initial setup is more involved than spinning up a WordPress site. You need to understand build tools, static site generators, and deployment pipelines. If something breaks in your build, you’re debugging Node.js dependency issues or template compilation errors instead of just toggling a plugin. The learning curve is real.

You also lose the WordPress plugin ecosystem. Need a contact form? You’re integrating a third-party service or building something yourself. Need comments? Same deal. WordPress has a plugin for everything, and while many of them are mediocre, the breadth of that ecosystem is genuinely useful.

And content management, even with KeyStatic, isn’t as polished as the WordPress editor. WordPress has had over two decades to refine its writing experience. Gutenberg, whatever your opinion of it, is a capable block editor. KeyStatic is good, but it’s a younger project and it shows in places.

Final Thoughts

For my use case, a technical blog with occasional portfolio updates, the move from WordPress to a static site on Cloudflare’s edge has been an unambiguous improvement. The site is faster because content is served from the nearest edge location rather than a single origin server. I have complete control over the HTML and CSS without fighting a theme system. And hosting went from $70/year to free.

If you’re running a blog that’s mostly static content, it’s worth considering. The old trade-off between “easy but slow and expensive” and “fast but complex and manual” is largely obsolete. You can have fast, cheap, and not-that-complicated all at once.