Why build with Astro?
We built this site with Astro. Most of its pages are content people come to read, with a few interactive pieces like search, project previews, and the animations we’ve had some fun with.
Astro suits that mix. It renders HTML first and doesn’t send browser-side JavaScript for an Astro component by default. We can add interaction where we need it without making every page load an application framework.
Visitors probably won’t care which tool we chose. They will care if the page takes too long to load or a link doesn’t work. Sending less code gives us a good start, especially on slower phones and connections.
What is Astro?
Astro is a tool developers use to build websites. It brings the pages, content, images, styles, and interactive features together, then produces a finished site that browsers can load efficiently. You do not need to know Astro—or install anything—to visit an Astro website. To a visitor, it simply feels like a website that loads quickly and works as expected.
Astro is different from a content management system such as WordPress. WordPress usually gives site owners a built-in dashboard where they can write pages, upload media, manage users, and install plugins. Astro does not include that kind of editing dashboard or require its own database. Content can live directly with the website, or Astro can connect to WordPress, Drupal, Shopify, or another content system when editors need those tools. In that arrangement, the CMS manages the content and Astro presents it to visitors.
Astro is also more than a folder of hand-written static HTML files. Traditional static HTML can be very fast, but updating navigation across dozens of individual files or creating hundreds of consistent pages by hand becomes difficult. Astro lets developers create reusable layouts and components, organize structured content, and generate all of those finished pages together. The result can retain the speed and reliability of static HTML without requiring every page to be maintained separately.
That makes Astro a flexible middle ground: it can power a straightforward small-business website without the maintenance of a full CMS, or serve as the fast front end for a larger content or commerce platform. We choose the setup based on who needs to publish, how often the content changes, and which features the organization actually needs.
Astro describes itself as a framework for content-driven websites and documents five core ideas: content-driven, server-first, fast by default, easy to use, and developer-focused. Its official overview is a useful starting point.
Ship HTML before shipping an application
Many websites need a few interactive features, but they do not need every heading, paragraph, image, and navigation link to be reconstructed by JavaScript in the visitor’s browser.
An Astro component renders to HTML at build time or on the server. Its frontmatter can load content, shape data, and prepare component properties without becoming part of the browser bundle. A simple feature card can remain exactly that:
---
interface Props {
title: string;
description: string;
href: string;
}
const { title, description, href } = Astro.props;
---
<article class="feature-card">
<h2>{title}</h2>
<p>{description}</p>
<a href={href}>Learn more</a>
</article>There is no hydration instruction here, so the finished component adds no client-side framework runtime. The browser receives the markup and CSS it needs.
Add interactivity as an island
Some parts of a page really do need to run in the browser: a product configurator, a searchable directory, an account control, or a complex data visualization. Astro’s islands architecture lets those features become focused interactive components inside an otherwise static page.
---
import ProjectEstimator from "../components/ProjectEstimator.tsx";
---
<h1>Plan your next website</h1>
<p>This introduction remains static HTML.</p>
<ProjectEstimator client:visible />The client:visible directive waits until the estimator approaches the viewport before loading its browser code. Other components can load immediately, during idle time, or only for a particular media query. That control helps us match the cost of an interaction to its actual value.
Astro can use components from React, Preact, Svelte, Vue, Solid, and other supported UI systems. That makes it possible to preserve a proven interactive component without adopting its framework for every part of the website.
Pre-render what can be static
Astro pre-renders pages as static HTML by default. Static pages can be served efficiently, cached broadly, and displayed without waiting for a database or application server on every visit.
Static does not mean manually maintained. A build can pull approved content from Markdown, a headless CMS, a commerce platform, or another API and generate the finished pages. When editors publish, an automated build can create a new static version.
Some projects also need personalized or frequently changing routes. Astro supports on-demand rendering for those pages, while the rest of the site can remain pre-rendered. We choose that boundary deliberately instead of giving every request a server dependency by default.
Give content a reliable structure
Astro content collections can validate local Markdown, MDX, JSON, YAML, or other loaded content against a schema. That catches missing titles, invalid dates, and inconsistent fields during development or the build rather than after a broken card reaches production.
import { defineCollection, z } from "astro:content";
import { glob } from "astro/loaders";
const articles = defineCollection({
loader: glob({ pattern: "**/*.md", base: "./src/content/articles" }),
schema: z.object({
title: z.string(),
description: z.string(),
publishDate: z.coerce.date(),
draft: z.boolean().default(true),
}),
});
export const collections = { articles };This structure is useful for articles, case studies, team profiles, services, documentation, and other repeatable content. It gives editors and developers a clear contract without requiring a runtime database for every project.
Connect the right content system
Astro is not a replacement for every CMS or commerce platform. It can be the presentation layer in front of an existing system when that separation makes sense.
A team might keep Drupal for complex structured content and workflows, WordPress for a familiar editorial experience, or Shopify for products, inventory, checkout, and orders. Astro can consume the content or catalog APIs and produce a focused front end. The value is not “headless” as a slogan; it is choosing a boundary that improves the visitor experience without making publishing, previews, deployment, or recovery harder for the people operating the site.
For a smaller business site, a local Astro content collection may be simpler and more durable than adding a separate CMS. For a large organization, existing governance and integrations may make the CMS essential. We design around the real editorial and operational needs rather than forcing the same architecture onto every project.
Performance still requires decisions
Astro makes it easier to send less JavaScript, but a framework cannot prevent every slow site. Oversized images, too many font files, third-party trackers, unbounded API calls, and carelessly hydrated components can still erase the advantage.
Our performance work includes:
- Establishing a page-weight and request budget before features accumulate.
- Optimizing responsive images and reserving their layout space.
- Hosting essential assets locally when licensing permits.
- Loading scripts only on the pages and components that need them.
- Testing production builds rather than judging the development server.
- Checking keyboard access, reduced-motion behavior, and slower mobile conditions.
- Measuring again after analytics, consent tools, chat widgets, or other third-party features are proposed.
The goal is not a perfect score detached from the business. It is a site that feels immediate, remains accessible, supports search and discovery, and stays maintainable as content and features grow.
Where Astro fits—and where it may not
Astro is especially strong for content-rich websites, marketing experiences, publications, documentation, portfolios, and front ends where most of the page can be HTML and selective areas need richer interaction.
It is not automatically the best foundation for a browser application in which nearly every screen is highly stateful and interactive. A mature Drupal, WordPress, or Shopify theme may also be the better choice when a separate frontend build would add operational complexity without delivering a meaningful benefit.
The important question is not whether Astro is newer or faster in the abstract. It is whether its server-first rendering, static output, content tools, and selective interactivity fit the website your team needs to run.
For the right project, that fit is excellent: start with durable HTML, add only the browser code the experience requires, and keep the path from content to visitor as short as possible.