Why we're choosing Astro for content-driven websites

Astro is a web framework built around delivering content as HTML and adding browser-side JavaScript where it is needed. We're choosing it as a leading option for future content-driven websites because that starting point suits the work many businesses actually need: clear pages, distinctive design, useful content and interactions that earn their place. It is a technical preference, not a promise that every project should use the same stack.

A framework is not a substitute for strategy, design or good writing. It does, however, shape what a site sends to a visitor's device, how content gets updated and how much maintenance it needs. Those decisions are part of the design brief, even when the client never sees a line of code.

A content-first starting point

A typical business website is not a complex web application on every page. Visitors want to understand the offer, compare services, inspect past work and get in touch. Astro can pre-render those pages into HTML at build time, while also supporting server rendering when a page needs data at request time. That gives us a useful choice instead of treating every screen as an application by default.

This matters particularly for a studio, consultancy, publisher or service business whose content has to be easy to find and read. A well-structured page can arrive with its main text and links already present in the HTML. We still need to design accessible navigation, use meaningful headings and maintain the content. Astro simply provides a foundation that supports that work.

Interactivity without making everything interactive

Astro's islands architecture lets us choose which components need to run JavaScript in the browser. A pricing calculator, animated product demonstration or interactive filter can behave like an application without forcing the surrounding article, service copy and footer to carry the same client-side workload. Static content stays static, and interactive components can be loaded according to when they are needed.

That is especially interesting to us because we care about motion and visual storytelling. Animation is not automatically lightweight, and Astro cannot fix an oversized video or an expensive animation script. But being selective about where JavaScript runs gives us a cleaner starting point for creating expressive pages while protecting the reading and navigation experience.

Performance is a design decision

A slow site can make a strong brand feel careless. A page that shifts while someone reads, waits too long before responding or loads its main image late creates friction at exactly the moment a potential customer is forming an impression. We want to make sensible performance choices early, from image formats and typography to component behaviour and hosting.

Astro's approach can reduce unnecessary JavaScript, but the result still depends on what we build. We'll measure actual pages rather than promise a particular Lighthouse score before a project exists. Google uses Core Web Vitals in its ranking systems, although strong metrics alone do not guarantee search rankings. Performance is worth pursuing primarily because people benefit from it.

Your content should not depend on your developer

A custom-coded website does not have to mean emailing a developer whenever a headline changes. Astro can get content from a headless CMS, including Sanity, so editors can work with structured articles, case studies and service information in an interface made for content. The exact editing experience depends on how the CMS and preview workflow are configured, so that needs to be planned as part of the project.

There is a trade-off worth stating clearly: when an Astro site is fully pre-rendered, a published CMS change may need a new build and deployment before visitors see it. A server-rendered route can behave differently. Neither model is universally better; we choose based on how frequently the content changes, who needs to edit it and what ongoing infrastructure makes sense.

When we'd choose something else

If the main experience is a highly interactive application with complex shared client state, we would evaluate an application-focused framework instead. If a client needs an all-in-one visual builder they can personally reshape every day, an established website platform may be the more practical purchase. The right answer includes the team's skills, handover expectations, budget and the features likely to arrive next.

Our existing studio website was built with Next.js, as documented in its case study. Astro is part of the direction we're exploring for future client builds, not a retroactive description of that project. Good design work is not loyalty to a particular framework; it is the ability to choose an appropriate foundation and explain what that choice means to the client.

What this means for your website

If you're planning a service site, portfolio, editorial platform or marketing website, Astro deserves a place in the conversation. We would start with your audience, content, editing needs and conversion goals, then decide whether Astro makes those things easier to deliver. If you're exploring a new website, tell us what it needs to do. The stack can follow the brief, not the other way around.