From WordPress to Jamstack: How I Made My Sites Dramatically Faster

WordPress powers over 40% of the web. It is mature, flexible, and has an ecosystem of thousands of plugins. For years, it was my default choice for every site I needed to spin up quickly. But somewhere along the way, it became a liability — slow page loads, constant security patches, plugin conflicts, and hosting bills that scaled with traffic spikes I had no way to predict.

So I moved my sites off WordPress. One went to Jekyll, one went to Astro. Both are Jamstack. Both are now dramatically faster. Here is the full story.

What Was Wrong With WordPress

Nothing was catastrophically broken. That is almost the problem. WordPress degrades gradually, in ways that are easy to rationalise.

Every page request hits PHP, which queries MySQL, which assembles HTML, which gets sent to the user — every single time, even if nothing on the page has changed in weeks. Caching plugins help, but they add their own complexity. Then you add a SEO plugin, a security plugin, a page builder, a form handler — and suddenly you have a 4-second Time to First Byte on a page that is essentially a blog post.

The other thing that crept up on me was maintenance overhead. WordPress core updates. Plugin updates. Theme updates. The occasional conflict between two plugins that used to work fine together. The nagging awareness that an unpatched WordPress install is a target. I was spending meaningful time just keeping the lights on — time I would rather spend writing or building.

The final nudge was a Google Search Console warning about Core Web Vitals. Largest Contentful Paint over 4 seconds. A blog post. Plain text and one image. Over 4 seconds.

That was enough.

What is Jamstack, and Why Does it Matter?

Jamstack is an architecture, not a specific tool. The name originally stood for JavaScript, APIs, and Markup, but the core idea is simpler: pre-build your site into static files, then serve them from a CDN.

No PHP. No database. No server-side rendering on each request. When a user visits your site, they get a pre-built HTML file delivered from an edge node close to them. There is nothing to compute, nothing to query. The file is just there, ready to send.

The performance implications are significant:

• Time to First Byte drops from 100–500ms to single-digit milliseconds from a CDN edge
• No database = no database attacks. The entire attack surface collapses
• Hosting costs become trivially small or free — serving static files from a CDN is cheap at any scale
• No more maintenance cycles for CMS updates, plugin conflicts, or PHP version migrations

The trade-off is that you lose the easy dynamic capabilities that WordPress gives you out of the box. But for most content sites — blogs, portfolios, marketing pages, documentation — those capabilities were never really needed.

Why Jekyll for One Site

Jekyll is the elder statesman of static site generators. It has been around since 2008, it is what GitHub Pages was built on, and it does one thing exceptionally well: it takes Markdown files and turns them into a fast, clean website.

I chose Jekyll for this blog for a few reasons:

The content model is dead simple. A post is a Markdown file in a _posts folder with a date in the filename. The front matter is YAML at the top of the file. There is no CMS to log into, no editor to fight with. I write in whatever text editor I have open and push to Git.

The ecosystem is stable. Jekyll has been around long enough that the rough edges are well-worn. Plugins are mature. The conventions are well-documented. I am not chasing a rapidly moving API.

GitHub Actions makes deployment seamless. A git push triggers a build on the CI server, which runs jekyll build and rsync’s the output to the web server. The whole pipeline runs in under two minutes for a site this size.

The migration from WordPress was largely mechanical: export posts from WordPress as XML, run a converter to produce Markdown files, adjust the front matter to match the Jekyll theme conventions, and clean up any shortcodes or embedded HTML that did not translate cleanly. The content survived intact. What was left behind was all the overhead.

Why Astro for Another

Astro is a newer generation of static site generator, and it takes a different philosophical stance. While Jekyll is opinionated and minimal, Astro is flexible and component-driven.

The headline feature of Astro is Islands Architecture: by default, Astro ships zero JavaScript to the browser. Components are rendered to static HTML at build time. If a component needs interactivity, you opt into it explicitly — and only that component loads JavaScript, hydrated only when it enters the viewport or when the user interacts with it.

For a site that is mostly content but has a few interactive elements — a search widget, an interactive chart, an embedded map — this is a perfect model. You get the performance of a fully static site for the 95% of the page that does not need JavaScript, and you pay the JavaScript cost only for the 5% that does.

