As the lead of a site where most routes prerender at build, how would you govern which routes stay that way as it grows?
answer
- cheap per view, expensive per publish
- duration is pages times per-page cost
- cap the enumeration deliberately
- build time is also recovery time
- decide per family, with an owner
basics
~20 sTreat build duration as a budget with an owner. Prerender families whose content changes on the deploy cadence and whose page count is capped to a valuable slice; move per-user, fast-moving and long-tail families to another mode.
solid answer
~50 sI would make it an explicit policy rather than an accumulation of defaults. Build duration is roughly the number of enumerated pages times the per-page cost of data loading and render, so a growing catalogue turns the build into a shared constraint every team pays for — and since a rebuild is how content is published, it is also publish and correction latency. The policy I would set: prerender families whose content changes no faster than we deploy and whose enumeration is explicitly capped to a valuable slice rather than to everything; leave the tail to render on request; forbid the mode outright where the page is per-user. Then I would instrument it: build duration and page count per family reported per build, with a threshold that opens a review, and each family's mode a recorded decision with a named owner.
go deeper
Take away the shape of the tradeoff: prerendering is cheap to serve and costly to rebuild, so bigger page counts mean slower publishing.
Be able to estimate a build: enumerated pages times per-page data loading and render, and say which families have a bounded count.
Show you would cap enumerations, pair them with a fallback for the tail, and measure build duration per family instead of discovering it during an incident.
Own the policy: a stated publish-latency service level, a budgeted build owned by someone, per-family mode decisions, and the willingness to refuse the mode where it technically works but harms recovery.
Build-time prerendering is cheap per view and expensive per publish, and both halves of that trade scale with the size of the site. Left ungoverned it degrades the same way in every organisation: the build grows page by page until someone notices that shipping a one-word fix takes forty minutes, and by then the mode is load-bearing across dozens of route families. ## The inputs a policy has to weigh - **Change cadence versus deploy cadence.** The mode is only honest when a family's content changes no faster than the pipeline rebuilds and deploys. Documentation: fine. A price that marketing edits hourly: not fine. - **Page count and its growth rate.** Build duration tracks *enumerated pages × (data loading + render)*. The number that matters is not today's count but its slope, and whether the enumeration is capped or written as "everything". - **The value distribution across the family.** Catalogue traffic is usually heavily skewed. Prerendering the whole tail buys build minutes for pages almost nobody requests. - **Personalisation.** Anything that differs per viewer cannot be one shared file, and no amount of build budget changes that. - **Recovery latency.** Because publishing is a deploy, build duration is also how long a bad page stays wrong. That makes it a risk number, not only a developer-experience number. - **Who pays.** The build is shared infrastructure. One team's enumeration change slows every other team's releases, which is precisely why the decision cannot live only inside a route file. ## A policy that holds up 1. **Default by family, not by route.** Decide the mode for "marketing", "docs", "catalogue detail", "account" once, write it down, and make an exception require a reason. 2. **Cap every enumeration.** An enumeration should express a deliberate slice — published items, the primary locale, the top segment by traffic or recency — never an unbounded "all rows". Uncapped lists are how build duration escapes. 3. **Give the tail somewhere to go.** Pair a capped enumeration with a fallback for unenumerated paths so coverage does not depend on build size, and so the cap can be tightened without breaking links. 4. **Budget the build.** Put a number on total build duration and on per-family page count, publish them with every build, and make crossing the threshold open a review instead of a complaint three sprints later. 5. **Make publish latency a stated service level.** Editors should know the publish-to-visible figure and be able to hold the pipeline to it; engineers should know that halving the build halves an operational risk. 6. **Re-decide on triggers, not on a calendar.** A family's mode gets revisited when its page count crosses a multiple, when its change cadence changes, or when personalisation enters it. ## Where the families usually land | Route family | Typical fit | Why | |---|---|---| | Marketing and landing pages | Build-time | Small, deliberate, changes with releases | | Documentation and reference | Build-time | Versioned with the code, bounded page count | | Catalogue detail, head of the distribution | Build-time, capped | High value per page, cost worth paying | | Catalogue detail, long tail | On request | Cheap to render rarely, ruinous to prerender in bulk | | Search results and filtered listings | On request | Combinatorial path space, no meaningful list to enumerate | | Anything per-user | Never build-time | One shared file cannot carry per-viewer content | ## What the policy is trading away Being explicit costs something and it is worth naming. A capped enumeration means two serving paths for one family, with two freshness stories and a subtle class of "it is fast for some pages" reports. A build budget means someone has to own a number that no feature ticket asks for. And a review gate adds friction to a change that would otherwise be one line in a route file. The alternative, though, is that the mode is chosen implicitly by whoever wrote the enumeration first, and the bill arrives as a slow build that nobody has the mandate to fix. ## The signal of a strong answer A principal-level answer treats build duration as a shared, budgeted resource with an owner, connects it to publishing and to incident recovery rather than to developer convenience alone, and is willing to say which families should *not* be prerendered even though prerendering them would technically work. An answer that only says "prerender what you can, it is faster" has not understood which cost moved, or onto whom.
- Why is build duration a risk number and not just a developer-experience number?Because a rebuild is how content is published on this mode, the build is also the fastest a wrong page can be corrected. A forty-minute build means a forty-minute floor on fixing a bad price or an incorrect statement, before any cache in front is considered.
- What is the cost of capping an enumeration and letting the tail render on request?One route family now has two serving paths with different freshness and latency profiles, so reports like "it is slow, but only sometimes" become normal. It also needs a fallback that is cost-guarded, since unenumerated paths become work the origin performs on demand.
- How do you stop route families from drifting into the build budget unnoticed?Report per-family page count and build duration with every build, set a threshold that opens a review, and require the mode for a family to be a recorded decision with an owner. Without a published number, the slide is invisible until it is painful.
saying these in an interview costs you the question
- Prerenders everything on principle without a build budget
- Writes enumerations as all rows with no cap or filter
- Treats build duration as a developer annoyance, not a publishing constraint
- Decides the render mode per route by habit rather than per family by policy
- Ignores that one team's enumeration slows every other team's release
- Keeps per-user routes on build-time prerendering and patches around it