Astro Under the Hood: How It Actually Works (and Why It's Fast)

In our previous post, we covered why we left WordPress for our client builds. That post explored the security risks, performance problems, and maintenance burden that pushed us to make a change. Now it is time to explain what we moved to and how it works technically. We chose Astro as the foundational technology for all new client websites, and we are actively migrating six existing WordPress sites and several hundred-page static sites to this new standard. Astro is not just another JavaScript framework. It represents a fundamentally different approach to building content-rich websites.

Zero JavaScript by Default

Most modern frameworks ship substantial JavaScript to the browser, even for static content. React, Next.js, Nuxt, and SvelteKit all send their runtime to the client. A simple "About Us" page might download hundreds of kilobytes of framework code: hydration logic, virtual DOM diffing libraries, and state management. The browser has to download, parse, compile, and execute all of that JavaScript before the page becomes fully interactive.

Astro flips this completely. It renders everything to static HTML at build time and sends zero JavaScript to the browser by default. If you have a static page with no interactive elements, Astro generates pure HTML and CSS. The browser receives lean markup, displays it immediately, and does not have to process any JavaScript at all. No hydration, no virtual DOM, no framework overhead. The result is dramatically faster page loads and reduced bandwidth consumption, especially on slower networks or less powerful devices.

Islands Architecture

This is Astro's key innovation. Traditional frameworks use a "hydrate everything" approach: even if only a small contact form needs interactivity, the entire page's component tree gets re-rendered on the client. All the associated JavaScript downloads and executes for the full page.

Astro lets you mark specific interactive components as "islands." Think of your website as a static HTML continent with small, independent islands of JavaScript functionality. A contact form, a search widget, an image carousel, or a chat bubble can each be an island. Each island hydrates independently, loading JavaScript only for that specific component. The rest of the page (headers, navigation, content, footer) stays as zero-JavaScript HTML.

You also control when islands hydrate:

• client:load hydrates immediately on page load, for critical interactive elements.
• client:idle hydrates after the browser finishes initial rendering, prioritizing content display.
• client:visible hydrates only when the component scrolls into view, ideal for below-the-fold elements.
• client:media hydrates when a CSS media query matches, enabling responsive hydration.

A page with one interactive form only downloads JavaScript for that form. Not for the navigation, not for the footer, not for the content sections. This dramatically reduces the initial JavaScript payload.

Static and SSR: Pick Per Page

Most frameworks force a binary choice: build a purely static site or a fully server-rendered application. Astro lets you choose your rendering strategy on a per-page basis.

Service pages, about pages, and landing pages that change infrequently can be fully static. They are pre-built into HTML at deploy time, served instantly from a CDN, and cost almost nothing to host. Blog posts, case studies, and product listings that need fresh data can be server-side rendered, pulling content from a database on each request.

We use this exact pattern on Med-Vision, a healthcare consulting site built with Astro 4 SSR. The core service and about pages are fully static for maximum speed. The blog posts and case studies pull from MariaDB on each request, so new content appears immediately without a full site rebuild. This hybrid approach gives you the speed and security of static sites for foundational content, combined with the dynamic capabilities of SSR where you need them. It is also how we connect our custom headless CMS to Astro client sites.

The Pros

Our decision to standardize on Astro was based on several concrete advantages:

• Framework-agnostic: Use React, Vue, Svelte, Preact, Solid, or plain HTML within the same project. Pick the right tool for each interactive island, or skip frameworks entirely for static content.
• Exceptional performance out of the box: Zero JavaScript by default plus islands architecture consistently delivers Lighthouse scores of 95 to 100.
• Simple mental model: Write HTML and CSS for content. Add interactivity only where needed. No need to think of everything as a "component" or manage complex state for static content.
• Content-focused by design: Built to handle markdown, MDX, and headless CMS content efficiently.
• Growing ecosystem: Official integrations for Tailwind CSS, MDX, sitemap generation, image optimization (AVIF, WebP), and RSS feeds.
• TypeScript support built in: Type safety and better tooling for larger projects.
• Excellent documentation: Clear, comprehensive, and practical.

The Honest Cons

No technology is perfect. Here are the real tradeoffs:

• Smaller ecosystem than Next.js: Fewer third-party plugins, fewer tutorials, and fewer Stack Overflow answers for niche problems. The community is growing fast, but it is not as established yet.
• Not ideal for heavy SPAs: If your project is fundamentally a single-page application with complex client-side routing and extensive state management (a SaaS dashboard, a project management tool), use Next.js or SvelteKit instead.
• SSR requires a Node.js server: Static mode is simple to host anywhere. SSR mode needs a Node.js process, which adds hosting complexity compared to pure static files.
• Learning curve for WordPress-only teams: Moving from WordPress to a JavaScript-based build process requires understanding components, build tools, and package managers. The investment is worthwhile, but it is real.
• Build step adds complexity: Compared to uploading raw HTML files, Astro's build process is an extra layer. It is what enables the performance benefits, but it is a consideration for simple projects.

Who Should Use Astro (and Who Shouldn't)

Great for: Marketing sites, portfolios, blogs, documentation, multi-page business sites, landing pages, and any content-first website where most pages are primarily informational with occasional interactive elements.

Not great for: Full web applications (SaaS dashboards, project management tools), real-time collaboration platforms, or sites where 90% of the UI is interactive with minimal static content. For those, use Next.js, SvelteKit, or a dedicated SPA framework.

The sweet spot is sites where most pages serve content with some interactive components. That describes the vast majority of business websites, which is exactly why we adopted Astro as our standard for web design.

Astro vs. Next.js vs. WordPress