I didn't have a fleet of slow WordPress sites to rescue. What I had in February 2026 was one old WordPress site (quicksummit.net, my automation consultancy) on a self-managed VPS, my personal site on that same kind of VPS setup, and a plan to launch several new content sites fast.
Every new site went into Astro on Cloudflare Pages. aimarketingpicks.com and remoteworkpicks.com went live on February 5, and soflotimes.com and anonark.com followed the same week. QuickSummit got rebuilt in Astro too. mikekhaytman.com moved off the VPS onto Pages as well, though it stays plain hand-written HTML because a personal site doesn't need a framework.
Below is why I made that call, what broke, and who should consider it.
Why WordPress gets slow
WordPress sites get slow because of: 1. Plugins: every plugin you install makes your site slightly slower 2. Database queries: each page load hits the database multiple times 3. Image optimization: photos need to be optimized for mobile, desktop, retina, etc., and WordPress doesn't handle this well by default 4. Caching complexity: WordPress needs plugins to cache, those plugins need configuration, and they can conflict with other plugins.
My own reasons were as much about operations as speed. Patching a server, WordPress core and a stack of plugins is a recurring job, and I didn't want it for content sites whose pages change a few times a week.
A small footnote that made the point for me: while launching aimarketingpicks.com, I found a $30/month WordPress hosting plan attached to the domain at my registrar. I wasn't using it. I cancelled it and got the charge refunded.
What's Astro
Astro is a static site generator. The distinction matters:
WordPress: Server gets request → queries database → runs PHP → generates HTML → sends to browser
Astro: You build the site once → generates HTML files → server just serves the files
The second is much faster because nothing is computed at request time.
Astro is specifically good because: 1. You can use modern JavaScript frameworks (React, Vue, Svelte) but they only run where you need them 2. It generates static HTML by default 3. It's fast to build 4. Cloudflare Pages (where I host) is basically free ($0 for small projects)
The build process (for non-technical people)
Instead of WordPress's admin dashboard, you write your content in markdown files. Your computer runs a build process that turns those markdown files into HTML. Then you push those HTML files to Cloudflare Pages.
I build locally and push the output with one wrangler pages deploy command. (You can also connect a Git repo and let Cloudflare build on every push.) Either way, the site is served from Cloudflare's edge network rather than a central server, which is why it's fast.
What I can honestly measure
I don't have a before-and-after speed chart, because there's no fair "before." The new sites never ran on WordPress, and I didn't benchmark QuickSummit's old build before retiring it.
What I can say: a static page on a CDN skips the work that makes WordPress slow. No PHP, no database queries, no cache plugin to configure. The speed benefit is real, but I don't have a measured number for it and won't invent one.
The benefits I did see firsthand: $0 hosting, no server to patch, and sites simple enough that an automated job can publish to them safely (more on that below).
What broke
The WordPress admin dashboard is gone. Now I have to:
- Write posts as markdown files
- Preview locally before deploying
- Commit changes to Git (not a big deal, but it's a step)
- Deploy manually (or set up a CI/CD pipeline)
If I misspell something, I don't fix it in an admin panel. I fix the markdown file and redeploy. A typo fix that takes seconds in a WordPress editor becomes edit, rebuild, deploy.
Two things broke that I didn't expect:
- Static doesn't mean SEO-safe by default. A week after launch, Search Console showed almost nothing indexed. The template put tag pages, pagination, search and archive pages in the sitemap, so Google found a pile of thin URLs. On aimarketingpicks.com, 75 URLs were not indexed, 72 of them sitting in "Discovered, currently not indexed." I filtered the sitemaps down to real content pages and noindexed the thin templates on the three sites that had the problem.
- No admin panel means no revision history unless you add it. An automated content job overwrote an existing post and wiped an embed I'd added by hand. The file had never been committed to Git, so there was nothing to roll back to. I restored it manually, committed that site's articles to Git the same day, and made "commit before you deploy" a rule.
Also, I lost:
- The WordPress admin experience (which is good, even if slow)
- Easy content scheduling (Astro can do this, but it requires a bit of setup)
- Live previews while editing
- Plugins that added functionality (related posts, similar products, etc.)
Those plugins are useful. Now if I want that functionality, I have to write custom code.
The cost comparison
WordPress (my old VPS setup):
- Hosting: a server to pay for every month
- Maintenance: OS patches, WordPress core updates, plugin updates and conflicts
- Domain: same as below
Astro + Cloudflare:
- Hosting: $0 (Pages free tier)
- Domain: about $11/year at Porkbun
- Maintenance: dependency updates when I choose to do them, no server
- Setup: real time up front, plus comfort with a terminal
Setup time is the big cost in a migration. If you're building a new site, most of that cost disappears, which is why every new site I launch starts static.
Who should switch
You should switch if:
- Your blog doesn't need frequent updates
- You're comfortable with Git and command line
- You want faster sites
- You don't need a complex plugin ecosystem
- You're willing to put real time into the migration
You shouldn't switch if:
- You update your blog multiple times per day
- You want a graphical interface for editing
- You have non-technical team members who need to edit content
- You need specific WordPress plugins
The bigger picture
The web is moving away from CMS-centric architecture. Instead of WordPress doing everything (hosting, rendering, database), services are specializing.
Astro handles static generation. Cloudflare handles CDN and edge computing. If you need a database, you use something like Supabase. If you need a CMS interface, you plug in Decap CMS or Sanity.
It's more complex to set up, but once it's set up, it's faster, cheaper, and more maintainable.
Would I do it again
Yes. The cost savings and not having a server to babysit both matter, and the developer experience is better.
But I wouldn't push it on every site. If a business runs on specific WordPress plugins, or a non-technical team edits content every day, those are good reasons to stay. Plenty of the client sites I work on run on WordPress or another CMS, and for them that's the right call.
For new projects and content sites I control, Astro + Cloudflare is now my default.
The learning curve
Astro has a steeper learning curve than WordPress.
You need to be comfortable with:
- Git (version control)
- Markdown (formatting)
- Terminal commands
- Basic development concepts
If you're non-technical, WordPress is still the better choice: the admin interface is good, it's well documented, and you can Google your way through problems. Astro expects you to be willing to write a little code.
Hybrid approach
You don't have to choose. Some people run Astro for the blog and WordPress for e-commerce or membership. The combination works.
Or you could use a headless WordPress (database only) + Astro (frontend). That gives you WordPress content management + Astro performance.
I suspect that's where things are heading: WordPress managing content, and Astro, Next.js or similar presenting it fast.
Conclusion
The web is moving toward decoupled architecture. The tool that stores your content (CMS) is separate from the tool that displays it (static generator or framework).
WordPress was an all-in-one solution, which made sense when the alternatives were weak. For some use cases they're now better.
Pick the architecture that fits your needs and your business, rather than the one you already know.
Update, October 2026
The portfolio is now six Astro sites on Cloudflare Pages (aimarketingpicks, remoteworkpicks, soflotimes, anonark, quicksummit and blacktiewhiteglove), plus this site in plain HTML. Three things I'd add:
- The cutover took longer than the rebuild. QuickSummit's Astro version existed in February, but the clean, final cutover to Pages didn't happen until July 27, 2026, once a redesign was ready. Until then the old VPS was still in the picture, and I kept it running afterward as the rollback. I'd recommend the same.
- Check your 404s. Without a built 404 page, Cloudflare Pages answered unknown URLs on one of my sites with the homepage and an HTTP 200. That's an unlimited supply of duplicate pages. The old nginx setup on QuickSummit had the same flaw. One curl against a made-up URL catches it.
- Static sites are easy to automate. Since July 2026, a content pipeline I built researches, drafts, quality-gates, publishes and deploys posts to these sites on its own. That's only practical because a post is a markdown file and a deploy is one command.