All articles

// 4 August 2026 · by James Willcocks

Why almost every site I build runs on Astro

People ask what I "make websites in." The answer is a framework called Astro. New, fast, and a little contrarian. Here's what it actually is, why it's the right tool for a service business's website, the kind of site it's the wrong tool for, and the one real trade-off it asks you to make.

  • · astro
  • · javascript
  • · performance
  • · business
Vintage engraving of an antique brass orrery (a mechanical model of the solar system), one planet on its arm picked out in terracotta

People ask what I “make websites in,” the way you might ask a builder what they build with. For years my answer was WordPress. For almost everything now, it’s a framework called Astro. The name draws a blank with most business owners, because it’s new and it isn’t the thing everyone else is using.

This isn’t the piece about why I moved off WordPress. I’ve written that one already, and it’s mostly about plugins, security and maintenance. This is the other half of the answer: what Astro actually is, why it’s the right tool for the kind of website most businesses need, the kind of site it would be a bad choice for, and the one real trade-off it asks you to accept.

What Astro actually is

Astro is a web framework, the software a developer uses to build and assemble a site. Its defining idea is almost contrarian: it ships zero JavaScript to the browser by default.

To unpack that. Most websites are delivered as one of two things. Either the server sends a finished page (plain HTML, ready to display) or it sends a bundle of JavaScript that the visitor’s phone then has to run to build the page after it arrives. Astro takes the first road, hard. It renders your pages to static HTML when the site is built, and the visitor is handed the finished article. Where a page needs something interactive, a menu that opens or a carousel that swipes, Astro adds a small, self-contained “island” of JavaScript for just that piece and leaves everything around it as static HTML. That pattern is called islands architecture, and Astro is the framework that popularised it.

The result is a website that is, for the most part, just HTML and CSS, the way the fastest-loading pages on the web have always been.

The framework nearly everyone else uses is React

To see why “zero JavaScript by default” is an unusual stance, you have to know what it’s standing against. A large slice of the modern web is built with JavaScript UI frameworks: React, Vue, Angular, Svelte and a few others. React, built and open-sourced by Facebook (now Meta), is the runaway leader: in Stack Overflow’s 2025 developer survey it was used by nearly half of professional developers, far ahead of the rest.

Share of professional developers using each front-end framework React around 47 percent, Angular 18 percent, Vue 18 percent, Svelte 7 percent, in Stack Overflow's 2025 developer survey. FRONT-END FRAMEWORKS, SHARE OF PROFESSIONAL DEVELOPERS React 47% Angular 18% Vue 18% Svelte 7% Astro isn't on this chart. It ships none of this by default, and can embed any of them in an island when a page truly needs it. Source: Stack Overflow Developer Survey, 2025.

Here’s the thing that trips people up: Astro isn’t really “versus” React. It sits at a different layer. You can run React (or Vue, or Svelte) inside an Astro island if a particular feature calls for it. The difference is the default. React-first frameworks send the JavaScript and build the page on the visitor’s device; Astro sends the finished page and only reaches for that machinery in the specific spots that earn it.

Where React is the right call, and Astro isn’t

I want to be fair to React, because it exists for very good reasons and it’s superb at what it’s for.

Facebook is the canonical example. It isn’t really a “website” in the brochure sense. It’s a vast piece of software that happens to run in a browser: a feed updating in real time, notifications, chat, infinite scroll, every screen different for every logged-in user, state changing by the second. You can’t pre-build that as static HTML, because there’s no static version of it. It has to be assembled live, per person, in the browser. That’s exactly the job React was invented for.

So if you’re building a web app (something behind a login, a dashboard, a booking system with live availability, a tool people operate rather than read) then React, Vue or Svelte is the right family, and I’ll tell you so plainly. Astro can do logins and dynamic pages, but at that point it’s swimming against its own current, and one of the app-first frameworks will serve you better. It’s a case of the right tool for the job, and pretending one tool wins every job is how people end up with the wrong one.

The quiet truth the industry doesn’t dwell on, though, is that most websites aren’t web apps. They just get built with app-grade tools anyway, hauling a React-sized engine to deliver what is, in the end, a set of pages that inform and persuade.

Why it’s right for the sites I build

