In a CSR app the server sends a shell and a script; the script fetches data and constructs the page. For app-like interfaces behind a login — dashboards, editors — this is often fine: the user already has the app loaded and wants interactivity, not a first impression.
For public pages it is an expensive choice: crawlers may run your JavaScript slowly or not at all, link previews show nothing, and the 'Largest Contentful Paint' happens when the app finishes booting on the user's phone. That is why content sites moved to SSR and static generation — the page should exist before the JavaScript does.
Related terms
Server-side rendering (SSR)
Generating the page's HTML on the server per request — the browser gets a complete page, not a loader and a promise.
Hydration
The step where JavaScript takes over server-rendered HTML in the browser and makes it interactive.
Core Web Vitals
Google's three field metrics for loading, responsiveness and visual stability, measured on real visits rather than in a lab.
The bench this belongs to
Full-stackIf you can describe it, we can build it. React and Next.js on the front, Python or Node behind, Postgres underneath, shipped to somewhere you can afford to run.
