Static site vs WordPress: a performance audit across 12 client migrations

This is a working summary of what we measured across twelve client migrations, plus what the numbers do and don’t tell you.

What we measured

For every site, we collected Core Web Vitals data for thirty days before the migration and thirty days after. The pre-migration sites were all WordPress, ranging from off-the-shelf themes through to heavily customized builds with five-plus active plugins. Post-migration, all twelve sites ran on Astro deployed to Cloudflare Pages, with content authored through a headless CMS.

We used Lighthouse for synthetic measurement and Cloudflare RUM for field data. Field data is what real users experience; Lighthouse is what Google shows in PageSpeed Insights. Both numbers matter for different reasons.

The headline numbers

Largest Contentful Paint, the most-cited Core Web Vital, dropped from a cohort median of 3.2 seconds to 0.9 seconds. That’s not a 20% improvement. It’s a category change in perceived speed.

Time to First Byte fell harder: median 1.8 seconds to 90 milliseconds. Static files served from a global CDN behave differently from PHP rendering on a single origin server. The architectural shift is doing the work.

Cumulative Layout Shift was already passing on most sites pre-migration but improved across the board, mostly because Astro builds force you to size images and fonts at build time.

The First Input Delay improvement was the smallest and least uniform. WordPress with reasonable plugin hygiene was already fine here; the gain came from sites that were running heavy analytics or chat scripts that didn’t survive the migration cleanup.

What the cost numbers mean

The cost figures need a footnote. Pre-migration, the cohort spent $48 to $220 per month on hosting, CDN, security, and managed updates - depending on how heavy the site was and which managed WordPress provider they used. Post-migration, every site landed under $5/month total because Cloudflare Pages is free for most use cases and we serve images from R2 at near-zero cost.

This is real money for small businesses. Annualized across the cohort, the monthly hosting savings funded a full agency engagement.

What the cost number doesn’t include: developer time. Static sites are cheaper to host but require a build step and a Git workflow that some clients find harder to manage on their own. We solve that with a headless CMS, but somebody had to set that up. The migration itself takes real hours.

The editor experience question

The biggest concern when we propose static migrations is “but my team uses the WordPress editor every day.” That’s a fair concern, and the honest answer is: editing on a static-plus-CMS stack is different, not better or worse for everyone.

We surveyed the editorial teams at the three migrated sites where content updates happened weekly or more. Two reported clearly higher satisfaction with the new stack, citing faster preview, fewer surprise plugin breakages, and cleaner image handling. One reported lower satisfaction, mostly because the team had built a Gutenberg-based workflow with lots of custom blocks that didn’t translate cleanly to the new CMS.

The lesson: if your editorial team is heavy on Gutenberg block patterns, expect a real adjustment period. If they’re mostly writing prose with images, the new stack is generally a relief.

Where this study has limits

Twelve sites is not a huge sample. They were all our clients, which means we picked them, which means selection bias is real. Sites that were poor candidates for migration didn’t migrate; they kept running WordPress.

We also didn’t measure SEO impact in any rigorous way. Anecdotally, organic traffic was flat or up post-migration, but isolating the effect of a tech migration from the dozens of other things that move organic rankings is genuinely hard.

Practical takeaway

If your WordPress site is more than three years old and runs more than five plugins, an Astro migration is likely to hit our cohort numbers within the first month. If your team is heavily invested in WordPress-native authoring patterns, budget for the editorial transition before you sign off on the technical migration.

This is the trade-off in plain language. We do these migrations regularly and have a rough playbook for the editorial side as well as the technical side.