All writing

// 4 August 2026

Why almost every site I build runs on Astro

People ask what I "make websites in." The honest answer is a framework called Astro — new, fast, and a little contrarian. Here is 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 is a framework called Astro — and the name draws a blank with most business owners, because it is genuinely new and it is not the thing everyone else is using.

This is not the piece about why I moved off WordPress — I have written that one already, and it is mostly about plugins, security and maintenance. This is the other half of the answer: what Astro actually is, why it is 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 honest 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 genuinely needs something interactive — a menu that opens, 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 is 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 is the thing that trips people up: Astro is not 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 is superb at what it is for.

Facebook is the canonical example. It is not really a “website” in the brochure sense — it is 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 cannot pre-build that as static HTML, because there is no static version of it — it has to be assembled live, per person, in the browser. That is exactly the job React was invented for.

So if you are 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 will tell you so plainly. Astro can do logins and dynamic pages, but at that point it is swimming against its own current, and one of the app-first frameworks will serve you better. It is genuinely 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 are not 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, 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 do not need to rebuild themselves in the browser. They need to load instantly, rank well, and look right. That is 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 is 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 is 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 is 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 are 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 is 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 honest part, because every choice has a cost and this is Astro’s.

A site that is just fast static files has no admin panel. Clients cannot log in and edit their own website. Changes come through me. And I will not pretend that is nothing — on a cold email especially, “here is a new website for your business; if you want to change anything, you come to me” can sound like I am keeping you on a leash. I understand the reaction completely. So let me make the honest case rather than gloss over it.

First, what self-editing is actually like. I have 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 is 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 are actually good at.

Second, the maths — because this is really the plumber calculation. A text change that takes me half an hour — half my hourly rate, so about £27 — 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. Yes, you could do it yourself and save the call-out — right up until you count your hours.

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. Turnaround people brace themselves for takes days takes 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 is a trust element in there, and I would rather name it than pretend it away. You are trusting me to be around and to be responsive. That is a fair thing to weigh, and you should. But what you are buying with it is a site that is 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 james@willcocks.uk.

// next step

Got a project? Let's talk.

A free call to talk through what you need and whether I can help. No follow-up sales pressure if it isn’t a fit.