Astro pros and cons: when it’s worth using

Anyone who's sold websites without maintenance knows how often you tell clients you'll set them up with a super-easy CMS that lets them make big or small changes effortlessly.

The client loves the idea in the proposal, but once you've set it up, they change nothing for months. And on the rare occasion they want a change, they email you to do it.

Fair enough: they're focused on their business, and all they want from their website is customers. Nothing wrong with that.

Having seen this so often, I've always thought that WordPress is great, especially for developers, because it requires maintenance that shouldn't always be necessary.. 

So I figured there had to be alternatives. Other approaches I hadn't found until now.

Because with pure HTML sites, even the smallest change, like updating the customer-service phone number, takes ages. And often you need complex features that, in principle, require a server-side language.

And yes, PHP is an option, with its includes and all its possibilities. But development becomes much more complicated than with WordPress. Not to mention needing hosting with the language installed and having to keep it updated.

But very recently I discovered Astro. And everything clicked.

Astro's philosophy: HTML first, JavaScript only when needed

If you're new to the tool, start by understanding what Astro is and how it works, especially the technical side. Here we'll focus on the practical consequences of its architecture..

Its approach is to deliver content as HTML and reserve browser-side code for the parts that need it. Of course, besides static generation, it also supports on-demand rendering.

Let's see what that means.

Astro's advantages

Before we start, it's important to clarify that some advantages are universal, while others only apply to certain types of websites.

Here's the rundown.

Performance built into the architecture

For a service page, serving a prepared document avoids work during the visit. You don't need a server to build the content because it hasn't changed; simply returning a stored HTML file is enough.

That provides an excellent starting point for (very) fast loading. Especially with properly optimized images (hello webp), optimized CSS and efficient file delivery.

The advantage is that you start with a lightweight structure and then deliberately add only what you really need..

Very little JavaScript in the browser

Astro tries to avoid all unnecessary JavaScript, because saving JavaScript cuts download size and the work the device has to do. On a PC that's usually fine, but on a phone, especially a cheaper one, it's a bigger deal: it has to parse and run everything it receives while doing everything else.

On an informational website, sending loads of logic that barely adds any functionality for visitors is an unnecessary waste of resources.

Astro, on the other hand, makes it easier to integrate the small interactive tools you actually need. You keep the advantage as long as you're careful about what you add.

Clean HTML and a good starting point for SEO

Making the main content available in HTML makes it easier to access.

And it's relatively easy to follow best practices for SEO, because it lets you build a clear structure of headings, links and sections.

Smaller attack surface

This one's good if you want to avoid maintenance.

On a static site, there's no CMS or database running on the public-facing side. There are fewer exposed features to protect..

That reduces certain risks A LOT, though it doesn't make the project invulnerable. Your hosting account, GitHub repository and connected services still need protection. And if you have a form with a backend, that backend must validate input and prevent misuse. The good thing is that for some sites this is hardly ever needed.

Simple, cheap hosting

Another universal advantage.

Serving static files usually takes less infrastructure than running an app with a database and server-side language. For small projects, a static site may fit a free or inexpensive plan, depending on the provider's terms.

In fact, one huge advantage is being able to deploy a free site build on CloudFlare, so you pay nothing for hosting. Yep, that cost disappears completely.

Of course, you need to distinguish website hosting from the rest of the project:

• You'll always have to pay for the domain.
• Email can also be free..
• If you use APIs—from Meta or elsewhere—the cost depends on usage.

In short, avoiding a traditional server doesn't make the whole setup free, but it does remove the biggest expense for corporate sites.

Components without turning the whole website into an SPA

An SPA (Single Page Application) is an application in which much of the navigation and interface depends on browser code. That can make sense for certain products (such as social networks and their feeds), but a services website rarely needs it.

However, Astro lets you reuse components and shared structures where needed, without forcing the whole site to behave like an SPA. You can fix one shared block once while continuing to serve pages as regular documents.

Content flexibility

Not needing a CMS doesn't mean you can't add one to the architecture.

You can start with static files for a corporate site and connect a CMS if, say, you decide to start a blog. You can also connect to systems the business already uses and retrieve data from them.

That freedom offers different solutions for all kinds of sites.

Git integration

Because it needs only files, not a database, Astro integrates brilliantly with Git.

Keeping project history in Git makes it easier to check what changed, test it before publishing and roll back to an earlier state.

When AI writes code, this traceability is especially useful: you can review a specific change without relying on the assistant to remember what it did.

Separating the frontend from external services

Sure, HTML is great, but HTML alone can't make a form work and deliver its submissions. You need a server for that.

The good news is that with HTML, you can connect to the API of services such as Zoho Mail and have submissions sent to your chosen email address. All for free.

