SSR, or server-side rendering, means the server assembles the complete HTML for a page every time someone requests it. Instead of sending a near-empty shell that the browser has to fill in, the server fetches the data, builds the page, and sends back something the visitor can read at once.
Picture ordering a meal cooked to order versus grabbing one from a fridge. A pre-made dish (a static page) is instant but identical for everyone. A cooked-to-order meal (an SSR page) takes a moment longer but can be tailored to exactly what you asked for. That makes SSR the right fit for content that depends on who is logged in or on data that changes constantly.
The main trade-off is cost and speed per visit. Because the server does work on every request, it can be slower than handing over a finished file from a static site, and your Time to First Byte needs attention. Caching and rendering only the parts that change keep things quick. After the HTML arrives, the page often goes through hydration so it becomes interactive.
It helps to contrast it with a single-page application, which ships a blank shell and builds everything in the browser. That works for an app behind a login, but a search engine or a slow phone sees nothing until the script runs. Frameworks like Next.js and Astro now mix both: render the first view on the server, then let the browser take over. So you are rarely choosing SSR for the whole site, but page by page where the data is fresh or personal.
At TopDevs we reach for SSR when a page must show personal or real-time data, and we cache aggressively so visitors still get a fast first paint.
