# Precomputation

> Do expensive work before anyone asks for it, so a request reads a ready answer instead of building one.

Precomputation moves work from request time to a moment you choose, such as a build, a schedule, or a write.

## Use it when

- Many users get the same answer, such as a product page or a leaderboard.
- The answer is costly to build but changes rarely.
- A small delay between a change and its appearance is acceptable.

## How it works

A static site generator renders every page at build time and uploads files, so a request costs a file read. Incremental static regeneration, as Next.js does it, renders a page on first request, keeps the result, and rebuilds it in the background after a set time. Search indexes, recommendation lists, and daily reports follow the same plan: a job computes them, and requests read the output.

A page rendered once and read 100,000 times spends its cost once. Putting a CDN in front of the files makes the repeat reads nearly free.

## What it costs

You pay for work no one may ever read, and you must decide when to rebuild. Pages that depend on the user cannot be shared. A change shows up late, and a purge or a revalidate is the only way to force it. Large sites can spend minutes rebuilding.

## In Quorum

Two controls get close. The Framework on an [App Server](https://wiki.playquorum.dev/components/server.md) can be Next.js, after [Next.js](https://wiki.playquorum.dev/research/fw-nextjs.md) and [Node](https://wiki.playquorum.dev/research/lang-node.md), which renders a share of pages as static output that a [CDN](https://wiki.playquorum.dev/components/cdn.md) can cache. Report reads can use a Database view, which [Materialized views and denormalization](https://wiki.playquorum.dev/patterns/materialized-views-and-denormalization.md) covers.



[CDN push and pull](https://wiki.playquorum.dev/patterns/cdn-push-and-pull.md) covers the cache layer in front.

Source: https://wiki.playquorum.dev/patterns/precomputation