Server-side rendering sends back a finished page rather than the bones of one. The browser shows something useful before any JavaScript runs; hydration fills in the interactivity afterwards.
In plain language
On the web, this term comes up when people talk about how pages, apps, and services are built or connected. Server-side rendering sends back a finished page rather than the bones of one. The browser shows something useful before any JavaScript runs; hydration fills in the interactivity afterwards. If you are new to the field, the simplest mental model is this: rendering the first paint on the server. Read it once with that frame in mind, then come back and read it again — that is usually enough for the rest of the entry to make sense.
An everyday picture
Think of Server-side Rendering as part of the doorway between a person and a machine. People see the door — the page that loads, the button that responds — and barely notice the hinges. Server-side Rendering is one of the hinges.
Where it shows up
You meet Server-side Rendering in almost every website, app, and dashboard. The piece itself is invisible; what you notice is the page that loads, the field that updates, the screen that fits the phone in your hand.
A small example
Imagine the scene above. The role Server-side Rendering plays is the one its blurb describes — Rendering the first paint on the server. Every time a page loads or a button fires a request, ideas like this are quietly doing the work between the browser and the server.
Common misunderstanding
One line to take with you
Server-side Rendering is part of the surface between people and machines. The user sees the result, never the seam.