skip to content

An editor fixes a typo on a page prerendered at build time, but the live site still shows the old text. Why, and what would you put in place?

level: seniorimportance: should knowfreq 50%

answer

  1. the page is a photograph of build-time data
  2. serving never consults the source
  3. publishing is now a release
  4. build lag plus deploy plus cache lifetime
  5. trigger the build from the publish event

basics

~20 s

The deployed page is a file rendered from the data as it stood during the build, and serving it never consults the source. The correction ships when a new build runs and deploys, so publishing needs an automatic rebuild trigger.

solid answer

~50 s

Nothing is broken: build-time prerendering froze that page when the build ran, and serving it is a file read that never touches the content source. So the edit is live in the source and absent from the artifact, and it reaches users when a new build renders that route again and the deploy replaces the file — plus however long a cache in front keeps serving the old bytes. What I would put in place: a rebuild triggered by the content source on publish rather than by a human remembering; an agreed publish-latency budget with the editors, measured from publish to visible; a preview route that renders per request so editors can verify before the rebuild; short-lived caching or a purge at deploy for prerendered HTML, so the edge does not extend the staleness window; and a rule that route families whose corrections are urgent should not be on this mode at all.

go deeper

for a junior

Remember that a prerendered page holds the data from the moment of the build, so a later edit cannot show up in it until something produces the page again.

for a middle

Explain the whole chain — build renders, deploy replaces, cache may still hold — and be able to say which link you would check first when staleness is reported.

for a senior

Show the operational answer: automate the rebuild from the publish event, budget publish-to-visible latency, give editors a preview, and keep the edge from extending the window.

for a principal

Argue the boundary: which content families may live behind a release pipeline at all, what latency the business accepts, and when to move a family to a fresher mode instead.

This is the defining property of build-time prerendering, seen from the editor's side: **the page is a photograph, and the shutter closed when the build ran**. ## Why the old text is still there Three facts stack up: 1. The route's data loading ran **during the build**, against the content source as it stood then. 2. The result was serialised to HTML and written into the build output as a file. 3. Serving it is a file read. No request re-consults the content source, so no edit to that source can reach the visitor through the existing file. And then a fourth, often forgotten: even after a new file is deployed, anything caching the old response — an edge cache, a proxy, the browser — keeps serving what it has until its own freshness rules expire or it is purged. The staleness a user experiences is *build lag plus deploy time plus cache lifetime*. ## Publishing has become deploying The organisational consequence is bigger than the technical one. On a per-request-rendered site, publishing is an editorial act: save, and the next request shows it. Under build-time prerendering, publishing is a **release**: a build runs, an artifact is produced, a deploy swaps it in. That changes who can publish, how fast, and what a bad publish costs. The questions that follow are all operational: - Who or what triggers the build when an editor publishes? - How long does the build take, and is that the same as the time-to-correction for an urgent fix? - What happens if the build fails at 22:00 on a Friday — does the correction simply not ship? - Can an editor see their change anywhere before it is live? ## What to put in place | Lever | What it fixes | What it costs | |---|---|---| | A publish event from the content source that triggers a build | Human latency and forgotten deploys | Build runs on someone else's cadence; needs debouncing against edit storms | | An agreed publish-latency budget (publish → visible) | Turns a vague complaint into a measurable target | Forces a build-duration budget to match | | A preview route rendered per request | Editors verify before the rebuild | A second render path to keep consistent with the real one | | Rebuilding only what changed, where the tooling supports a persistent build cache | Keeps the trigger practical on a big site | Cache-correctness risk: a stale build cache can re-emit old pages | | Short freshness for prerendered HTML, or a purge at deploy | Stops the edge extending the window | More origin hits, or a purge step that must not be skipped | | Moving urgent-correction routes off this mode | Removes the class of problem | Loses the per-request cost profile for those routes | A meta-framework may also offer refreshing a prerendered page out of band, without a full rebuild; that is a separate render mode with its own semantics rather than a property of build-time prerendering, and it is the other honest answer when the rebuild cadence cannot be made fast enough. ## Diagnosing it when it is reported Work outwards from the artifact: 1. **Is the fix in the source?** Confirm the edit is actually published, not saved as a draft. 2. **Did a build run since?** Compare the deploy timestamp with the edit timestamp — most reports end here. 3. **Did that build include the page?** If the enumeration filters on a published flag or a date, a newly edited item can still be outside the list. 4. **Is the deployed file correct?** Fetch the page bypassing the cache. If those bytes are right, the problem is caching, not building. 5. **Is something in front still serving the old copy?** Then the fix is a purge or a shorter freshness window on HTML, not another build. ## The judgment an interviewer is listening for Not "rebuild it" — that is the mechanism, and everyone gets there. The judgment is recognising that the mode has moved publishing into the release pipeline, and that the right response is either to automate and budget that pipeline, or to admit this route family was a bad fit for build-time prerendering and pick a mode whose freshness matches how urgently its content changes.

  • The fix was deployed, yet some users still see the old text. What now?
    The artifact is correct and something in front of it is not. Fetch the page bypassing caches: if those bytes are right, the old copy is being held by an edge cache, proxy or browser. Fix it with a purge at deploy or a shorter freshness window on prerendered HTML.
  • How do you let editors check a change before the rebuild?
    Give them a preview path for the same route that renders per request against the live content, including unpublished drafts, behind authentication. It answers "will this look right" without waiting for a build, as long as it renders through the same components as production.
  • When should you conclude that build-time prerendering is the wrong mode for a route family?
    When the content's change cadence is faster than the pipeline can rebuild and deploy, or when corrections are urgent enough that build lag is a business risk. At that point pick a mode whose freshness matches the content instead of optimising the build around it.

A printed catalogue: correcting a price in the database does nothing for the copies already posted. The correction ships with the next print run, and whatever is still on the shelf keeps the old figure.

saying these in an interview costs you the question

  • Thinks a prerendered page re-reads the content source when someone visits it
  • Blames caching before checking whether a build ran at all
  • Treats a rebuild as instant regardless of how long the build takes
  • Ignores that an edge cache extends staleness after the deploy
  • Leaves publishing to a human remembering to trigger a deploy
  • Keeps urgent, fast-changing content on build-time prerendering anyway