Why a website with zero JavaScript loads faster

Most slow websites aren't slow because of their words or their pictures. They're slow because of the code that runs before anyone can read those words. Here's why sending no JavaScript at all is the quickest route to a fast site, and how vagejs makes it the default instead of a weekend project.

What happens when a page loads?

When someone taps a link, their browser has a short list of jobs. It downloads the HTML, reads it from top to bottom, fetches the stylesheet, works out where everything goes, and paints the result onto the screen. For a plain page of text and images, that's quick. A modern phone can do it in a fraction of a second.

JavaScript adds more jobs to that list. The browser has to download each script, then parse it (read and understand the code), then compile it, then run it. While a script runs, the browser's main thread is busy, and a busy main thread can't respond to taps or scrolls. On a fast laptop you barely notice. On a mid-range phone with a weak signal, every extra script is time your visitor spends staring at a half-drawn page.

That's the core idea: HTML and CSS are cheap for a browser to handle, and JavaScript is expensive. Byte for byte, a script costs more than an image of the same size, because an image only needs decoding, while a script needs parsing, compiling and running.

Why do content sites ship code they don't need?

A blog post, a pricing page or a company's "About us" page doesn't need to change after it loads. It's the same for every visitor. Yet plenty of these pages arrive with large bundles of JavaScript, usually for one of three reasons:

1. The framework needs it. Some tools build every page as an app, so the browser has to download the app's code before it can show anything interactive, even when nothing on the page is interactive.
2. Plugins add it. Each add-on for sliders, pop-ups, fonts or forms brings its own script, and they pile up over the years.
3. Nobody measures it. Without a check on page weight, a page can quietly grow from a few kilobytes to a few megabytes.

None of these are about what the reader came for. They're the cost of the tooling.

The three numbers Google cares about

Google measures how a page feels to real visitors with a set of signals called Core Web Vitals. There are three, and the thresholds Google calls "good" are measured at the 75th percentile of real visits (so most of your visitors need a good experience, not just the lucky ones):

• Largest Contentful Paint (LCP): how long until the biggest piece of content, usually a heading or main image, appears. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page reacts when someone taps or clicks. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much things jump around while the page loads. Good is 0.1 or less.

JavaScript can hurt all three. Scripts that block rendering push LCP later. Long tasks on the main thread make taps feel sluggish, which raises INP. And content injected by scripts after the page appears, like a late banner, shoves everything down and adds to CLS.

A page with no JavaScript removes the biggest cause of trouble on two of those three numbers outright, and makes the third much easier to control.

If you'd like to check these sources yourself, run npx vage guidelines --json in a vagejs project. It shows the Core Web Vitals thresholds the tool uses, with a link to Google's own page about them.

What "0 KB of JavaScript" looks like in practice

vagejs is a static site generator. That's a technical name for a simple idea: it builds every page ahead of time from your Markdown files, so the finished site is a folder of plain HTML, CSS and images. There's no server code and no database working each time someone visits.

By default, those pages carry no JavaScript at all. Not a small bundle, not a "hydration" step, nothing. The only way a script gets onto a page is if you add one on purpose, such as an analytics tag you've chosen to turn on.

We tested a brand-new site made with npm create vagejs@latest using Google's Lighthouse tool on mobile settings with a simulated slow network. Here's what it measured:

Lighthouse scored it 100 in Performance, Accessibility, Best Practices and SEO. That test used vagejs 0.3.0 and Lighthouse 13.5.0 on 24 October 2026. We ran it three times and got the same speed numbers every time.

Two honest caveats. First, these are lab results: one simulated page load on a fresh starter. Your numbers will depend on your images, your content and your host. Second, Google's ranking signals use field data from real Chrome users, which a lab test can only estimate. A fast starting point gives you a lot of headroom, but it isn't a promise.

Speed that doesn't wear off

Lots of sites launch fast and then slow down as features get bolted on. The fix isn't heroic optimization once a year. It's noticing the moment a page gets heavier than it should.

vagejs includes vage audit, which builds your site and checks every page against size budgets: limits for JavaScript, CSS, images, fonts, total weight and the number of requests. If a page goes over, you'll see which page and by how much. You set the budgets in vage.config.ts; the defaults are a starting point, not a rule handed down from above.

