Astro 7.4: Measure and Speed Up Your Website Builds

Since October 15, 2026, Astro 7.4 has offered astro build --timings, a new tool for understanding what slows down website generation. Vite plugins, Markdown, images, integrations, or components: instead of searching at random, developers can identify the areas that actually consume the most time and verify the impact of their optimizations.

This new feature is particularly useful for large brochure websites, B2B catalogs, and publishing platforms. It does not, by itself, guarantee a faster build: it is a diagnostic tool. Here’s how to use it in practice, along with the limitations of Astro 7.4’s other features.

1. How do you use astro build --timings?

As new pages and integrations are added, a build can take much longer than it did when a project was first launched. Astro 7.4 now displays a report at the end of compilation that breaks down where time is being spent. To get started, check your Node.js and Astro versions, then run the build again:

node --version
npx astro --version
npx astro build --timings

The diagnostic breaks down the cost of configuration, preparation, client and server bundles, page generation, Vite plugins, Markdown, syntax highlighting, images, and integrations. It also highlights pages or files that take longer than others. The report does not necessarily attribute every millisecond to a single line of code, but it shows you where to investigate.

One caveat: some tasks run concurrently. The sum of all the durations shown does not necessarily equal the total elapsed time. To evaluate a speedup, always compare the total time with the details for the targeted phase.

2. A practical example: a 600-page business catalog

Imagine a B2B catalog whose 600 product pages are built from an API, with descriptions, images, and specifications. This is a teaching example, not a benchmark run by SDX: measurements for this project have yet to be collected.

If most of the “slowest pages” are product pages and “component render” is the dominant cost, examine those pages’ components and queries. If the main cost appears under “images,” optimizing the image pipeline should take priority. The report helps you avoid confusing these two causes.

What the Astro team actually measured

To demonstrate the feature, Astro expanded a nine-page blog with a comments section that first fetches comments, then the authors’ profiles. The successive calls increase generation time. After combining these requests with Promise.all(), the page generation phase drops from 2.10 to 1.13 seconds.

This is neither the total compilation time after optimization nor a generalizable gain for 600-page catalogs. The demo’s initial total build took 2.61 seconds, but the highlighted result, 2.10 → 1.13 seconds, is specifically for page generation.

3. Reduce network waits and share data

Avoid two independent sequential requests

In an Astro component, a product’s details and stock data may be fetched one after the other even though neither depends on the other:

---
const { product } = Astro.props;
const api = import.meta.env.CATALOG_API_URL;
const details = await fetch(api + "/products/" + product.id)
  .then((r) => r.json());
const stock = await fetch(api + "/stock/" + product.id)
  .then((r) => r.json());
---

You can run both requests together with Promise.all():

---
const { product } = Astro.props;
const api = import.meta.env.CATALOG_API_URL;
async function getJson(path) {
  const response = await fetch(api + path);
  if (!response.ok) throw new Error("API " + response.status);
  return response.json();
}
const [details, stock] = await Promise.all([
  getJson("/products/" + product.id),
  getJson("/stock/" + product.id),
]);
---

This approach can reduce waiting time, but it does not reduce the number of requests. It requires error handling and concurrency levels that are compatible with the API’s limits; launching hundreds of simultaneous requests can instead overwhelm the service.

Load the catalog once instead of once per page

If the products are available in a single response, getStaticPaths() can prepare the static routes and pass the required data to the pages, avoiding repeat API calls for each property that is already known:

---
// src/pages/catalogue/[slug].astro
export async function getStaticPaths() {
  const api = import.meta.env.CATALOG_API_URL;
  const response = await fetch(api + "/products");
  if (!response.ok) throw new Error("Catalogue indisponible");
  const products = await response.json();
  return products.map((product) => ({
    params: { slug: product.slug },
    props: { product },
  }));
}
const { product } = Astro.props;
---
<h2>{product.name}</h2>
<p>{product.description}</p>

This code is intentionally simplified: it assumes the API’s content can be loaded in one batch and that a static page does not require immediate refreshing. On a real platform, use a shared data layer, controlled caching, and pagination or batched requests if needed. Highly variable stock or prices should not be frozen without a refresh strategy: they may require on-demand rendering.

The same logic applies to other opportunities: eliminate redundant Markdown processing, review Vite plugins, avoid repeated calculations in a layout, and identify an unusually high number of image conversions. Every change should correspond to a hypothesis that can be verified with --timings.

4. Before and after: establish a reliable comparison

It is tempting to compare a local run with a build performed on another computer or in CI. However, CPU, memory, cache state, API response time, Node.js versions, and the exact content can all affect measured timings. A comparison is only meaningful when the scope remains constant.

A practical protocol is to run five builds per variant, clearly distinguishing cold-cache and warm-cache builds. This is a method proposed for this article, not an official Astro benchmark.

