Astro 7.4 Profiles Your Build and Splits Image Services by Phase

Astro 7.4 shipped on October 15 with a build profiler that answers a question most teams guess at. astro build --timings prints a breakdown across build phases, Vite plugins, Markdown and syntax highlighting, page rendering, image work, and integrations. In the blog starter, page generation consumed 2.10 seconds of a 2.61-second build, 80.6% of the total; parallelizing dependent fetches cut that phase to 1.13 seconds.

image.service now accepts separate build and runtime entrypoints. Prerendered pages and development use the build service, while on-demand pages and the production image endpoint use the runtime service. A single service still works. Integration authors need to handle the runtime property, because top-level entrypoint and config are undefined in split mode, and custom prerenderers must pass through image metadata from getStaticPaths() and render().

Two experimental flags are worth watching. experimental.parallelPrerender renders static pages on Node worker threads, defaulting to all cores but one. Astro ignores it, with a warning, when the adapter prerenders itself, which currently means @astrojs/cloudflare. The other lets you replace Astro's default redirect page with src/pages/3xx.astro for custom branding or locale handling.

The floor is now Node 22.22.0 for Astro and its official integrations. Check that before you upgrade. Take the build timings now; the profile usually points at image work or a serial fetch chain.