Most marketing sites ship a framework runtime to render text that never changes. Astro does not. Pages are HTML at build time, and interactive parts are opted in one component at a time.
The sites this suits
Company sites, documentation, resource libraries, campaign microsites, blogs with a real publishing rhythm. Anything where the content team changes copy far more often than an engineer changes behaviour.
What that buys
- A first paint that does not wait for a bundle to parse
- Hosting that is a static file server, not a fleet to patch
- Search engines reading finished HTML instead of executing an app
- A Lighthouse score that stays where it started, because there is no runtime to regress
Islands, used sparingly
An interactive island is a real cost: it ships its own JavaScript. So a search box, a filter or a booking widget becomes an island, and a testimonial slider usually becomes CSS instead. We argue that case per component rather than importing a framework across the whole page for the sake of two effects.
Content the editors own
Content lives in files or a headless CMS with a schema, so a missing description or a broken link fails the build instead of reaching production. Nothing is stored in a page template where only a developer can change it.
When we would not use it
If the product is an application with sessions, dashboards and per-user data on every screen, Astro is the wrong shape and Next.js is the right one. The two decisions are made from the same question — how much of this page is different per person — and we answer it before a line is written.
See how this fits the rest of the stack or read what we do on web development.