Astro: why use it for sites with thousands of pages

A site with 50 pages forgives almost any technical choice. A site with 5,000 does not. Every extra kilobyte of JavaScript, every additional second in the build and every content field without a standard is repeated thousands of times.

Astro is a web framework created for this kind of project: content-driven sites such as blogs, documentation, portals and catalogs. This article explains why it usually works well at scale, based on the official documentation and public data consulted on October 8, 2026. It also shows where it stops being the best choice.

A necessary disclosure: the Token & Tech site is built with Astro. That is why we rely on verifiable sources and point out the limits with the same care as the advantages.

What Astro is

The Why Astro? page defines Astro as “the web framework for building content-driven websites”. Two principles appear right at the start.

The first is being server-first: Astro prefers to build the HTML on the server or at build time, instead of assembling the page in the visitor’s browser. The second is zero JavaScript by default: pages reach the browser without JavaScript unless you ask for it.

In June 2026, the team released Astro 7. In January of the same year, the company behind the project joined Cloudflare. According to the announcement, Astro remains open source, under the MIT license, and stays compatible with various hosting platforms, not just Cloudflare’s. It is worth watching whether this promise holds, since it is a statement of intent, not a technical guarantee.

Why the number of pages changes the choice

On a small site, a heavy framework costs little. On a large site, three costs add up.

• Cost to the visitor: the JavaScript each page loads weighs on the reader’s phone, especially on slow connections.
• Build cost: the build is the step in which the framework turns code and content into the site’s final files. With thousands of pages, it can take minutes.
• Editorial cost: thousands of content files only stay consistent if there are rules the computer can check.

Astro has answers for all three. None is magic, and each comes with trade-offs.

Islands: interactivity only where needed

Astro’s central concept is the islands architecture. The documentation on islands describes the page as static HTML, with small “islands” of JavaScript only where there is interactivity or personalization. The term “component island” was coined in 2019 by Katie Sylor-Miller, then at Etsy, and expanded in 2020 by Jason Miller, creator of Preact, according to the same page.

In practice, it works like this. By default, Astro strips all client-side JavaScript from components. To make a component interactive, you add a client:* directive. There are variations: client:load loads the component immediately, client:idle waits for the browser to be idle and client:visible loads only when the component enters the viewport.

This also applies to components from other libraries. Astro has official integrations for React, Preact, Svelte, Vue, SolidJS and AlpineJS. A React component used in Astro becomes static HTML on the server and only sends JavaScript if it receives a client directive.

For a portal with thousands of articles, the consequence is direct. The text, headings and links, which make up most of the page, arrive as ready-made HTML. The search button or the newsletter form load their own JavaScript, without dragging the rest of the page along.

There are also server islands, enabled with server:defer. They render a dynamic section on the server, separately from the rest of the page, and show placeholder content in the meantime. They are useful, for example, for displaying a logged-in user’s avatar without delaying the article from loading.

Content as data: collections with a schema

The second pillar for large sites is content collections. The collections documentation explains that each set of content is declared in a configuration file, with a loader, the piece that reads the data.

The glob() loader reads folders of Markdown, MDX, JSON or YAML files. file() reads multiple entries from a single file. Custom loaders can fetch data from a CMS, a database or an API.

Each collection can have a schema, a formal description of which fields each item must have and of what type. Astro uses the Zod library for this. If an article is missing a date or has a wrong field, the build reports the error. The same structure generates TypeScript types and lets you link items from different collections with reference(), such as an article linked to its author.

Two points in the documentation matter to anyone with a lot of content. Collections generated at build time are meant for “relatively static” data, can be cached between one build and the next and, according to the page, can handle “tens of thousands of entries”. For even larger volumes, the documentation itself suggests rendering pages on demand instead of generating everything at once.

The details of this feature are in the article on Astro Content Collections.

Generating thousands of routes at build time

In static mode, which is the default, Astro needs to know every route at build time. The routing documentation explains that a dynamic page, such as [slug].astro, exports the getStaticPaths() function, which returns the list of URLs to create. The paginate() function splits long lists into numbered pages, with previous and next links.

How long this takes depends on the project. The only figure published with the method and machine described comes from the Astro team itself, in the version 7 announcement. The tests ran on a MacBook Pro with an M4 Pro chip and 48 GB of memory. Some results, before and after the update:

