Over six months, a small UK-based theme studio rebuilt five client websites using Astro, a modern static site framework designed around the principle of shipping zero JavaScript by default. The results were striking enough that they've since stopped quoting WordPress projects entirely for content-driven sites. Here's a detailed look at what they did, what worked, and what they'd do differently.
The Background: A Theme Agency Under Pressure
The studio — a three-person team specialising in portfolio and small business themes — had built their entire workflow around WordPress. They maintained a library of custom themes using the block editor, relied on Advanced Custom Fields for flexible layouts, and delivered sites to clients on managed WordPress hosting.
The problem: Core Web Vitals. Google's 2021 page experience update made performance a direct ranking signal, and clients started noticing drops in organic traffic tied to sluggish LCP and high CLS scores. Managed hosting helped, but the underlying issue was architectural. WordPress loads PHP, queries a database, assembles HTML on every request — even for pages that never change. A standard business homepage with a quality theme was regularly scoring below 60 on Google PageSpeed Insights on mobile.
They evaluated several options: Gatsby, Next.js, Hugo, and Astro. The deciding factor was Astro's Islands Architecture — a rendering model where each interactive component hydrates independently, and static regions ship as plain HTML with no JavaScript overhead.
Project One: A Landscape Photography Portfolio
The first Astro rebuild was a photographer's portfolio that had previously run on a premium WordPress theme. The original site had 47 plugins, a 3.2-second Largest Contentful Paint on mobile, and was costing the client £40/month on managed WordPress hosting.
The Astro project structure was straightforward:
- Framework: Astro 4.x with static output mode
- Styling: Scoped CSS within
.astrocomponents — no CSS framework - Content: Markdown files in
src/content/using Astro's Content Collections API - Deployment: Cloudflare Pages (free tier)
- CMS: Decap CMS (formerly Netlify CMS) for the client's blog updates
Build time: 4.3 seconds for 68 pages. The resulting site shipped 0KB of JavaScript on every static page. The only JavaScript on the entire site was a small contact form handler — a 2.4KB Vue component that loaded only on the contact page, using Astro's client:visible directive so it didn't block rendering.
Post-launch PageSpeed score on mobile: 97. LCP dropped from 3.2s to 0.8s. Hosting cost: £0.
The Theme Architecture That Made It Work
One of the strongest advantages of building themes in Astro is the component model. Each .astro file is a self-contained component with its own scoped styles — conceptually similar to WordPress template parts, but without the global CSS bleed that makes WordPress theming unpredictable at scale.
The team settled on a folder structure that mapped cleanly to WordPress concepts:
src/layouts/— equivalent to WordPress theme templates (single.php,page.php)src/components/— reusable parts like headers, footers, cardssrc/pages/— route files; any.astrofile here becomes a URLsrc/content/— Markdown or MDX files with frontmatter, replacing the WordPress database for content
This structure is well-documented in Astro's official project structure guide. For developers already comfortable with WordPress template hierarchy, the mental model transfers surprisingly well.
Content Management: The Realistic Tradeoff
The most consistent concern from clients was content editing. WordPress's block editor is genuinely excellent for non-technical users. Asking a client to push Markdown files to a Git repository is not a viable alternative for most businesses.
The team tested three headless CMS options alongside Astro:
| CMS | Best For | Free Tier |
|---|---|---|
| Decap CMS | Simple blogs, Git-backed | Yes (open source) |
| Sanity | Structured content, teams | Yes (limited) |
| Keystatic | Astro-native, local-first | Yes (open source) |
For most small business clients, Keystatic became the preferred option. It runs locally during development and generates a minimal cloud editing interface on deployment — with zero vendor lock-in. Clients described the editing experience as "simpler than WordPress" once onboarded, primarily because there were fewer settings and plugin conflicts to navigate.
Performance Benchmarks Across Five Projects
After completing five full rebuilds, the results were consistent enough to draw conclusions:
- Average mobile PageSpeed score (WordPress original): 58
- Average mobile PageSpeed score (Astro rebuild): 94
- Average JavaScript shipped per page: 0KB (static pages), under 8KB (pages with interactive components)
- Average hosting cost reduction: from £25-40/month to £0-5/month
- Average build time: under 10 seconds for sites up to 100 pages
Academic research from Stanford's systems engineering program and industry benchmarks consistently show that sub-1-second LCP correlates with 20-30% lower bounce rates on content sites. The studio observed roughly a 22% average reduction in bounce rate across the rebuilt projects, measured over a 90-day post-launch window.
According to data from the U.S. Census Bureau's digital commerce statistics, the median small business website sees 60-70% of its traffic from mobile devices — exactly the context where WordPress performance gaps are most severe and where Astro's zero-JS default has the greatest impact.
Where WordPress Still Wins
This case study isn't a recommendation to abandon WordPress wholesale. There are clear scenarios where WordPress remains the better choice:
- WooCommerce stores with complex inventory, user accounts, and dynamic pricing — Astro handles static e-commerce well via integrations, but WordPress/WooCommerce is a more mature ecosystem for complex retail.
- Membership sites requiring per-user content gating — stateless SSGs don't have a native answer for this yet.
- Clients who insist on WordPress — preference is a real factor. Introducing a new toolchain has onboarding costs for clients and developers alike.
- Large editorial teams already embedded in the WordPress workflow — the productivity cost of migration often exceeds the performance gain.
The Wikipedia article on static site generators offers useful historical context on why the SSG model resurged as a serious alternative to CMSs after 2015 — largely driven by CDN cost reductions and the rise of Git-centric workflows among web developers.
What the Team Would Do Differently
With six months of Astro production experience, the studio identified two mistakes they'd avoid on future projects:
1. Underestimating image pipeline setup. Astro's built-in <Image /> component handles WebP conversion and responsive srcset generation automatically, but configuring it correctly for remote images (e.g., images stored in a headless CMS) required extra work. Budget time for this during scoping.
2. Not defining content schema upfront. Astro's Content Collections require a Zod schema for each content type. On the first two projects, schema was defined retroactively, requiring migration work. Defining schema before writing a single piece of content saved significant time on later projects.
Should You Consider Astro for Your Next Theme Project?
For content-focused sites — portfolios, blogs, documentation, marketing pages, local business sites — Astro's performance floor is meaningfully higher than WordPress by default. The framework has matured rapidly since its 1.0 release; Astro 4.x includes stable server-side rendering support, a first-party CMS adapter ecosystem, and seamless React/Vue/Svelte component interop via its integrations layer.
The theme development model maps well to existing WordPress knowledge: layouts are templates, components are template parts, and pages are routes. The concepts transfer; only the syntax changes. For teams already building custom WordPress themes, the learning curve is measured in days, not weeks.
Whether the performance gains justify the toolchain switch depends on the specific project and client. But for the studio in this case study, the answer was unambiguous: their last five WordPress projects all had mobile scores below 65. Their last five Astro projects all scored above 90. The data made the decision for them.