The seventh round of Astro puts the weight not on a feature list but on the build pipeline itself: move the two slowest stages into Rust, then hand whatever is still unexplained to a report about where the time went.

The version sits at 7.4.1

The current stable release is 7.4.1, published on 19 October 2026. The line rests on two waypoints: the 7 line opened on 22 June 2026, and this release landed on 15 October. The project is open source under the MIT licence, and the repository is written mainly in TypeScript.

Rust took over the two slowest stages

What the first release of the 7 line did fits into one sentence: replace the whole component compiler, rewritten from a Go build into a Rust one; move Markdown and MDX handling onto a Rust pipeline; and change the rendering engine to a queue based strategy that lines up fragments waiting to be rendered more efficiently.

The official reason is that a build has three stages and the first one eats the time: pages, content and client components get packed into one JavaScript bundle, then each prerendered page is requested in turn and turned into HTML. The slow part happens to be compilation and Markdown handling, so both moved into native code. The default Markdown processor changed with them, from a combination of plugins to a pipeline of its own. Sites writing plain Markdown barely notice; a project carrying a string of plugins that rewrite the syntax tree has to confirm them one by one.

Vite 8 and the bundler it brings

The other half of the speed comes from Vite 8. The largest change in that release is a bundler written in Rust built into it, merging two tools that used to split the job while keeping the plugin interface intact. After the merge the official figures give a range: overall build time drops somewhere between 15 and 61 percent, and a few sites go more than twice as fast.

The benchmark table shows the distribution better. A documentation site of six thousand pages went from about 115 seconds to about 74, and one of thirteen thousand from about 386 to about 326. The more pages a site has, the smaller the percentage gain, because page rendering itself did not move into Rust and takes a bigger share of what is left.

How much you gain depends on how much of your site's time goes into compilation and Markdown, and a content site built from a few thousand Markdown files is exactly the kind where compilation dominates.

This release turns the build into a report

The first release answered how to be faster; this one answers where the speed went and where it did not. The build command takes another flag, and at the end it prints a breakdown: each stage, each class of plugin, Markdown handling and syntax highlighting, page rendering, image handling and integrations, with times and shares, plus median and high figures for the slowest pages.

The official demonstration uses a blog starter. The template holds nine pages, the whole run takes about two and a half seconds, and page generation accounts for just over two of them, roughly 80 percent. The slowest pages are almost all the ones applying the article layout, while the homepage and the feed sit in the milliseconds. The problem is named precisely: inside the layout the comment section fetches comments first and then the profile of each author, chaining two rounds of requests, so every page waits.

After changing it to fetch everything concurrently in one pass and pass the results down, page generation fell from just over two seconds to about one, and rendering time per article halved. The value of the example is not that second but what it surfaces, which is hard to find without a report: in the editor the code looks perfectly fine.

Image service splits into build and runtime

This release lets the image service be configured twice: one for prerendered pages, one for pages rendered on demand. A build has the whole machine and a full runtime, so the local optimiser fits best; on-demand rendering runs on a server or an edge node where the local optimiser may not work at all, which makes an image CDN the sensible pick. Before this you picked one or left the choice to the adapter. To make it hold, images used during the build are now tracked by the framework's own pipeline, and adapters no longer reimplement their own copy.

What a stricter compiler means

Swapping compilers is not pure speed. The new Rust compiler is stricter about invalid HTML: unclosed tags raise errors outright, and non-void elements must have a matching closing tag; semantically invalid nesting is no longer corrected automatically but handed to the browser as written.

The old compiler helped quietly, closing tags, fixing order and moving misplaced nodes out. That help caused trouble that was hard to debug in some cases, so the new one declines. The price is that an upgrade may surface errors never seen before and may change rendered output. The practical routine is plain: run a build after upgrading, close whatever tags are open, and check template nesting wherever output moved. A project with tidy templates feels almost nothing; one carrying history gets a cleanup.

Two experimental switches and a few new rules

Two experimental abilities ride along. One is parallel prerendering, spreading static page rendering across worker threads and using every core but one by default; each worker adds memory to the build, so on a tight machine or when nothing gets faster the count should come down. The other is a custom redirect page: a static site has no server to send redirect headers, so every redirect generates a small page carrying a refresh instruction, and until now its text, styling and delay were fixed, while the new switch renders it from your own template with source, target, status code and delay passed in as parameters.

A few new rules are worth noting. The minimum Node version rises to 22; src/fetch.ts becomes a reserved filename that advanced routing pulls in as configuration, so a project with a file of that name must change config or rename; and font providers gain an optional callback declaring the weights, glyphs, subsets and formats a family actually has, where a value the provider cannot supply draws an early warning. That callback is optional now and becomes required in the next major release.

Who it suits

The site calls itself a web framework for content driven websites, naming marketing sites, blogs and shops as the kinds it serves. The core design is server first: components render on the server and only HTML goes to the browser, leaving no surplus JavaScript cost, while interactive parts load separately as islands. On extensibility it accepts components from the mainstream UI frameworks, so existing components move in as they are, and on the content side it offers collections, where Markdown and data files dropped into a folder gain type safety and completion.

The reason to put it in a toolbox is rarely one feature but build time and output size being controllable at once. The first release pushed the former down; this one makes it explainable.

The story Astro 7 tells is plain: replace the slow parts with a faster language, then turn what remains unexplained into a report somebody can read. The first took a rewrite, the second takes a flag. What is worth remembering is not the percentages but the order: when a build slows down, read the report before deciding what to change.