SSR, SSG or hybrid: the question almost nobody asks right

The question we get asked is “what’s better, SSR or static?”, and that question is already framed wrong. It’s like asking whether a car or a van is better without saying what you’re going to haul.

SSG (static site, generated at build time) means the pages are built once and served identically until the next deploy. It’s extremely fast, cheap to host and almost impossible to bring down with traffic, because there’s nothing to compute on each visit. The price is that content doesn’t change on its own: if something updates at the source, the site has to be rebuilt.

SSR (server-side rendering on every request) makes sense when content changes all the time or depends on who’s viewing the page: a property listing with filters, a price that varies with stock, a panel where each user sees something different. Here you do need a server running, not just static files, and that comes with an infrastructure and complexity cost you have to take on.

Hybrid, part static site and part server-rendered, is what we use in most serious projects, even though almost nobody asks for it that explicitly. In a real estate project we work on, for example, the fixed-content pages (about us, privacy policy) are static, while the property listings, which change with available stock, run on SSR.

The mistake I see repeated is choosing the architecture based on what sounds more modern instead of on how the project’s actual content changes. I’ve seen entirely SSR sites for content that updates once a month, paying for a server running 24 hours a day to render exactly the same thing over and over. And I’ve also seen the opposite mistake: static sites where someone tries to bolt on dynamic functionality with client-side JavaScript, when what they needed from the start was SSR.

The right question, before looking at frameworks, is how often each part of this site changes and who needs to see it updated to the second. That answer decides the architecture, not this quarter’s trendy framework.