Teams often pick a rendering strategy by framework default and move on. This rendering strategy often decides how fast your page loads, whether search engines can read them, how stale your content gets, and ultimately how much you pay your hosting provider.
Get it wrong and you can end up server rendering a marketing page that changes twice a year, or shipping your home page as an empty shell to Google when they go to rank it.
In short, rendering strategy impacts when, where, and how your website is generated, affecting 6 key areas:
CSR generates the page's content in the user's browser, the server sends an HTML shell, the browser downloads the associated JavaScript and executes it to render the page.
CSR is great for:
However it comes at the cost of:
CSR is a poor default for public content pages because it delays initial content and can make indexing harder. Sometimes it is the only practical option, such as a static-only deployment that needs live data or a browser-only integration. See client-side fetching in Next.js for an example.
SSR generates the HTML on the server when a user requests the page. Unlike CSR, the browser receives HTML containing the rendered content without needing JavaScript to render the initial page.
SSR is great for:
However it comes at the cost of:
SSG generates HTML ahead of time, typically during the build process. This means when a user visits the website, the server delivers an existing HTML file rather than generating it on demand.
SSG is great for:
However it comes at the cost of:
ISR is an extension of SSG, it combines static page delivery with the ability to regenerate pages without rebuilding the entire website.
Users still receive pre-generated HTML pages, but individual cached pages can be regenerated using time-based or on-demand re-validation as a rebuild signal.
ISR is great for:
However it comes at the cost of:
SSW Rules uses ISR and a TinaCloud webhook to revalidate affected pages. With over 3,000 rules, a rule update takes about 7 minutes to appear.
For a code example, see Incremental Static Regeneration (ISR) in Next.js.
PPR combines static and dynamic rendering within a single page. The static portions are generated ahead of time, whilst dynamic content is rendered when the user makes a request and is streamed into the response. Loading fallbacks are shown while the server prepares the dynamic content.
PPR is great for:
However it comes at the cost of:
Choosing the right strategy starts with understanding your site's requirements, ask the following:
How often does the content change?
Is the content the same for every visitor?
Does the content need to be indexed by search engines?
How much traffic will the website receive?
How quickly must content change go live?
What is your infra and hosting budget?
Render content as early as possible, but as late as necessary. Choose the simplest strategy that satisfies your requirements, and remember that different pages within the same app can use different rendering strategies.