What is Server-Side Rendering?

With client-side rendering (CSR), all the HTML, JavaScript, CSS, images, and other assets that make up the page are downloaded to the client, and then the computation required to produce the rendered page is done within the browser.

But with SSR, the browser doesn’t need to wait for all the JavaScript to download and execute before it can display the component markup. Moving computation to the server lets the resulting page get cached in the CDN for subsequent visitors.

More benefits of SSR include:

  • faster time-to-content
  • improved SEO data freshness — data will be available whenever search engines crawl the site

Diagram comparing the First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Time to Interactive (TTI) of client-side and server-side rendering processes.

There are two ways to add SSR functionality to your site. One way is to enable SSR on a page-by-page basis. This means that you choose which pages to render on the server-side, and which to render on the client-side.

To learn how to turn on SSR for a page of an LWR on Node.js-only site, review Enable SSR for LWR Apps. If you have an Experience Cloud site, review Hydration Capabilities for Islands (Experience Cloud) instead.

If you want more granular control over which specific components on a page get SSRed, take a look at Understanding Islands. LWR supports islands architecture, which lets you determine whether components are server-rendered, server-rendered with hydration, or client-rendered. Hydration adds interactivity to a component on the client side.

Before you can set up islands on a page, you have to enable SSR for the entire page.

Before you enable SSR for your site, you have to make sure your components are SSRable. This process involves auditing, editing, and testing your components. To get started, visit Configure Components for SSR.