Astro

Astro's central idea is that a page is HTML unless it says otherwise. Components render on the server or at build time. An interactive component opts in to the browser with a directive that also says when it should load, and the rest of the page never ships a runtime. Astro calls these interactive pieces islands.

Content comes from wherever it lives: Markdown files in the repository, a headless CMS, or both. Pages can be built ahead of time or rendered on request, route by route, so one site can hold static articles beside a few pages that need live data.

Why it matters for a marketing site

A marketing page is mostly content, and most frameworks still ship a large runtime to display it. Astro starts from HTML and adds script only where a component asks for it. Pages stay light by default, and speed does not depend on someone policing every new script. The whole site also becomes code that any developer or coding agent can read and change.

How I handle it

Astro is one of the two frameworks I build in. The Everbase Stack is Astro or Next.js, with Sanity, on Cloudflare or Vercel, in accounts your organization owns. Astro suits sites where every visitor sees the same pages. When a site is data-driven or behaves like an app, such as logged-in views or heavy per-visitor rendering, I build in Next.js instead.

Example

Say a homepage has nine sections and one interactive pricing calculator. Eight sections ship as plain HTML and CSS. The calculator loads its own script, and only that script. A reader who never scrolls that far still downloads it unless it is set to load when visible, which Astro also lets you choose per component.

Common mistakes

• Rebuilding the old site's runtime. Adding a client-side component for every section hands back the weight Astro saved.
• Assuming it comes with an editor. Astro renders pages and has no editing interface. Editors need a CMS such as Sanity.
• Choosing it for an app. Dashboards and logged-in products usually fit an app framework better.