There is a version of the "we rewrote it in Rust" story that is mostly marketing. Astro 7 is not that version — it replaced three separate layers of its build pipeline at once, and then spent two point releases dealing with the consequences.
The short version: the .astro compiler is now Rust instead of Go, Markdown and MDX run through a new Rust processor, rendering moved to a queue-based engine, and the whole thing sits on Vite 8 with its Rolldown bundler. Astro's own benchmarks put builds 15 to 61 percent faster.
That range is the real story. A 4× spread between the low and high end means the honest answer to "will this speed up my build?" is it depends on what your site looks like — and it is worth knowing which side you land on before you plan the migration.
What actually changed under the hood
Three swaps, each with different implications.
The compiler. The .astro compiler was rewritten in Rust, replacing the previous Go implementation. It is built on oxc for parsing and Lightning CSS for style scoping — the same native toolchain layer that Vite, Rolldown, and a growing share of the JavaScript ecosystem now share. This is the part of the release that touches every project, because every .astro file goes through it.
Markdown and MDX. Content now runs through Sätteri, a Rust processor built on pulldown-cmark and Oxc by Astro core team member Erika. GitHub Flavored Markdown, smart punctuation, heading IDs, math, and wikilinks are built in rather than added as plugins. Projects that depend on the remark/rehype ecosystem can stay on the old unified pipeline — the maintainers were explicit on Hacker News that the new pipeline is deliberately pluggable and unified is not going away.
The bundler. Vite 8 ships Rolldown as its single unified Rust bundler, replacing the previous esbuild-in-dev / Rollup-in-prod split. That change is not Astro-specific; it lands the same way for anyone else on Vite 8.
Astro's published numbers: astro.build itself went from 62.70s to 24.24s, and the Cloudflare developer docs — 8,431 pages — went from 386.89s to 261.94s. Note the shape of those two results. The small marketing site got a 2.6× improvement; the enormous docs site got about 1.5×. Bigger is not automatically better here.
Who actually gets the speedup
Maintainer Matthew Phillips answered this directly when a developer reported their builds got slightly slower:
The performance improvements are mostly for larger sites (thousands of pages) and especially when using a lot of MDX.
Read that as a decision rule.
- Heavy MDX, thousands of routes: this is the target case. The Markdown pipeline was the bottleneck, and it is the piece that got replaced wholesale.
- A few dozen pages, mostly components: you will see something, but compile time was probably not your problem. Your build is dominated by npm install, image processing, and CI runner cold start.
- Builds dominated by data fetching: a faster compiler does not make your CMS respond faster. If your build spends 90 seconds waiting on API calls, native tooling optimizes the other 10.
Before you plan a migration around build time, find out where the time actually goes. On most CI providers this is one line:
# Where does the wall clock go?
time npm ci
time npm run build
If npm ci is the larger number, Astro 7 is not your fix.
The strictness tax
The new compiler is stricter than the Go one, and this is the part that surprises teams mid-upgrade. Unclosed tags now error instead of being silently repaired. Invalid nesting is passed through as written rather than corrected. Whitespace between elements follows JSX rules.
For a greenfield codebase this is a non-event. For a codebase with four years of accumulated .astro files written against a forgiving compiler, it is a real migration cost, and one commenter on the release thread called it "just not cool" for exactly that reason.
The mitigation is boring and effective: upgrade on a branch, let the compiler tell you, and fix in bulk.
npx @astrojs/upgrade
npm run build # the compiler will now list what it used to quietly repair
The v7 upgrade guide covers the rest. The breaking changes worth flagging to whoever owns the codebase: src/fetch.ts becomes a reserved filename, @astrojs/db is removed in favour of Drizzle or node:sqlite, and the deprecated astro:transitions internals are gone.
One genuinely nice side effect, reported in the release discussion: the dependency count dropped from 247 in v6 to 190 in v7. Fewer packages in the tree is fewer things to audit the next time an advisory lands in a transitive native dependency — which, as Next.js users learned this week, is not a hypothetical concern.
Incremental builds are the bigger lever
Here is the thing about making a full build 40% faster: on a large content site, you are still rebuilding 8,000 pages to publish one typo fix. That is the wrong shape of problem to solve with raw speed.
Astro 7.2, released on 6 August, added experimental incremental builds behind a flag. A route opts in by returning a cacheKey for each path from getStaticPaths(); if the key is unchanged since the last build, the page is not re-rendered.
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
experimental: {
incrementalBuild: true,
},
});
For content collections, the natural key is the entry digest — it changes exactly when the underlying content changes:
// src/pages/blog/[...slug].astro
export async function getStaticPaths() {
const entries = await getCollection('blog');
return entries.map((entry) => ({
params: { slug: entry.id },
props: { entry },
cacheKey: entry.digest,
}));
}
The discipline this demands is worth naming: your cacheKey has to capture everything that affects the rendered output. If a page's HTML depends on the entry body and on a shared sidebar of recent posts, keying on entry.digest alone will serve stale pages. That is not a bug in the feature — it is the same cache-invalidation problem every incremental system has, moved to a place where you can see it. Key it on a hash of every input, or leave the route out of the incremental path.
It is behind an experimental flag for a reason. Treat it as something to prototype on a branch and verify against a full build, not something to switch on before a release.
Also worth knowing
Two smaller items from the point releases that solve real problems:
Astro 7.1 (16 July) split the CSP directives, adding script-src-elem, script-src-attr, style-src-elem, and style-src-attr. If you have ever loosened style-src to 'unsafe-inline' because one component needed an inline style, and thereby weakened the policy for every external stylesheet too, this is the fix. It also added an experimental collectionStorage: "chunked" flag that splits the .astro/data-store.json store every 10Mb — relevant if you deploy to a platform that caps individual file sizes.
Astro 7 also introduced advanced routing through a src/fetch.ts entrypoint compatible with Hono, and stabilised route caching with experimental CDN providers for Netlify, Vercel, and Cloudflare.
Takeaways
- Measure before you migrate. The 15–61% range is real, and where you land in it depends on page count and MDX volume. If your build time is dominated by dependency install or data fetching, a native compiler will not move the number that matters.
- Budget for the strictness tax on older codebases. The new compiler errors on markup the Go one silently repaired. Run
npx @astrojs/upgradeon a branch and let the build surface the list. - Incremental builds are the structural fix, not raw compiler speed. For content sites in the thousands of pages, not rebuilding unchanged routes beats rebuilding them faster. But own the cache-invalidation problem honestly — a
cacheKeythat misses an input ships stale HTML. - Fewer dependencies is a security result, not just a tidiness one. 247 → 190 packages is 57 fewer transitive surfaces to audit.
- The broader signal: with Astro on Rust, Vite 8 on Rolldown, and Next.js on Turbopack, native build tooling is now the default rather than the differentiator. Build time is no longer a reason to pick one framework over another — which frees the decision to be about the thing it should have been about all along, which is what you are building.
Sources