A marketing site has one job: load fast, read clearly, and get out of the way. Most of the stacks teams reach for were built for applications (dashboards, feeds, things that change while you look at them), and a marketing site is not that. When we sat down to pick a default for content and marketing sites, Astro for marketing sites kept winning, not because it is fashionable, but because its defaults match what these sites actually are: mostly static content that should ship almost no JavaScript.
This is a practitioner’s argument, not a benchmark contest. We build on Astro because it makes the fast, correct thing the easy thing, and because the places it does not fit are honest and easy to spot.
What a marketing site really needs
Strip a marketing site to its essentials and you get text, images, a handful of interactive bits, and a content model someone non-technical has to maintain. The rendering is overwhelmingly static. The interactivity is local (a menu, a tabbed feature block, a contact form), not a live application state spanning the whole page.
The mismatch most teams hit is reaching for an application framework to build a brochure. You end up shipping a client-side router, a hydration runtime, and a bundle that re-renders the entire page in the browser to display words that never change. The visitor pays for that in load time. The business pays for it in conversions, which is the through-line of the real cost of a slow website.
The fastest JavaScript is the JavaScript you never send. A marketing site’s default should be no script at all, with exceptions you opt into on purpose.
Astro starts from that premise. It renders your pages to HTML at build time and ships zero JavaScript unless you explicitly ask for some. That single default (opt-in interactivity instead of opt-out) is the reason most of the performance work happens for free.
Islands architecture, in plain terms
The idea Astro is best known for is islands architecture. Picture a page as a sea of static HTML with small islands of interactivity floating in it. The menu is an island. The image carousel is an island. The rest (the headline, the copy, the footer) is plain HTML that needs no runtime at all.
Each island hydrates independently. The carousel can load and become interactive without dragging the entire page’s JavaScript along with it. And the static ocean between the islands ships as HTML, full stop.
Why this beats the all-or-nothing model
Most application frameworks hydrate the whole page: to make one button work, the browser downloads and re-executes the logic for the entire tree. Islands break that bargain. You pay for interactivity only where you place it, in proportion to how much you place.
For a marketing site that is exactly the right shape, because interactivity is the exception. A few concrete wins:
- Smaller bundles by default. A page with two interactive components ships two small islands, not one large application.
- Faster time-to-interactive. There is less to parse and execute, so the page is usable sooner.
- Graceful failure. If an island’s script is slow or fails, the static content around it still renders and reads.
Control how each island loads
Astro lets you declare when an island hydrates with client directives. client:load hydrates immediately; client:idle waits until the browser is free; client:visible waits until the component scrolls into view. A below-the-fold testimonial slider can use client:visible and cost the initial load nothing.
That control is the difference between “we ship some JavaScript” and “we ship the right JavaScript at the right moment.” It is also one of the levers we reach for first when tuning Core Web Vitals, because deferring an island is often the cheapest LCP and INP win available.
Zero-JS by default is the real headline
Islands get the attention, but the quieter feature matters more: by default, an Astro component renders to HTML and ships no JavaScript. You write components in a familiar, JSX-like syntax, and the output is static markup. You only cross into client-side code when you mark a component as an island.
This inverts the usual incentive. In an application framework, shipping JavaScript is the path of least resistance and not shipping it takes discipline. In Astro, the path of least resistance is a fast static page, and adding runtime cost is the deliberate act. Defaults decide outcomes, and this default points at performance.
It also means you can bring components from React, Vue, Svelte, or Solid and render them as static HTML, using libraries your team already knows without paying their runtime cost on every page. When you do need interactivity, that same component becomes an island. One mental model, two output modes.
Content collections: structure your content like data
A marketing site is a content site, and content needs a model. Astro’s content collections give you typed, schema-validated content (Markdown, MDX, or data files) that you query like a small local database. You define a schema for, say, blog posts or case studies, and Astro validates every entry against it at build time.
The payoff is the kind of safety that prevents 2am incidents:
- Type safety. A typo in a frontmatter field or a missing
pubDatefails the build, not production. - A real authoring contract. The schema tells writers exactly what a page needs, so entries ship complete instead of half-filled.
- Queryable content. Listing pages, tag filters, and related-post blocks read from the collection instead of from hand-maintained lists that rot.
This is the same content-modeling discipline we apply at the architecture stage in website information architecture, just expressed in code. The model you sketch for the IA becomes the schema that backs the build, and the two stay in agreement.
For sites where non-technical editors need a friendlier surface than Markdown files, Astro pairs cleanly with a headless CMS; collections can source from an API instead of the filesystem. If that is your situation, weigh the options the way we lay out in choosing a headless CMS without regret before committing.
The developer experience earns its keep
DX is not vanity. The faster a senior team can ship correct work, the more of the budget goes into the work itself instead of into fighting the toolchain. Astro is pleasant in the ways that compound.
- One file format, few surprises.
.astrocomponents are HTML with a typed script section. There is little ceremony and almost no magic to debug. - Fast builds and a quick dev loop. Static output means the build is predictable and the local feedback loop is tight.
- Sensible escape hatches. Need a server-rendered route, an API endpoint, or edge rendering? Astro supports those rendering modes without forcing the whole site into them. Picking the right one per route is the subject of static, server, or edge rendering strategies explained.
The deeper benefit is that Astro keeps the simple thing simple. A page that is just content stays a file of content. You are not wiring providers and routers to publish a paragraph.
The trade-offs, said plainly
No tool is free, and pretending otherwise is how teams end up fighting their stack a year in. Astro has real edges.
When Astro is the wrong choice
If you are building a highly interactive application (a live dashboard, a collaborative editor, a feed that updates constantly, anything where most of the screen is dynamic state), islands stop being an advantage. When nearly everything is an island, you have re-implemented an application framework the hard way. Reach for a framework built for that shape instead.
Astro also shines brightest on content-led sites. The more your value lives in stateful, app-like flows behind a login, the less Astro’s static-first defaults buy you. Marketing site, docs, blog, campaign microsite, brochure-plus-a-few-tools: yes. SaaS product surface: usually no.
Smaller costs to budget for
- Hydration boundaries take thought. Islands don’t share state by default. If two interactive components need to talk, you design that on purpose. It is not free the way it is in a single-tree app.
- A learning curve for the mental model. Teams steeped in client-side frameworks have to unlearn “everything hydrates.” That adjustment is short, but it is real.
- Ecosystem maturity in spots. It is excellent and growing, but for a niche integration you may occasionally do more wiring than a larger ecosystem would require.
Choose the tool that fits the shape of the thing you are building. Astro fits content sites the way an application framework fits applications, and mixing them up is the actual mistake, not the tool.
How Strynal builds with Astro
We default to Astro for marketing and content sites because its grain runs the same direction as the work: fast static output, interactivity only where it earns its place, and a content model the whole team can trust. None of that is theoretical. It is the difference between a site that scores well on launch day and one that holds its performance budget as content accumulates. That durability is the point of our websites and apps work.
Because the team that scopes the work is the team that builds it, the rendering decisions get made with the design and the content, not bolted on afterward. Every engagement starts on a blank page, with no template and no recycled stack chosen for the last client, so the architecture fits the site you actually have. As the in-house studio for Global Digital Platforms, we have shipped enough of these to know where the fast path is and where the edges are.
If your current site loads slower than it should and you are not sure whether the fix is the stack, the structure, or both, that is a good first conversation to have. Walk us through what feels slow, and we will tell you honestly whether Astro is the right move, or whether the problem lives somewhere the framework can’t reach.