npx vage audit                  # budgets and accessibility checks
npx vage audit --lighthouse     # also runs Lighthouse in Chrome

When the site is live, npx vage audit --url https://your-site.com asks Google's PageSpeed Insights about a real page, plus real-visitor data from the Chrome UX Report if your site gets enough traffic to have it. It uses your own Google API key, which stays outside your project. More detail is in checks and audits.

Images: the other half of page speed

Once JavaScript is out of the way, images are usually the heaviest thing on a page. vagejs handles three of the most common image mistakes for you:

• No layout jumps. It reads each image's width and height from the file and writes them into the HTML, so the browser reserves the right amount of space before the picture arrives. That keeps CLS near zero.
• Lazy loading after the first image. Every image in your page content except the first one waits to download until the reader scrolls near it, so the first screen loads sooner.
• Smaller files for phones. Turn on images: { optimize: true } and vagejs makes resized WebP copies of your content images and offers them with srcset, so a phone picks a size that fits its screen instead of downloading a desktop-sized photo. It never enlarges a picture, and it remembers its work between builds so rebuilding stays quick.

// vage.config.ts
images: { optimize: true },

This needs the sharp package as a development dependency. Add avif: true next to optimize and vagejs makes AVIF copies too, offered first, with WebP as the fallback.

Fast also means fewer things to break

Speed isn't the only benefit of shipping plain HTML. A page with no scripts:

• Works on old and cheap devices. Low-end phones are often slowed down most by JavaScript, and plain HTML treats them the same as new ones.
• Works when a script fails. If a third-party script is blocked or down, a script-heavy page can show a blank screen. A static page just shows up.
• Is easier for search engines and AI tools to read. Crawlers get your full content in the HTML they download, with no need to run code first to see the text.
• Has a smaller attack surface. Without scripts there's less for an attacker to tamper with. On Cloudflare, vagejs writes a Content-Security-Policy worked out from your own pages, which tells browsers to refuse scripts you didn't put there.

"But I need a contact form" (and other honest limits)

Zero JavaScript is a great default, not a religion. Some sites need interactive pieces: a search box, a booking widget, a chart that updates. vagejs doesn't stop you adding them. Layouts are your own trusted code, and you can add the scripts you really need. Since 0.11 you can also mark a React component as interactive, and only the pages that use one load JavaScript. Just know the trade: every script you add has a cost, and vage audit will show it to you.

There are also things vagejs isn't built for. If you're building a web app with logins, dashboards and data that changes per user, a static content framework is the wrong tool. vagejs is for content websites: marketing pages, docs, blogs, portfolios and small business sites, where the same page goes to every visitor.

Analytics without slowing every visit

Analytics is the most common reason a content site ends up with JavaScript, so it's worth a word. In vagejs, analytics is off until you turn it on in vage.config.ts. You can choose Google Analytics 4, Google Tag Manager, Plausible or Microsoft Clarity.

When you do, the tag is added to production builds only, so your local preview stays clean, and Google's tags start with consent set to "denied" by default. Your own consent banner then updates that when a visitor agrees. If raw speed is your top priority, consider whether a lighter tool, or your host's server-side stats, answers your questions without a script on every page. See configuration for the settings.

How to try it

You'll need Node.js 22.12 or newer. Then:

npm create vagejs@latest my-site
cd my-site
npm install
npm run dev

Open the address the dev server prints, edit src/pages/index.md, and the browser reloads as you save. When you're ready, npm run build writes the finished site into dist/. Run npm run audit on it and see your own numbers.

Why zero JavaScript pays off

• Browsers handle HTML and CSS cheaply; JavaScript costs download, parse, compile and run time, which hurts most on phones.
• Core Web Vitals reward pages that appear quickly, respond quickly and don't jump around. Fewer scripts help all three.
• vagejs builds plain HTML pages with 0 KB of JavaScript by default, and a fresh starter scored 100 across Lighthouse's main categories in our lab test.
• Size budgets in vage audit keep the site fast as it grows, and image handling covers the rest.
• Lab scores aren't rankings. A fast site gives good content its best chance; it doesn't replace good content.

If you'd like a fast site without spending your evenings tuning one, get started in a minute or browse the docs.