Performance
Server-side rendering
Also called SSR.
Server-side rendering is generating the HTML for a page on the server at request time, then sending finished markup to the browser. The visitor sees content before any client-side JavaScript runs.
How it is measured
Fetch the URL with curl and read the body. If your headline and product list are in the HTML, it is server-rendered; if you only get an empty `<div id=root>`, it is not. Time it with TTFB, because SSR moves work from the browser to the origin, so TTFB now includes data fetches and template rendering.
Track server render time per route in logs or an APM tool, separate from network latency. In field data, SSR usually improves FCP and LCP over client-side rendering, but a slow render pushes TTFB up, so watch both together.
Worked example
A marketplace listing page in Remix queries two APIs and renders 48 cards. Server render takes 310 ms and TTFB at the nearest region is 380 ms. The HTML contains all 48 titles and prices, so FCP is 1.0 s on 4G.
When the search API slows to 1.4 s at 18:00, TTFB becomes 1.8 s and every visitor waits, because the server blocks on data before sending any bytes. Caching the search response for 30 s brings TTFB back to 420 ms.
How it differs
SSR renders per request, so content is fresh but each hit costs server time. Static site generation renders once at build, so hits are nearly free but content is as old as the last deploy. Client-side rendering moves the work into the browser and sends a near-empty shell.
Common errors
Assuming SSR means fast when it can mean slow TTFB. Hydration mismatch errors. Fetching data on the server and again on the client. Putting no cache in front of an expensive render. Rendering personalised content and then caching it publicly.
In practice
Use SSR for pages whose content changes per request or per user. Measure TTFB at p75 by route, and put a short cache in front of anything that is the same for everyone. If a page changes once a day, move it to static generation.