What “zero JavaScript” actually means

When we say Astro ships zero JavaScript by default, we mean it literally. The HTML that arrives at your visitor’s browser is just that — HTML and CSS. No framework runtime. No hydration step. No virtual DOM diffing. No 200KB of React sitting idle in the background, waiting for someone to click a button that never gets clicked.

Most frameworks do not work this way. They assume interactivity everywhere, so they ship the machinery for interactivity everywhere, even on pages that are just text and images. Astro inverts the assumption. A page is static until you explicitly tell it otherwise.

Why should you, the business owner, care

JavaScript costs you money. Not on your invoice — in the places that show up on your revenue.

Bounce rate. Google’s own data: as page load time moves from one second to three seconds, the probability a visitor leaves jumps 32%. Move to five seconds and you have lost most of your mobile audience. Every kilobyte of JavaScript adds load time, and the relationship is not linear on a phone.

Mobile reality. Roughly half of your traffic is on a phone. A mid-range Android — the device most of your customers actually carry — takes three to four times longer to parse and execute the same JavaScript as a MacBook. The animation that looks buttery on your laptop is janky on the phone in someone’s pocket. We have watched this happen in testing over and over.

Search ranking. Google treats page experience as a ranking signal. Core Web Vitals, especially the interaction metric, are directly driven by how much JavaScript blocks the main thread. A heavy site does not just feel slow. It ranks lower.

The numbers, side by side

A typical marketing site built on React or Next.js ships somewhere between 150KB and 300KB of JavaScript gzipped, before you add a single feature. A lot of that is framework code the page is not even using — state management, a router, a virtual DOM — sitting there because the framework needs it on standby.

The same site, built in Astro, ships zero kilobytes of JavaScript. The entire page — HTML, CSS, fonts, images — often weighs less than that one JavaScript bundle.

This is not a 20% improvement. It is a different category of performance. The phone processes the page the moment the bytes arrive instead of waiting to execute a script before it can paint.

When you actually need JavaScript

You need JavaScript when the page has to respond to the user in a way HTML alone cannot. A contact form that validates input as you type. A pricing toggle. An interactive gallery. A search box. These are legitimate uses, and Astro does not stop you from using them.

The mechanism is called islands. Astro renders your whole page as static HTML at build time. Then, for the specific components that need interactivity, it ships a small, self-contained chunk of JavaScript — an island — and hydrates only that piece. Everything around it stays static.

A contact form becomes an island in a sea of static content. The hero image, the navigation, the body copy, the footer — none of them load a single line of JavaScript. The form loads maybe 4KB. The total for the page might be 4KB instead of 200KB.

A waterfall chart comparing a 200KB React bundle against Astro's near-zero baseline

That is the whole idea. You pay for interactivity only where you use it.

Why most business sites do not need a framework

Here is the uncomfortable truth about the average small business website. It has five to ten pages. A homepage. A services page. An about page. A contact form. Maybe a blog. There is no real-time data. No user accounts. No dashboard. No complex state.

You do not need a client-side framework for that. You need clean HTML, well-structured CSS, a fast server, and good content. The framework is overhead you are paying for — in load time, in maintenance, in hosting — to solve problems you do not have.

We have inherited dozens of sites that were built on heavy frameworks to display what amounts to a brochure. The framework added nothing the visitor could see. It added load time, complexity, and a dozen dependencies that broke the next time someone ran an update.

The business case, in one paragraph

When a potential customer lands on your site and it appears instantly, they do not think “impressive Core Web Vitals.” They think “this feels like a real company.” They trust you a fraction more. They stay a few seconds longer. They are more likely to fill in the contact form. None of that shows up in a single metric. All of it shows up in your pipeline over time.

Speed is not a technical feature. It is a business advantage that compounds quietly.

What you give up (and what you do not)

People assume going static means giving up interactivity. It does not. You give up the assumption of interactivity. There is a difference.

If you need a working contact form, you have one. If you need a pricing calculator, you have one. If you need an interactive demo, you build it as an island and it works exactly as it would anywhere else. What you lose is the obligation to ship a framework’s runtime to every visitor regardless of whether they ever touch the interactive part.

You also give up a certain kind of complexity. There is no build pipeline fighting you. There is no hydration mismatch bug at 2am. There is no dependency tree with three hundred packages. For a business site, that is not a loss. It is relief.

If you want a site that loads before your competitor’s even starts, we build them that way by default. See our pricing or send us a message.