When Is a Page Built? Build Time, Request Time, and Browser Time

“Rendered” is too vague until you name when and where

A teammate says, “This is an SSR page,” and points to one label as if every part of the page is produced in the same place at the same moment. Another teammate says, “It becomes client-rendered because JavaScript runs later.” Both descriptions can hide the real architecture question: which responsibility happens before a user asks, which happens while handling a request, and which happens after the response reaches the browser?

This lesson builds Rendering Placement Timeline v1. The artifact does not force one timing label onto an entire page. It records each bounded responsibility, its placement at build time, request time, browser time, or a justified hybrid boundary, plus the evidence and uncertainty behind that placement.

By the end, you should be able to discuss timing without treating “SSR,” “CSR,” “static,” “dynamic,” or “hydration” as substitutes for a responsibility map.

Carry forward two boundaries, not two whole lessons

WEBF-001 is the hard prerequisite: keep the browser–server request/response boundary. WEBF-003 is the soft prerequisite: keep the distinction between a response that is already produced before a request and a response generated from current request/server context.

This page owns only rendering and generation timing inside the split WEB-000 mental model. It does not teach a framework, define a universal performance ranking, close WEB-000, or claim that every page has exactly one rendering time.

Use three timing locations, then allow hybrids

The minimum model has three responsibility locations.

Build time — before the specific user request. A build or deployment process can turn source content/data/templates into artifacts before traffic arrives. When a later request receives that already-produced artifact, the generation responsibility for that artifact happened before the request. This is a timing placement, not a claim that the page can never change again.

Request time — after a request arrives, before the response is sent. A server-side application can inspect the request or current server-side data and generate the response representation during request handling. MDN’s client/server overview describes this request/response generation boundary for dynamic sites. [S-MDN-CS]

Browser time — after the response reaches the browser. The browser processes returned HTML and related resources to display the page, and client-side code may activate or update behavior after delivery. In React specifically, hydrateRoot is one example in which client logic attaches to HTML that was generated on the server; this vendor example is not a universal requirement for browser rendering. [S-MDN-CS] [S-REACT-HYDRATE]

A single feature can use all three. The model therefore classifies responsibilities, not whole pages.

Record a responsibility, its trigger, and its uncertainty

The Rendering Placement Ledger is the row-level evidence table inside Rendering Placement Timeline v1; it is not a second artifact. For each bounded responsibility, record:

• Observed fact/requirement: what the scenario actually says.
• Responsibility: what must be produced, selected, rendered, activated, or updated.
• Placement: BUILD_TIME, REQUEST_TIME, BROWSER_TIME, HYBRID, or UNKNOWN.
• Trigger/input: deployment/build input, request data, current server state, browser state, user interaction, or another stated cause.
• Rationale: why the placement follows from the evidence.
• Uncertainty/constraint: what is not yet known or what could invalidate the placement.
• Next evidence: what you would inspect before strengthening the claim.

Two checks prevent category collapse: When must this responsibility have enough information to run? and Where does that information become available?

Generation time and display time are related, not identical

Build-time generation does not mean “non-interactive”

An HTML shell can be generated before traffic and still load JavaScript that adds browser-side behavior after delivery. The generation of the shell and the later browser behavior occupy different rows in the timeline.

Request-time generation does not mean “always fresher”

A server can generate a representation during a request and still use cached, delayed, or stale inputs. Freshness depends on the data and invalidation path, not only on the moment the template runs. This lesson therefore records freshness requirements as constraints rather than universal properties.

Browser-time rendering does not imply the server did no work

The browser ultimately displays the returned document, even when the server generated HTML first. React hydration makes this separation easy to see: the server-generated HTML exists first, then client logic attaches in the browser. [S-REACT-HYDRATE]

“SSR” and “CSR” can hide mixed responsibilities

A page may pre-produce one shell, compute another bounded fragment during a request, and activate separate interactive state in the browser. A single acronym can be useful shorthand in a specific stack, but the decision record must still locate each responsibility and its evidence.

Contrast cases without turning labels into rules

Case 1 — deployment-built release notes

A release-notes document is generated during deployment and served as the same produced artifact until the next release. Place document generation at build time. When a user visits, the browser still processes and displays the returned document at browser time. Do not conclude that “build-time” means “the browser does nothing.”

Case 2 — request-specific shipping estimate

A shipping estimate depends on the destination and inventory state available when the request is handled. Place estimate generation at request time if those inputs must affect the returned response. Do not infer that every other part of the page must also be request-time generated.

Case 3 — browser-only disclosure control

The response already contains the article text and a collapsed disclosure. Clicking the control changes the displayed state locally. Place that interaction/update at browser time. This says nothing by itself about when the original article HTML was generated.