Site	Pages (approx.)	Before	After
docs.astro.build	6,313	114.54 s	73.53 s
developers.cloudflare.com	8,431	386.89 s	261.94 s
aspire.dev	13,275	385.84 s	326.11 s

Read these numbers with caution. They were measured by the vendor, on a high-performance machine, and the page does not say how many times each build was repeated. They serve to show the order of magnitude (minutes, not hours, for sites of 6,000 to 13,000 pages), not to predict your case.

In version 5, from December 2024, the official announcement already spoke of collection builds up to five times faster for Markdown on content-heavy sites and memory usage 25% to 50% lower. That page does not describe the method either.

The configuration reference shows two settings related to large builds. cacheDir defines where artifacts reused in subsequent builds are stored. build.concurrency defines how many pages are generated in parallel. The documentation recommends keeping the default value, 1, in most cases, and warns that too high a number can make the build slower due to lack of memory.

When generating everything at build time is no longer enough

Generating all pages in advance has a consequence: to update content, you need to run a new build. On a blog, that is acceptable. On a catalog with prices that change all the time, it is not.

The on-demand rendering documentation shows the way out. With an adapter, the package that connects Astro to a server environment (Node.js, Netlify, Vercel, Cloudflare and others), you mark specific pages with export const prerender = false. They are then built on every visit, and the rest of the site stays static.

The same page recommends starting in static mode and switching the default to server only when most pages need it. For data that changes a lot, collections also have a “live” version (live collections), which fetches the data on every request but requires an adapter and does not support MDX or image optimization, according to the collections documentation.

What field data shows

Performance promises only count if they show up on real sites. The HTTP Archive technology report, an independent project that monitors the web, makes it possible to compare frameworks with real-world usage data.

The report measures the share of origins (domains) with good results on all three Core Web Vitals, Google’s metrics for loading speed (LCP), visual stability (CLS) and responsiveness to clicks and taps (INP). The assessment uses the 75th percentile of page loads, split between mobile and desktop.

In the most recent data available, for August 2026:

• Astro: 71.0% of origins on mobile with all three metrics good (43,850 origins assessed) and 83.6% on desktop.
• Average across the whole measured web: 53.0% on mobile.
• JavaScript on the home page: the median for Astro sites was about 405 KB on mobile.

That last number dispels a myth. “Zero JavaScript by default” does not mean zero JavaScript in practice: real sites add interactive components, audience analytics and third-party scripts.

The method itself also has limits. According to the HTTP Archive FAQ, technologies are detected with the Wappalyzer tool and the crawl tests only the listed URL, usually the home page, which may not represent the whole site. And there is a bias no dashboard corrects: in the editorial team’s assessment, those who choose Astro usually build content sites, which tend to be lighter than applications. The correlation does not prove that the framework, on its own, causes the result.

When Astro is not the best choice

Astro’s documentation is frank about its focus. The migrating from Next.js guide notes that highly interactive applications, such as dashboards, may require advanced techniques in Astro.

Some signs that another path may be better:

• Most of the page is interactive. If almost everything is state, forms and real-time updates, the advantage of islands shrinks.
• App-style navigation. Astro is, by default, a multi-page site. The <ClientRouter /> component turns navigation into something like a single-page app, but the transitions documentation warns that you may need to reinitialize scripts and state manually on each page change.
• Content that changes all the time, on every page. It can be solved with on-demand rendering, but then you lose part of the simplicity of a static site and have to maintain a server.
• A team already specialized in another ecosystem. The cost of learning and migrating also counts.

In these cases, app-oriented frameworks such as Next.js tend to fit better. The detailed comparison is in Astro or Next.js: architecture and performance compared.

Takeaways

• Astro was designed for content sites: HTML generated ahead of time, JavaScript only in the islands you choose.
• At scale, the gains come from three fronts: less code in the browser, routes generated from collections with a validated schema and builds with caching. The published build figures come from the vendor itself and serve as an order of magnitude.
• HTTP Archive field data from August 2026 shows Astro sites above the web average on Core Web Vitals, but the measurement covers home pages and does not isolate the framework’s effect.
• If your project is more application than publication, or if the content changes every minute, consider on-demand rendering or another framework before deciding.