Astro 7.4 Is Here: Build Timings, Separate Image Services, and Experimental Parallel Prerendering

Key Takeaways

• Astro 7.4 (released October 15, 2026) introduces astro build --timings to surface exactly where build time is spent across phases, Vite plugins, pages, Markdown, images, and integrations.
• Separate build and runtime image services let teams use Sharp (or similar) for prerendered pages while routing on-demand/edge images through a CDN service that can actually run in constrained runtimes.
• Experimental parallel prerendering (experimental.parallelPrerender) renders static pages across Node.js worker threads, targeting multi-core machines and large static sites.
• Additional changes include a notFound() handler for custom entrypoints, font configuration warnings, a raised minimum Node.js version (22.22.0), and an experimental custom redirect page for static builds.
• Analysis of the official example shows that serial network requests inside components can dominate page-generation time; --timings makes these patterns visible before applying broader optimizations such as parallel prerendering.

What Changed in Astro 7.4

Astro 7.4 focuses on build observability and configuration flexibility rather than a single large feature. The release, authored by Matthew Phillips, centers on helping developers diagnose slow builds and on allowing different image-processing strategies for prerendered versus on-demand pages.

The three most visible additions are the new --timings flag, the ability to declare distinct build and runtime image services, and the experimental parallel prerendering flag. Supporting changes improve custom server entrypoints, surface font mismatches earlier, and raise the minimum supported Node.js version.

Build Timings: Diagnosing Slow Builds

Slow Astro builds often have non-obvious causes. A Vite plugin, Markdown syntax highlighting, image transforms, or a single heavy page component can dominate wall-clock time. Astro 7.4 adds a --timings flag that prints a structured summary after the build completes:

astro build --timings

The report breaks time down by:

• Build phases (resolve config, setup, route discovery, content sync, prerender bundle, client bundle, generate pages, etc.) with both absolute time and percentage
• Page rendering totals and the slowest individual pages (including median and p95)
• Vite plugins, Markdown processing and syntax highlighting, image transforms, and integrations

In the official demonstration, a blog starter with a comment section that performed sequential fetches (comments, then each commenter’s profile) showed page generation consuming roughly 81% of total build time. After restructuring the fetches with Promise.all and passing data down, page-generation time dropped from 2.10 s to 1.13 s. The timings output made the sequential dependency obvious without requiring custom instrumentation.

Community feedback and early usage notes indicate that the flag is particularly useful before enabling broader experimental options such as parallel prerendering or incremental builds, because it identifies whether the bottleneck is rendering, bundling, or image work.

Separate Build and Runtime Image Services

Prerendered pages and on-demand pages have different image-processing constraints. At build time a full Node.js environment is available, so a local optimizer such as Sharp is efficient. On-demand and edge runtimes frequently cannot run Sharp, making an image CDN the practical choice. Previously a single image service had to serve both contexts, or the adapter chose one automatically.

Astro 7.4 allows image.service to accept separate build and runtime entries:

import { defineConfig } from 'astro/config';

export default defineConfig({
  image: {
    service: {
      build: { entrypoint: 'astro/assets/services/sharp' },
      runtime: { entrypoint: 'my-image-cdn-service' },
    },
  },
});

• The build service handles images on prerendered pages (and during development).
• The runtime service handles on-demand pages and the production image endpoint.
• A single service object continues to work as before.

The change required reworking how Astro tracks images used during the build so that prerenderers participate in the same image pipeline. As a result, adapters such as @astrojs/cloudflare now process prerendered images through the shared pipeline rather than maintaining a separate path.

Experimental Parallel Prerendering

Static page rendering previously occurred on a single thread even when the host machine had multiple cores. Astro 7.4 introduces an experimental flag that moves static page rendering into Node.js worker threads:

import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    parallelPrerender: true, // default: all cores minus one
    // or parallelPrerender: { workers: 4 }
  },
});

Analysis of the implementation shows the following practical characteristics and limitations:

• By default Astro uses all available CPU cores except one; the workers option caps the count.
• Each additional worker increases memory usage. If the build OOMs or shows little speedup, reducing the worker count is the recommended first adjustment.
• Module-level variables are not shared across pages rendered in parallel (a value cached while rendering one page is not guaranteed to be visible while rendering another).
• Pages whose getStaticPaths() return unserializable values (functions, class instances) cannot participate in parallel rendering.
• Adapters that handle prerendering independently (for example @astrojs/cloudflare) ignore the flag and emit a warning.

On large static sites with CPU-heavy pages the feature can reduce wall-clock build time; on small sites or memory-constrained CI runners the overhead may outweigh the benefit. The --timings report remains the recommended starting point for deciding whether parallel prerendering is the right lever.

Additional Changes

notFound() handler for custom entrypoints. When composing handlers from astro/fetch or astro/hono (instead of the all-in-one astro() handler), unmatched requests previously returned an empty 404 even if a custom 404.astro existed. Astro 7.4 adds a notFound() middleware that must be placed before pages() to render the proper 404 page. The convenience astro() handler already includes this behavior.

Font configuration warnings. Font providers can now implement an optional getFontProperties() callback that reports the weights, styles, subsets, and formats a family actually offers. Astro warns when the configuration requests values the provider cannot serve. All built-in providers support the callback.

Minimum Node.js version. The minimum supported Node.js version for Astro and official integrations is now 22.22.0, following the project’s support policy and alignment with environments such as StackBlitz. Projects on older Node 22 releases must upgrade Node before upgrading Astro.

Experimental custom redirect page. Static builds gain an experimental option for a custom redirect page.

Practical Considerations and Edge Cases

• Run astro build --timings on a representative production-like build before changing concurrency or enabling experimental flags. The report distinguishes page-rendering cost from Vite plugin cost and image cost.
• When adopting separate image services, verify that the runtime service is available in the deployment environment and that the build service can process the largest source images used on prerendered routes.
• Parallel prerendering is most effective on sites with many independent static pages. Sites that rely on shared module-level caches or that use adapters with their own prerender pipeline will see limited or no benefit and may receive warnings.
• Custom entrypoint setups that previously returned empty 404s should insert the new notFound() handler; existing all-in-one astro() usage is unaffected.
• Font warnings are advisory. They surface configuration mismatches that previously appeared only as incorrect visual output.

Conclusion

Astro 7.4 improves the developer’s ability to observe and control the build. The --timings flag provides a concrete breakdown of where time is spent, separate image services remove the previous one-size-fits-all constraint, and experimental parallel prerendering offers a multi-core path for large static sites. Supporting changes to custom entrypoints, font diagnostics, and the Node.js baseline complete a focused release.

Teams evaluating the upgrade should first capture a baseline with astro build --timings, confirm Node.js 22.22.0 or newer, and then decide whether separate image services or parallel prerendering address measured bottlenecks. The automated upgrade path is npx @astrojs/upgrade; full details and configuration examples are available in the official Astro 7.4 announcement and the corresponding documentation pages for the new flags and image service options.