Guided realistic case — product page

The shell is generated before traffic, the price is computed per request, and wishlist state activates in the browser. Do not copy a model answer. Add three rows to Rendering Placement Timeline v1, justify each placement, and state one thing the scenario still does not prove.

Two blocking misconceptions

Failure 1: “Rendering happens either on the server or in the browser.” This compresses multiple responsibilities into one event. Repair it by separating generation of a representation from browser processing/activation and by allowing multiple rows.

Failure 2: “Build-time output is forever stale.” Build-time generation says when an artifact was produced, not that no regeneration, later request, or browser update can ever occur. Repair it by recording the update mechanism and freshness constraint separately.

A related warning: hydration is not a universal synonym for browser rendering. React’s hydrateRoot describes a specific React operation on server-generated HTML. Use it as an example of a boundary, not as the definition of all browser-time rendering. [S-REACT-HYDRATE]

Architecture-review language that survives framework changes

Replace a page-wide label with a bounded statement such as:

“The event-guide shell is produced during deployment; request-time work selects a signed-in attendee notice from current session state; browser-time work expands local session details after delivery. This placement remains valid only while the guide can wait for the next deployment, the notice must be present in the returned response, and the expansion uses already-delivered data.”

The value is not the wording. The value is that the statement names responsibility, timing, input, and invalidation condition. If a framework changes, the reasoning can still be reviewed.

For experienced review, keep four categories distinct: observed fact, design/inference, uncertainty, and non-claim. A stack name belongs after the timing decision, not in place of it.

Choose placement per responsibility

Use build time when the needed inputs are available before requests and the acceptable freshness window permits pre-production. This can reduce request-path work, but may create rebuild or invalidation responsibilities.

Use request time when the response itself must depend on request/current server context that cannot be deferred. This enables contextual response generation, but adds work and dependencies to the request path.

Use browser time when the responsibility depends on browser-local state or post-delivery interaction, or when the product deliberately defers that work. This can avoid server-side coupling for that concern, but may depend on client capabilities and may occur after initial content is visible.

Use HYBRID for a row only when one bounded responsibility genuinely spans more than one timing boundary and splitting it would destroy the claim you are evaluating. Different responsibilities having different placements makes the feature mixed, but does not by itself justify a HYBRID row: split those responsibilities into separate rows. “Hybrid” is not an escape hatch; a hybrid row still needs the crossed boundaries, rationale, uncertainty, and next evidence.

Fade the labels

Guided pass: classify these three responsibilities separately: a navigation shell generated during deployment, an access message selected from current account permissions during the request, and a tab switch performed after a click in the browser.

Less-guided pass: remove the timing labels. For each responsibility, first write when its decisive input becomes available, then choose a placement.

Independent pass: use the product-page case from the Bible: shell before traffic, price per request, wishlist activation in the browser. Complete the record without using “SSR” or “CSR” as the rationale. Add at least two non-claims and one piece of evidence that could change a placement.

If evidence is missing, UNKNOWN is a valid temporary placement. Guessing is not.

What sufficient evidence looks like

A reviewable record lets another person reconstruct your reasoning:

The final Rendering Placement Timeline v1 must include explicit non-claims and must not claim ownership of the whole WEB-000 canonical or the chapter exit. No executable coding Lab is required because the construct under test is responsibility placement and architecture judgment, not implementation syntax.

Assessment and transfer

Five evidence types are used:

1. Retrieval: distinguish build, request, and browser time and state a non-claim.
2. Application: place independent responsibilities in a new mixed feature.
3. Diagnosis: repair a page-wide timing claim that collapses server generation and browser work.
4. Decision: choose a bounded placement and record uncertainty and invalidation evidence.
5. Transfer: complete Rendering Placement Timeline v1 for the product page whose shell is generated before traffic, price is computed per request, and wishlist state activates in the browser.

Diagnosis, decision, and transfer are blocking. A stack acronym alone is not evidence. The response must expose timing, responsibility, rationale, uncertainty, and non-claims.

Declared sources and freshness boundary

This lesson uses only the two sources frozen in the Bible:

• S-MDN-CS — MDN Client-server overview: request/response processing and server-side generation boundary.
• S-REACT-HYDRATE — React hydrateRoot: a current vendor example of client logic attaching to server-generated HTML; not a universal rendering requirement.

Both declared sources were rechecked on 2026-09-10; their required claim boundaries still match the Bible. The source set was not expanded. Review is due no later than 2026-12-31, or earlier if the vendor/framework terminology or the relevant page changes.

Final boundary: this lesson does not claim that a page has one rendering time, that build-time output cannot become interactive, or that request-time rendering is always fresher or better.