I chose Astro for a more component-heavy site where I wanted to use modern tooling (React components, TypeScript, scoped CSS) without sacrificing performance. The WordPress version of that site was loading 600KB of JavaScript on every page. The Astro version ships 0KB on most pages, with small islands loading on demand.

The performance difference was not subtle. Lighthouse scores went from the 40s to consistent 98–100 across all four metrics. Google Search Console flipped from warnings to “Good” across the board within three weeks of the migration going live.

The Migration Process

Both migrations followed roughly the same pattern:

1. Export the content. WordPress has a built-in XML export under Tools → Export. This gets you all your posts, pages, categories, tags, and media.

2. Convert posts to Markdown. For Jekyll, tools like wordpress-to-jekyll-exporter do most of the heavy lifting. For Astro, the same Markdown files work — Astro has built-in Markdown and MDX support with frontmatter.

3. Handle media. Images are the messiest part. WordPress stores media in wp-content/uploads with no particular naming convention. I took this as an opportunity to clean up, rename images descriptively, and convert everything to WebP. Smaller files, better format, clean slate.

4. Map redirects. WordPress URLs often look different from Jamstack URLs. Getting this wrong means losing search rankings you have built up over years. I audited every post URL and configured 301 redirects in nginx before switching DNS — a _redirects map in a simple text file made this straightforward to maintain.

5. Switch DNS. The final step. Updating the A record to point at the new server and waiting for propagation. Once live, nginx serves the static files directly — no PHP, no application server, just files on disk.

6. Monitor. Google Search Console, server access logs, and a quick Lighthouse run on a sample of pages confirmed everything was working before I declared the migration done.

What I Gave Up

Honesty demands I mention the trade-offs.

The authoring experience changed. Writing in Markdown in a text editor and pushing to Git is natural for me as a developer. It would be a steep learning curve for a non-technical content editor. If your site has multiple authors who are not comfortable with Git, you will need to add a headless CMS layer — something like Decap CMS, Forestry, or Contentful sitting in front of your static generator.

Some dynamic features need rethinking. Comments (I use a third-party service), contact forms (a serverless function), and search (a static JSON index with client-side filtering) all work fine — but each one required a deliberate decision rather than activating a plugin. That is a small cost for me and a real cost if you depend heavily on WordPress’s plugin ecosystem.

Build times exist. WordPress renders on request; Jamstack renders at build time. For a site with thousands of posts, a full build can take a few minutes. For my sites, it is under two minutes. Incremental builds in both Jekyll and Astro help, but if you are publishing dozens of posts a day, this is worth thinking about.

The Results

The numbers tell the story clearly:

The hosting cost dropped sharply. A small VPS serving pre-built static files handles far more traffic than a WordPress server of the same size — and with a fraction of the configuration complexity. The security anxiety is simply gone — there is nothing to hack. No PHP, no database, no admin panel exposed to the internet. nginx serving static files is about as minimal an attack surface as you can get.

Should You Make the Move?

If your site is primarily content — a blog, a portfolio, documentation, a marketing site — and you are not deeply dependent on WordPress-specific plugins, the case for moving to Jamstack is strong. The performance improvements are real, the maintenance burden disappears, and the developer experience of writing in Markdown and deploying with Git is a genuine improvement.

Jekyll is the right choice if you want simplicity, stability, and a site that will just work for years without drama. Low ceremony, low maintenance, excellent for blogs.

Astro is the right choice if you want modern tooling, component-based development, and the flexibility to add interactivity precisely where you need it. Better for more complex sites with varied content types.

Both are dramatically better than a WordPress install for anything where performance and security matter.

WordPress is a remarkable piece of software. For some use cases — large editorial teams, complex e-commerce, sites that genuinely need server-side personalisation — it remains the right tool. But for most of what I build, it was bringing more complexity than capability.

The Jamstack sites are faster, cheaper, more secure, and easier to maintain. The only thing I miss is the comforting illusion that a plugin exists for every problem.

It usually just existed to create new ones.