rendering-models
Rendering Models
Concept of the skill
A rendering model is the strategy by which a web user interface is produced and delivered, defined by two axes that together form a grid: WHEN the work happens (build time, request time, response stream, or user interaction) and WHERE it executes (server, edge, or client). The full work of producing a UI is constant — interpret data, compose a component tree, emit DOM, attach behavior — but moving each step between those time-and-place cells has dramatic consequences for what the user sees first, how the server scales, whether the content is crawlable, and how soon the page becomes interactive. The named models in current use (CSR, SSR, SSG, ISR, RSC, streaming SSR) plus two recent additions (edge SSR, PPR) are particular cells or paths through this grid, each making a different bargain across four user-facing performance numbers (FCP, LCP, TTI, INP) and three operational properties (server cost, cache behavior, crawlability). The decisive insight is that the choice is per-route, not per-application: a site that picks one model for everything is wrong for most of its routes, because a marketing page (static content), a search-results page (per-query dynamic content), and a logged-in dashboard (personalized content) each have a different content profile that maps to a different model. This skill exists to make those trade-offs legible — to read each route's content profile and pick the model whose bargain matches — rather than to crown a single winner.
Coverage
The taxonomy of how a web user interface is produced and delivered. Covers the time × place grid (build / request / stream / interaction × server / edge / client), the six named models in current use (CSR, SSR, SSG, ISR, RSC, streaming SSR) plus two recent additions (edge SSR, PPR), their trade-offs in FCP, LCP, TTI, INP, server cost, and crawlability, and the relationship between rendering and the downstream concerns of bundling, hydration, and HTTP delivery.
Philosophy of the skill
A rendering model is a staging decision: at what moment, and in what location, does the work of producing the UI happen. The full work is the same — interpret data, compose a component tree, emit DOM, attach behavior — but moving each step between build, request, stream, and interaction has dramatic consequences for what the user experiences first, how the server scales, and whether the content is crawlable.
The model choice is per-route, not per-application. A site that picks one model for everything will be wrong for most of its routes. The correct mental model is a grid of trade-offs, with each route landing at the position that matches its content profile (static / dynamic / personalized) and its performance constraints (FCP / TTI / cost).
The goal of this skill is to make the trade-offs legible, not to pick a winner. The right model in 2026 for a marketing page is not the right model for a logged-in dashboard, and neither is the right model for a streaming chat UI.