If you're already using this tool for business email, you don't need anything else in your stack.

Astro's main weaknesses

Now let's discuss the framework's disadvantages, which make it a poor choice for certain projects.

No ready-to-use CMS

When developing a website, the first practical question for me is: who will update or maintain it?

If the client expects to open a dashboard, replace a photo and publish, Astro alone doesn't offer that experience. You need to work with files or add an editing tool.

For clients who need to make changes without calling you, Astro isn't the best option.

More technical decisions to make

You have to decide where text lives, how changes get published, how the form is implemented and what happens if a service fails.

With a CMS like WordPress, most of that comes out of the box.

The upside of doing it with Astro, though, is that you can design the system once and reuse it across different websites.

Integrations require development

Some services make the job much easier, but you won't always find an install-and-go solution that meets all your needs, like typical CMS plugins.

For example, designing a form isn't enough. You need to connect submissions, handle errors, protect credentials and make sure messages arrive. Bookings involving schedules, payments and cancellations multiply the implementation work and therefore the decisions.

AI can speed up implementation, but you still need someone capable of reviewing the result and taking responsibility for it.

Less convenient for editorial teams

Someone who posts occasionally can work (reasonably) well with Markdown. A team with multiple authors, reviews, scheduling and constant image management needs a fuller editorial experience.

In other words, a good old-fashioned CMS.

You can put a suitable CMS on top of Astro, but the question is why you'd do that instead of just using the CMS.

Builds can get complicated on huge projects

With static generation, the pages you publish have to be built. How long that takes depends on how many there are, how data is fetched and what processing is involved.

A large catalogue with lots of images or external queries can complicate the process. There's no universal number of URLs beyond which Astro stops being useful: you need to measure the project and decide what to pre-generate and what to render on demand.

And if an urgent update depends on a build that fails, the old content stays online until the problem is fixed.

Smaller ecosystem than WordPress

Astro has integrations and templates, but not the same range of ready-made solutions for widely varying business needs.

In WordPress you can usually find several options for bookings, memberships or editorial workflows. With Astro you might have to connect services or build part of the functionality yourself. That affects development time, budget and who can maintain it later.

A learning curve for people coming from PHP or WordPress

If your usual workflow is installing a theme and configuring plugins, you'll meet new tools: packages, repositories, builds and deployments.

You don't have to master them all at once. But you do need to understand the path from the files you edit to what actually goes live. Otherwise, you can ask AI for a fix, see it locally and assume it's already on the live website.

Not every project suits a static architecture

Everything above boils down to this.

A relatively stable public page and a dashboard showing real-time personal data don't have the same requirements.

Astro can add server-side and dynamic features, but another platform may solve the overall problem better. It's not about whether Astro can do it, but whether it's worth it.

Clarifying Astro's limitations

I've touched on these throughout the article, but let me recap them here to make things clear.

No built-in CMS doesn't mean you can't use a CMS

You can add an editor and a content source. The real limitation is having to choose and integrate them, with their costs and maintenance.

No database requirement doesn't mean you can't use one

Astro doesn't require one for a simple website.

If your project needs to store users, bookings or changing information, it can connect to a database. Keys and sensitive queries must stay in a secure server environment.

Static generation doesn't mean Astro only serves static websites

You can combine strategies and services.

A prebuilt page can send a form to a backend. Public content and message processing are separate jobs.

Using JavaScript in development doesn't mean shipping all of it to the browser

What matters for loading is what the visitor receives.

Some code builds the page and never runs during a visit. Confusing those two moments leads you to misjudge the actual weight of the website.

When I'd choose Astro

Now for the important bit.

I'd consider Astro for:

• A corporate website.
• A portfolio.
• Documentation.

Provided that:

• The pages are relatively stable.
• Nobody but me will edit them.
• I want good performance.
• Low cost (no server to pay for).
• And my stack includes AI-assisted development and Git integration.

When I wouldn't choose Astro

I wouldn't use it if:

• The client needs to edit things themselves.
• The frontend needs constant changes.
• The blog will be the heart of the site.
• For a magazine.
• For an ecommerce site.
• For a membership site.

In short, whenever a CMS makes the job easier.

Conclusion: Astro isn't always better; it depends on the project

I love Astro's approach. It's something I've been looking for for ages because it lets you build many websites with static content and a structure tailored very, very closely to what they actually need.

It also works brilliantly with AI for developing almost everything.

But you have to think about the website's life after delivery too.

If the client can maintain it, the integrations are sorted and the content is a good fit, it's a very interesting option.

As you've probably guessed, the comparison I usually make for each project is Astro vs WordPress. In the linked article I explain how to decide based on the whole job, from editing and maintenance to the client's budget.