From Laravel to Astro: why I rebuilt my site with the right tool for the job

I didn’t rewrite this website because Laravel let me down. I rewrote it because curiosity got the better of me, and the performance gap was impossible to ignore.

This site started life as a Laravel application using Inertia and React. That wasn’t an accident. Laravel is what I use day in, day out to build backend-heavy web applications and automate business processes for clients. When I needed a site, I reached for the tool I knew best.

It worked. But over time, it became clear that “works” and “is the right tool” are not the same thing. This post is about what changed when I rebuilt my site with Astro, what I gained, and why this wasn’t a rejection of Laravel at all.

Why Laravel felt like the obvious choice

Laravel with Inertia is a solid stack. You get a single codebase, modern tooling, and a React frontend without building a separate API. For real applications, it’s a great setup.

For my site, the thinking was simple:

• I already know Laravel deeply
• Inertia removes a lot of SPA boilerplate
• React gives flexibility if I ever want richer interactivity

On paper, it looked sensible. In practice, I’d built a full application to serve mostly static content. If you’re thinking “that’s still fine”, you’re not wrong. But there’s a hidden cost to familiarity.

What actually matters for a content-driven site

Once I stripped the problem back, the requirements were boring in the best possible way:

• Fast initial page loads
• Minimal JavaScript
• Cheap, low-maintenance hosting
• Simple content updates
• No runtime surprises

There’s very little “application” in a portfolio and blog. No dashboards. No auth. No complex state. Mostly HTML, some CSS, and the occasional interactive component.

Laravel can do all of that. But it brings a lot along for the ride.

The moment Astro clicked

I didn’t go into Astro planning a rewrite. I was curious. I’d seen enough people talking about its performance model to want to understand it properly. Astro’s core idea is straightforward: ship HTML by default, and only hydrate JavaScript where you explicitly ask for it (Astro calls this islands architecture). That sounds obvious. It turns out it’s powerful.

Most pages on my site now ship effectively zero JavaScript. Not “small bundles”. Not “optimised bundles”. Just none. When you’re used to React-based stacks, that feels almost suspicious.

Performance gains that weren’t subtle

The difference wasn’t theoretical.

Static Astro pages typically ship:

• No framework runtime
• No client-side router
• No hydration unless you opt in

That usually shows up as:

• Near-zero JavaScript payloads for content pages
• Consistently high Lighthouse performance scores
• Faster initial loads

Serving the site via Cloudflare Pages means the HTML is deployed to Cloudflare’s global network, close to the user, with no application server involved. There’s nothing to warm up, nothing to queue, nothing to scale. The site feels instant because, for the most part, it is.

Maintenance: fewer moving parts, less cognitive load

This is where the decision really paid off. In Laravel, even a simple content change meant:

• Application structure
• Frontend components
• Build tooling
• Keeping PHP, Node, and dependencies in sync

None of this is hard, but it adds friction.

With Astro:

• Content lives in Markdown
• Structure is obvious
• The build output is static files

There’s no database to migrate, no runtime state to consider, and no backend to break. Editing content feels like editing content, not modifying an application. That distinction matters more than it sounds.

Hosting and cost differences

Previously, the site lived on a VPS provisioned via Forge. That’s a perfectly reasonable setup, but it comes with ongoing cost and responsibility:

• Monthly server costs
• Forge subscription
• Security updates
• Runtime monitoring

The Astro version is hosted on Cloudflare Pages.

The cost is effectively zero for a static site: requests to static assets on Pages are free and unlimited (Cloudflare Pages pricing). Deploys are automatic. Edge caching is built in.

For a simple site, that reduction in operational overhead is hard to argue against.

This is not an anti-Laravel post

It’s worth being explicit about this: Laravel is still the right tool for backend-heavy web applications. It excels at business logic, data modelling, integrations, and long-lived systems. That’s exactly what I use it for with clients.

Astro isn’t a replacement for Laravel. It’s a better fit for content-driven websites. The mistake wasn’t choosing Laravel. The mistake was assuming the same tool should be used everywhere.

Practical checklist

Before choosing a stack for a site, I now ask:

• Is this primarily content or behaviour?
• How much JavaScript does the user really need?
• What is the long-term maintenance cost?
• Can this be static without awkward workarounds?

If most answers point to “content”, Astro is hard to beat.

Final thoughts

Rewriting my site wasn’t about chasing a new framework. It was about recognising that I’d solved a simple problem with a complex tool because it felt comfortable. Laravel remains central to my work. Astro happens to be better for this job. Choosing the right tool isn’t about loyalty. It’s about judgement.