What It Actually Means
The first response contains very little. The browser downloads the code, runs it, requests the data, and assembles the page. Everything after that is fast, because navigation updates what is already loaded rather than fetching new pages.
The Trade
What you gain: a very responsive experience once loaded, a clean separation between the interface and the data behind it, and a server doing less work per request.
What you give up: the first impression, and reliable visibility in search.
The first load is the whole cost. Nothing appears until the code has downloaded and run, which on a phone on mobile data is measured in seconds. For somebody who has arrived once from a search result, that is often the entire interaction.
Where It Is Right
Behind a login. Application screens, dashboards, admin interfaces, portals. Users arrive deliberately, use the system for a while, and return. One slower load followed by instant navigation is exactly the correct trade, and search visibility is irrelevant because the pages are private.
Highly interactive tools where state needs to persist as the user moves around.
For those cases this is the sensible default and has been for a long time.
Where It Is Wrong
Anything you want found. Search engines can run the code needed to see the content, and they do it less reliably and less frequently than they read ordinary pages. On a site with limited authority that disadvantage compounds with a constrained crawl budget: pages that are expensive to render get less attention.
Anything a stranger lands on. Marketing pages, articles, landing pages taking campaign traffic. Paying for a click and then making the visitor wait for a blank screen is an expensive way to lose them.
Anything where resilience matters. If the code fails to load, on a poor connection or with an aggressive blocker, the visitor sees nothing at all rather than a degraded page.
What To Ask
- Is this page one a stranger might land on? If yes, this is the wrong approach for it.
- What does a search engine see? Ask for a demonstration using a fetch-and-render tool rather than an assurance.
- How long until something is visible on a phone? Test on mobile data.
- Is the whole site built this way, or only the application? Uniform application is the common mistake.
How To Think About It
The useful question is not which rendering approach is better. It is who is arriving at this page and what they have already invested in getting there.
A returning user inside your application has committed to the session and will happily accept one load. A stranger arriving from a search result has committed nothing and will leave. Those two situations want opposite answers, and a well-built site gives them opposite answers rather than picking one and applying it everywhere.
Where a page needs both, being found and behaving like an application, the answer is server-side rendering rather than a compromise on either.
More terms are in the glossary.
