Astro 6 to 7: The Real Numbers From Upgrading a 129-Page Site

I budgeted a Saturday afternoon to bump QuietClip's website from Astro 6 to Astro 7. I expected the usual chore: skim the migration guide, fix three deprecations, swear at one config option, redeploy, forget about it by dinner.

What I didn't expect was the production build dropping from 4.95 seconds to 2.95 seconds. Same code. Same machine. Same 129 pages. Forty percent faster, for the price of changing a version number.

So I did the thing I should always do and usually skip: I ran the benchmark before I touched anything, then ran the identical scripts after. Here are the real numbers from this Astro 7 upgrade, including the ones that refused to move.

40% faster builds, and I changed nothing but the version

Cold build: 4.95s to 2.95s. Warm build: 4.85s to 2.96s. Both are the median of five runs on the same Apple Silicon machine, same Node 22, same content collection. The only real change was Astro 6.4.8 going to 7.0.2, which pulled Vite 7 up to Vite 8 and switched on the new Rust-based template compiler.

I added exactly one line to the config: compressHTML: true. Astro 7 changed the default HTML compression strategy, and I wanted a clean before-and-after, not a comparison polluted by different whitespace handling. That was the entire migration. No deprecations to chase, no breaking API in my 69 .astro components. The thing I had braced for never came.

If you've ever sat through a Next.js build slowly eating your server, you know why I care about this. I wrote a whole post about my Next.js build killing my server and how I fixed it for free. Build time isn't a vanity metric. It's the tax you pay on every single deploy, every preview, every tiny typo fix. Cutting it in half changes how often you're willing to ship.

Where the two seconds actually went

The headline number hides the interesting part. The savings weren't spread evenly. They came from two specific phases.

The Vite client bundle dropped from 2.66s to 0.92s. That's a 65% cut, and it's almost entirely Vite 8 doing the work, not Astro. Rendering all 129 pages went from 4.39s to 2.32s, a 47% cut, and that's the new Rust compiler plus Astro's queued rendering. Those are exactly the two phases version 7 set out to attack, so it's satisfying to watch the benchmark agree with the changelog instead of the marketing copy. Peak build memory also came down 11%, from 704 MB to 625 MB, which matters if your CI box is small.

Here's the honest footnote I won't bury: image optimization is excluded from all of these numbers. QuietClip's site has over a thousand optimized webP files, and a first-ever cold build spends roughly 8.6 seconds in sharp generating them. But sharp is byte-for-byte identical in Astro 6 and 7, so including it would just add the same constant to both sides and dilute the real story. The repeatable build, the one you actually run all day, is the 5-second-to-3-second one. That's the number I'm standing behind.

The part that actually scared me

Faster builds are worthless if the site quietly breaks. A major version bump that swaps the template compiler and the markdown engine is exactly the kind of change that introduces a subtle rendering bug you don't notice until a customer emails you. I've watched AI tools confidently "upgrade" things and leave a mess behind, which is the whole reason I wrote about how Claude is great at building software and also great at breaking it.

So I checked. The build ran clean across 261 files, 69 .astro components and 132 markdown and MDX pages, with zero Rust-compiler errors and zero deprecation warnings. I grepped the entire dist/ folder for the usual failure signatures: unrendered MDX component tags, leaked import statements, raw expressions printed as text. Nothing. My editorial components still render. SmartyPants typography is intact across all 114 posts that use curly quotes. The new default markdown engine, Saetteri, turned out to be a transparent swap because I wasn't running any custom remark or rehype plugins that needed porting.

The output payload barely moved either. Gzipped HTML went from 1090.3 KB to 1088.1 KB across 129 files. JavaScript shrank slightly, 48.6 KB to 47.4 KB. CSS unchanged. That "barely moved" is the point: I got the build speedup without shipping a different site to anyone.

The numbers I'm deliberately not bragging about

If I only showed you the wins, you'd be right to distrust the rest. So here's what didn't improve, because pretending otherwise is how case studies become advertising.

Runtime Core Web Vitals on the live site are flat. The static HTML, CSS, and JavaScript a visitor downloads is essentially unchanged, so there was no reason to expect Lighthouse to jump, and it didn't. Desktop was already pinned at 100 with a Largest Contentful Paint around 0.5s and basically zero layout shift. After the Astro 7 upgrade and redeploy on Cloudflare, it held at 100 with no runtime regression. The honest live story is "nothing got worse," not "everything got faster." Build speed is a developer-experience win. It does not magically make your pages load faster for users, and anyone telling you a framework bump fixed their field performance is usually conflating the two.

My local Core Web Vitals measurements moved by a few milliseconds in both directions, but those were captured on unthrottled localhost, which is far too fast to publish as real-world numbers. They're a valid relative check, useless as an absolute claim. The publishable runtime figures are transfer sizes and request counts, and those stayed put: around 180 KB per page, 9 to 12 requests. No regression there either.

So should you do the Astro 7 upgrade?

If you're already on Astro 6 with a content-heavy static site and no exotic plugin stack, this was the easiest 40% I've ever bought. One config line, an afternoon of verification I mostly did out of paranoia, and faster builds forever. The risk-to-reward here was lopsided in a way that almost never happens with major version bumps.

If you're on a heavily customized setup with a pile of remark plugins or a server-rendered adapter doing clever things, slow down and benchmark your own phases first. My result is one data point from one 129-page marketing site, not a promise. Run the before-and-after yourself. That's the only honest way to know.

And if you're still deciding which framework to build on in the first place, I've written about how I actually decide between WordPress, Next.js, and Astro for client projects, and about the time I migrated three client sites from WordPress to Astro and nothing broke. Astro keeps earning its place on that shortlist, and this upgrade is part of why.

This is the kind of unglamorous, measured work I do for clients at Wunderlandmedia: benchmark before you touch it, verify after, and report the numbers that didn't move alongside the ones that did. If you want someone who treats your build pipeline like it matters, that's the whole job.