skip to content

What happens to a prerendered site's build when every route must also exist in each of ten languages?

level: middleimportance: should knowfreq 48%

answer

  1. a cross product, not a list
  2. paths times languages
  3. build time scales with the multiplier
  4. tier languages, render the tail on demand
  5. shard the build per language

basics

~20 s

The build output becomes roughly paths times languages: every route is rendered once per language, so build time, artifact size and deploy time scale with the language count. Teams bound it by prerendering only high-traffic languages and rendering the rest on demand.

solid answer

~50 s

Adding the language as a route dimension multiplies the prerendered surface: 4,000 paths in ten languages is up to 40,000 rendered outputs, each with its own HTML and its own data fetch. Build time, peak memory, artifact size and deploy time all grow with it, and the step that enumerates which paths to build now has to yield the cross product rather than a flat list. It is often worse than the arithmetic suggests, because pages that were never translated are still rendered once per language, and per-language data is fetched per page rather than once. The usual containment is to tier the languages — prerender the few that carry most traffic, render the rest on first request and cache the result, or regenerate on demand — and to shard the build so languages render in parallel. The trade is a slower first request for the long-tail languages in exchange for a build that stays finishable.

go deeper

for a junior

Hold on to the arithmetic: with the language in the route, the build renders each page once per language, so ten languages means roughly ten times the output.

for a middle

Explain what actually scales — render count, wall time, peak memory, artifact size — and why untranslated pages and per-page data fetches make the real cost worse than the raw multiplier.

for a senior

Show the containment strategies and their price: tiering languages and rendering the tail on demand moves cost to the first request, sharding multiplies infrastructure, narrow rebuilds need trustworthy change attribution.

for a principal

Own the policy: which languages earn a prerendered build, what first-request latency the long tail may have, and what build duration the team will tolerate before the site stops being rebuilt at all.

Prerendering trades request-time work for build-time work: every page a visitor might ask for is rendered once, ahead of time, into a finished artifact. Introduce the language as a route dimension and that set stops being the list of paths and becomes the **cross product of paths and languages**. ## Where the multiplication comes from A prerendering build needs a finite, enumerable list of addresses. With one language, that list is the routes plus whatever dynamic values each dynamic route expands to. With the language as the outermost segment, every entry in that list appears once per language, because each language URL is a genuinely different address with a genuinely different body. Four thousand paths in ten languages is up to forty thousand renders — not four thousand renders with ten string tables applied afterwards. ## What grows with it | What | How it scales | Why it hurts |---|---|---| | **Render count** | paths x languages | the dominant term; every render is a full page render | | **Build wall time** | roughly linear in renders | a 12-minute build becomes a two-hour build | | **Peak memory** | with concurrency, not with total | large builds die on the machine, not on the clock | | **Output size** | paths x languages x page weight | slower uploads, slower deploys, bigger artifacts to retain | | **Invalidation blast radius** | usually per language | a change in one language's copy should not rebuild the other nine | ## Why it is worse than the arithmetic - **Untranslated pages are still rendered.** Nothing in the build knows a page has no translation; it renders it once per language and emits near-identical artifacts. - **Data is fetched per rendered page, not per path.** Unless results are shared across languages, the same records are read ten times. - **Long-tail languages cost as much as the main one.** The language nobody visits takes exactly as long to render as the one carrying most of the traffic. - **The dynamic values themselves may be per-language.** If article slugs are translated, the path list is not one list reused ten times but ten different lists. ## Ways to keep it bounded 1. **Tier the languages.** Prerender the handful that carry most traffic; leave the rest to be rendered on first request and cached afterwards. Most meta-frameworks support exactly this split, though they name it differently. 2. **Render on demand and keep the result.** The first visitor to a cold long-tail page pays one render; everyone afterwards is served from cache, and the build never sees that page. 3. **Shard by language.** Languages are independent, so N build jobs each doing one language parallelise almost perfectly — at the cost of repeating any shared setup per job. 4. **Rebuild narrowly.** Scope a content change to the languages it actually touched instead of rebuilding the cross product. 5. **Prune the path list per language.** If a section only exists in three languages, do not enumerate it for the other seven. ## What each costs Tiering and on-demand rendering move work from the build to the first request, so the first visitor to a cold page waits for a real render, and a spike of cold traffic is a spike of server work rather than a static file read. Sharding multiplies build infrastructure and makes the pipeline harder to reason about. Narrow rebuilds need reliable change attribution — get it wrong and stale pages survive a deploy. None of these remove the multiplication; they decide who pays for it and when. ## A quick estimate before you commit Before adding the segment, measure one render and multiply honestly: - **Time one page render in the build**, including its data fetches, then multiply by paths and by languages; that number is the floor, not the estimate. - **Check what the dynamic values cost.** If the path list is itself per language, the enumeration step runs once per language too. - **Look at the deploy, not only the build.** Uploading and retaining ten times the artifacts has its own ceiling, and rollbacks get slower with it. - **Ask which languages have traffic.** The answer is usually lopsided enough that tiering is obvious once the numbers are on the table. ## Rule of thumb Treat the language count as a multiplier on everything the build does, and decide deliberately which languages earn a prerender. A build that takes hours is not just slow — it stops being run, and a site nobody dares rebuild drifts out of date in every language at once.

  • If only three of ten languages are prerendered, what does a visitor to one of the other seven actually get?
    Their first request is rendered at request time rather than read from a finished file, so it is slower — a real render plus its data fetches. Most setups then store that output so later visitors are served like a prerendered page. The risk is a cold-traffic spike in an untiered language landing entirely on the renderer at once.
  • Why does a language whose content is identical to another still cost a full render?
    The build renders addresses, not diffs. Two languages that happen to share copy are still two distinct URLs producing two distinct artifacts, and nothing compares them. The only way to avoid the cost is to not enumerate that language's paths at all, or to serve it from the other language's URL.

saying these in an interview costs you the question

  • Thinks the build renders once and substitutes strings per language when serving
  • Assumes untranslated pages are skipped by the build automatically
  • Expects build time to stay flat as languages are added
  • Believes adding a language only adds translation files, not outputs
  • Ignores that a change in one language can trigger a full cross-product rebuild