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>This component doesn’t need to run JavaScript in the browser. Astro renders it as HTML, and the browser displays it with CSS. That means visitors don’t have to download a JavaScript framework just to see this content.
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.
How a static frontend can improve security
A static HTML frontend can be a secure way to publish content from a CMS. Editors still work in Drupal, WordPress, or another content system, but a build retrieves the approved content and generates finished pages. Visitors receive those pages from the web server or a content delivery network; each page view does not need to reach the CMS or its database.
That separation can reduce what the public website exposes. For example, the CMS administration area and content API can be kept on a private network or behind restricted access, rather than leaving a CMS sign-in page open to everyone. The CMS can also run offline, with no public internet access: staff update the content, Astro builds the updated content, and the team tests it locally before publishing the finished files.
Astro also provides useful tools that help developers protect that boundary:
- Keep the public website simpler: Astro makes it practical to publish finished HTML pages while adding interactive features only where needed. For a CMS-backed website, that can mean fewer live systems exposed to visitors and fewer browser dependencies to maintain. Your organization can retain its editorial tools while reducing the complexity of the public frontend. Astro’s islands architecture supports this approach by letting developers make individual parts of a page interactive—such as a search tool or product configurator—while the surrounding content remains finished HTML.
- Add live features without making every page depend on a live application: Your website may need an account area or other features that respond to individual visitors. Astro’s on-demand rendering lets developers build those features into selected pages while keeping articles, services, and other public content static. That gives your team a smaller set of live routes to secure and monitor as the site grows.
- What happens if unwanted code does reach the front-end? Astro includes built-in support for generating an optional Content Security Policy, which can limit what live code is able to do. Developers can set rules for which scripts and styles a visitor’s browser is allowed to run or apply. When configured appropriately, those rules can block unauthorized code from running, helping protect visitors and limit the impact if another security measure fails.
For pages rendered on demand, Astro also checks the origin of certain form-like requests by default to help prevent cross-site request forgery. This applies to Astro’s on-demand routes, not to static files or separate CMS and API endpoints, which need their own protections.
The CMS, its plugins, the build system, and hosting still need updates and careful configuration. Limit access to the CMS and build credentials, use only the permissions each connection needs, and keep secrets and unpublished content out of the generated files. Review what goes into public pages, protect administrator accounts, and make sure the team can rebuild and recover the site. OWASP’s guidance on protecting administrative tools and secure defaults covers these boundaries.
A static frontend can reduce the number of moving parts exposed to visitors, but it is not a security guarantee. The right design depends on the CMS, the information being published, and the interactive features the site needs.
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.