← Back to blog
webastrotooling

Why I Moved From WordPress to Static Site Generation

After years of fighting with WordPress, I switched to Astro and static HTML. Here's why — and why you might want to, too.

I ran a WordPress site for years. It was fine. Then it was slow. Then it got hacked. Then I spent a weekend updating plugins instead of writing. Then I stopped writing altogether.

Sound familiar?

The Breaking Point

The final straw was a 4-second load time on a page with 300 words of text. Three hundred words. Four seconds. The page weighed 2.3MB because WordPress loaded jQuery, three font families, a contact form library (on a blog post), and analytics scripts from four different services.

I was serving a hamburger on a flatbed truck.

What I Actually Need

When I stripped it down, my requirements were simple:

  • Write posts in Markdown
  • Have them show up on the site, sorted by date
  • Fast page loads
  • Not think about security patches

That’s it. I don’t need a database. I don’t need a PHP runtime. I don’t need a plugin ecosystem. I need HTML files served from a CDN.

The Astro Approach

Astro compiles your site to static HTML at build time. No JavaScript ships to the browser unless you explicitly opt in. A typical blog post on this site:

  • ~15KB total page weight
  • ~50ms DOMContentLoaded
  • Zero client-side JavaScript
  • Zero database queries

Content lives in Markdown files in a folder. I add a new .md file, push to git, and Cloudflare Pages builds and deploys it in about 30 seconds.

The Workflow

# Write a post
vim src/content/blog/my-new-post.md

# Preview locally
npm run dev

# Publish
git add . && git commit -m "new post" && git push

That’s the entire CMS. It’s a folder and git. And honestly? It’s the most I’ve written in years, because the friction dropped to nearly zero.

Trade-offs

Static sites aren’t for everything. If you need user accounts, dynamic content, or real-time features, you’ll need something more. But for a portfolio and blog? This is it.