Why are there no figures in these cells? Because no build was run for this fictional catalog. A reliable technical article must distinguish the proposed protocol from results that were actually obtained.

5. Should you enable experimental parallel prerendering?

Astro 7.4 introduces experimental.parallelPrerender, which distributes static prerendering across multiple Node.js worker threads. This can be useful for computationally intensive projects with multiple available cores. For example, enable it as follows:

// astro.config.mjs — test only
import { defineConfig } from "astro/config";

export default defineConfig({
  experimental: {
    parallelPrerender: { workers: 4 },
  },
});

By default, when the option is enabled without an explicit worker count, Astro uses all available cores except one. Each worker can generate multiple pages according to build.concurrency, but it also increases memory consumption. A machine with limited memory or a build constrained by network services will not necessarily benefit.

The right order is therefore: first remove unnecessary API calls, use --timings to identify costly areas, and only then compare worker configurations if CPU-bound rendering has been shown to be a bottleneck.

6. Images, Node.js compatibility, and other updates

Two image services for two environments

Astro 7.4 allows one service for pages prerendered at build time and another for pages rendered on demand. For example, you can use Sharp during the build and an image CDN service suited to your production runtime:

// astro.config.mjs
import { defineConfig } from "astro/config";

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

The name my-image-cdn-service is a placeholder, not a ready-to-use module: it must be replaced with a compatible, installed, and configured image service. The build service is also used during development; the runtime service is intended for on-demand pages and the production image endpoint. The traditional single-service setup remains supported.

Node.js 22.22.0 becomes the minimum supported version

Astro 7.4 and its official integrations require at least Node.js 22.22.0. Check development machines, Docker images, CI, and hosting, then test your dependencies during the upgrade. The recommended migration command is:

npx @astrojs/upgrade

The @astrojs/cloudflare and @astrojs/markdoc integrations must also be updated to versions compatible with astro@^7.4.0. Remember to back up the project and validate the build before deployment.

Other changes include the new notFound() handler for entry points built with astro/fetch or astro/hono, improved detection of font parameters unsupported by their provider, and an experimental custom static redirect page.

7. Generation, loading, and SEO: keep the metrics separate

Build performance measures how quickly work is completed before a site goes live: compilation, data fetching, processing, and file generation. It primarily affects teams, continuous integration, and deployment times.

Loading performance concerns the visitor experience: network time, JavaScript, fonts, images, caching, and responsiveness. Core Web Vitals measure LCP (loading), INP (interactions), and CLS (visual stability), among other things. --timings measures none of these metrics.

Technical SEO also depends on indexability, tags, HTML structure, canonical URLs, internal linking, and the sitemap. A faster build does not automatically fix these issues. Measure Core Web Vitals and separately check the rendered content and its accessibility to search engines.

If your main concern is the size of images delivered to the browser, our article on JPEG XL, WebP, and AVIF covers a complementary topic: the amount of data transferred to users is not the same as the time spent processing images during generation.

FAQ: Common questions about Astro 7.4

Does --timings make the site faster?

No. The report identifies build slowdowns; you still need to fix their cause and measure the actual impact of your changes. It does not directly affect the visitor experience.

How can you identify a costly Astro component?

Look at the slowest pages and the component rendering section, then inspect shared layouts, requests, expensive loops, and external processing. The report guides your investigation but does not, on its own, identify a specific line of code.

Does parallel prerendering work on Cloudflare?

The experimental feature is ignored by @astrojs/cloudflare, which already manages its own prerendering system. Do not attribute nonexistent gains to it.

Should you migrate to Astro 7.4 immediately?

The diagnostic tool is worth testing on a slow build. Before committing to a permanent migration, check the minimum Node.js version, integrations, and deployment environment. You can use the timings option without enabling parallel prerendering.

Conclusion: optimizations guided by measurement

The most useful new feature in Astro 7.4 is visibility into the generation pipeline. With astro build --timings, you can identify a repetitive external call, a slow component, or a costly transformation, address the cause, and compare the result. Parallel prerendering and separate image services address other needs, but do not replace this approach.

At SDX Development, we apply this approach to the design, redesign, and optimization of professional websites: deliver more efficiently, maintain a maintainable foundation, and independently verify the performance visitors experience.

Sources and methodology 4 references

• Astro — Astro 7.4, official announcement dated October 15, 2026, and the 2.10 → 1.13-second example.
• Astro — CLI documentation, description of --timings.
• Astro — Experimental parallel prerendering, configuration and limitations.
• web.dev — Web Vitals, definitions of user experience metrics.

The official measurement table covers Astro’s demo project, not a real catalog. The 600-page example presents a reproducible method whose results are yet to be measured.