The sites I build, for trades, studios, clinics, shops and service businesses, are content. Pages that tell people who you are and what you do, earn their trust, and hand off to a phone call or a form. They don’t need to rebuild themselves in the browser. They need to load instantly, rank well, and look right. That’s precisely Astro’s home ground, and it means a few things are simply handled:

  • Speed. Static HTML served from a CDN edge is about as fast as the web gets, and on a patchy connection that’s the difference between a customer and a bounce, not a vanity score.
  • SEO done right the first time. Clean semantic HTML, correct metadata, sitemaps, structured data, a unique title and description on every page, built into how the site is assembled, not bolted on afterwards. On WordPress I was forever wrestling a plugin to give each page the SEO structure it should have had by default. With Astro it’s the default.
  • Nothing to hack, nothing to patch. The whole security-and-maintenance argument from the other article: a static site has almost no attack surface and no monthly plugin treadmill.

The bits nobody sees: images and share previews

Two unglamorous examples of “handled by default,” because they matter far more than they sound.

Images. How a site deals with images is most of its weight, and most of its speed. Astro processes every image at build time: it takes your original, generates modern formats like WebP at several sizes, and hands each visitor’s browser exactly the right one for their screen, never a byte more than needed. It’s all computed once, when the site is built, then served as plain static files. Compare that to WordPress, which on every upload generates a fistful of resized copies and stores them all on your server; decide later to change your image sizes and you’re regenerating thousands of files with (you guessed it) another plugin. Same goal, two very different amounts of cruft.

Share previews. When you paste a link into WhatsApp, LinkedIn or a text, the little preview card with an image is the “Open Graph image.” Most small-business sites either have none (the sad grey box) or one generic image reused across the whole site. Astro lets me generate a proper, on-brand preview image for every single page automatically. (The one for this very article was made that way, at build.) Tiny things. But tiny things are the entire difference between a site that looks looked-after and one that doesn’t.

None of this is me being clever on your behalf. It’s Astro giving me the control to do the boring things correctly, once, everywhere, instead of fighting for them page by page.

The one real trade-off: it isn’t a CMS

Now the cost, because every choice has one and this is Astro’s.

A site that’s just fast static files has no admin panel. Clients can’t log in and edit their own website. Changes come through me. And I won’t pretend that’s nothing. On a cold email especially, “here’s a new website for your business; if you want to change anything, you come to me” can sound like I’m keeping you on a leash. I understand the reaction completely. So here’s the case for it, without the gloss.

First, what self-editing is actually like. I’ve handed over WordPress sites, checked back a few days later, and found a wall of new text, deleted sections, and a genuine mess (made, happily, by an owner who was well within their rights to do it). That’s fine. But editing a website well is a real skill, it had taken them hours, and most business owners are far better off spending those hours on the thing they’re actually good at.

Second, the maths, because this is really the plumber calculation. A text change that takes me a few minutes can eat two or three hours of a business owner’s evening. Freelance developers in the UK charge £30–£80 an hour precisely because the fiddly work is slow if you don’t do it every day. Value your own time at anything near what you charge your own clients, and “free” edits stop being free. And mine already are: my hosting includes up to an hour of changes a month, so doing it yourself doesn’t even save you the fee. It just costs you the evening.

Third, the part that surprised me. Not fighting WordPress has made me dramatically faster, and that speed is yours, not just mine. A new page is thirty minutes, not an afternoon. A text tweak is a couple of minutes. A new blog post, a changed date, a fresh section: quick. Changes people expect to wait days for take an hour. The thing that looks, from the outside, like a loss of control is what lets me build and change things at a speed a self-serve site never matches.

And yes, there’s a trust element in there, and I’d rather name it than pretend it away. You’re trusting me to be around and to be responsive. That’s a fair thing to weigh, and you should. But what you’re buying with it is a site that’s faster, safer, better-built and looked after by the person who built it, instead of a site you technically control and privately dread touching.

The right tool

Astro is new: only a few years old, and Cloudflare thought enough of it to acquire the project in early 2026. That newness is exactly why most people haven’t heard of it, and also why the sites built on it feel a step ahead.

But “new” isn’t the argument. The argument is fit. For a Facebook (logged-in, live, app-shaped) Astro would be the wrong tool, and I’d reach for React without hesitation. For the kind of website the overwhelming majority of businesses actually need (content, done beautifully, loading instantly, findable, and cheap to run) it is, right now, the best tool going. Knowing which is which is most of the job.

// thanks for reading

If something here was useful, or wrong, I'd like to hear about it. Email Email us.

// next step

Got a project? Let's talk.

A free chat about what you need and whether I can help. If it isn't a fit, that's the end of it: no sales follow-up.