In the decoupled era with headless content management systems and APIs, SSR is still being used as it overcomes some of the challenges with other rendering techniques:
- SSG websites: build times and dynamic content
- Single page application (SPA) websites: first page load performance and SEO
However, there are also some disadvantages to SSR. For example, performance and scalability, which become more challenging. For SSR to deliver high performance, the APIs must be high performing and you only have a performance budget for one API request per page view.
Additionally, SSR can place a higher load on both the server rendering the HTML and the API servers, which can lead to slower response times and increased server costs. Often you want to leverage a reverse proxy cache such as Cloudflare or Varnish when going for SSR - but then you have to manage cache invalidation.
How to implement this pattern
First, choose a framework which supports SSR, such as Next.js, Remix, SvelteKit, Gatsby, Nuxt, etc. Pick the one that suits your requirements best.
Next, fetch your content from Enterspeed using the API credentials from your Environment client created in Enterspeed. You can implement a helper function to fetch pages (fetch via URL) or components (fetch via handle) more easily.
💡 INFO: If you develop using Next.js and their App Router, which uses React Server Components (RSC), use the
cache: 'no-store' option to fetch fresh data on every
fetch request. Read more about Dynamic Data Fetching in Next.js.
Lastly, connect your Git repository with a hosting provider that supports SSR, such as Netlify, Vercel, Cloudflare Pages, etc. and deploy your site.