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

Astro 7.4 adds astro build --timings for diagnosing slow builds, separate build/runtime image services, and experimental parallel prerendering for multi-core speed.

Canonical URL: https://aiidelist.com/blog/astro-7-4-release-build-timings-parallel-prerender

Language: en

Published: 2026-10-15

Updated: 2026-10-15

## 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:

```bash
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:

```js
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:

```js
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.