Why your marketing site should ship zero JavaScript by default

Here’s a question worth sitting with: what does your marketing homepage do? For the vast majority of sites, the honest answer is “it shows text and images, and has a few links and maybe a form.” That’s it. It’s a document. And yet the typical marketing site ships one to three megabytes of JavaScript to render that document, a framework, its runtime, a router, a state library, and a pile of dependencies, all to display content that is fundamentally static.

This is backwards. The right default for a content site is zero JavaScript, with interactivity added deliberately, only where it earns its place.

The cost of JavaScript you didn’t need

JavaScript is the most expensive thing you can put on a page, byte for byte. An image of the same size just decodes and displays. JavaScript has to be downloaded, parsed, compiled, and executed, and that work happens on your visitor’s device, which might be a three-year-old phone on a coffee-shop connection, not the developer’s laptop.

When a site ships a heavy framework to render static content, every visitor pays for it: slower loads, a page that looks ready but doesn’t respond to taps yet (because the JavaScript is still booting), and worse Core Web Vitals scores that drag down search rankings. You’re paying a performance tax for capability you’re not using.

”But we might need interactivity later”

This is the reasoning that lands teams on a heavy framework for a brochure site: what if we add an app-like feature down the road? It feels prudent. It’s the expensive choice, because it makes every page slow today to hedge against a maybe-feature tomorrow.

The better model is the opposite. Start with zero JavaScript, pure HTML and CSS, which browsers render blindingly fast, and add interactivity as islands: small, isolated bits of JavaScript that hydrate only the specific component that needs them. A contact form, a filter widget, an image carousel. The form gets its JavaScript; the other 95% of the page stays static and instant.

You get the interactivity where it matters and the speed everywhere else. You don’t have to choose.

How this works in practice

Modern site frameworks, Astro is the one we reach for, are built around exactly this idea. You write components, but by default they render to plain HTML at build time and ship no JavaScript at all. When a component genuinely needs to be interactive, you mark it, and only then does it ship the code to make it work.

The result is a site that’s mostly static HTML served from a CDN, which is to say, about as fast as the web gets, with small pockets of interactivity exactly where the experience calls for it. Near-perfect Lighthouse scores aren’t something you fight for at the end; they’re the natural state of a site built this way.

Why this matters beyond speed

Shipping less JavaScript isn’t just faster. It’s:

• More reliable. Less code means fewer things that can break, fewer dependencies to keep patched, fewer runtime errors on someone’s odd browser.
• More accessible. Static HTML works everywhere, old phones, slow connections, assistive tech, without depending on a JavaScript bundle executing correctly first.
• Cheaper to host. Static files served from a CDN cost almost nothing to serve at scale, with no server rendering on every request.
• Better for SEO. Crawlers get fully-formed HTML immediately, not a blank shell they have to execute JavaScript to read.

The principle

This is really one instance of a broader principle we hold to: use the least powerful tool that does the job well. A document should be served as a document. An app should be built as an app. The trouble starts when you build a document as if it were an app, because that’s where all the weight comes from.

It’s why an EmbarkDev marketing site is fast by default rather than fast after a round of optimization, and why we’ll tell you honestly when a project genuinely is app-shaped and wants a different tool. If you want a site that’s fast because of how it’s built, not despite it, let’s talk.