Steven Ly's Developer Portfolio

Rendering Strategies: SSG vs SSR vs CSR vs ISR

Steven Ly's profile imageSteven Ly
Rendering Strategies: SSG vs SSR vs CSR vs ISR's cover image

As you journey through learning NextJS one of the more popular meta-frameworks for JavaScript. You might have heard of these acronyms, SSG (Static Site Generation), SSR (Server Side Rendering), CSR (Client Side Rendering), and ISR (Incremental Site Regeneration)

I'll give you a short and sweet description of each that makes it easy to understand what they are, their drawbacks, and use cases.


Server Side Rendering:

Generating the HTML content on the server before delivering it to the client. Amazing for Site Engine Optimization, allowing Search Engines to crawl your website easily. One of the first traditional approaches to web development before React using HTML, CSS, and Javascript, with frameworks such as Ruby on Rails, Django and Laravel.


Pros:

  • Site Engine Optimization
  • Faster Initial Page Loads: (no waiting on huge Javascript bundles as you scale)

Cons:

  • Slow Time to First Byte: (How responsive your server is compared to when you make the action on the client) i.e. Waiting on the server to render your page after you click a button on a different one.
  • Server Latency: Servers are distributed throughout the world. You might be in California and the server you're requesting might be in the Netherlands, increasing the time it takes to get to you (the client) (See the workaround on how React & NextJS handles this)
  • Server Load: when everything is hitting your server and generating your content, spikes in traffic could bring down your server if not handled correctly (horizontally and vertically scaling)

When to use:
Use for when SEO is crucial for an app or website, where faster initial page loads are important as well as for an application that has consistent dynamic data.
This includes E-commerce websites, News Portals, and Social Media Platforms.

Image credits: React PWA

Static Site Generation:

Rendering all the HTML files and content in advance (at build time). Usually placing them on a CDN or server, to be served when a client requests the Page.


Pros:

  • Performance: Static sites are incredibly fast because they consist of pre-built files served directly to the browser, eliminating the need for database queries or complex back-end processing at request time.
  • Scalability: Serving static files can be efficiently handled via CDN allowing for global distribution and high traffic without pressure on the server.

Cons:

  • Constant Building: These pages are rendered at build time before being served via a server or CDN. Every time data is updated the pages must be built resulting in more builds, costs, and less flexibility.
  • Interactivity: Things such as fetching data from a server for real-time data and updating your view are unavailable in this approach.

When to use:
Websites where speed and loading time are crucial for user experience. Sites expecting huge amounts of traffic where content is not changed often.
This includes portfolio websites such as this one, documentation and blogs.

Incremental Site Regeneration:

A new concept that combines SSR and SSG. Pre-rendering static pages at build time, while also being rebuilt periodically or on-demand when needed.


Pros:

  • SEO & Speed: Since the pages are statically generated they inherently gain the same benefits as Static Site Generation.
  • Building: Reduced build times can save you not just money but time as well. As it only has to rebuild the selected pages when data and content are updated

Cons:

  • Stale Content: There is a possibility that the user will be served stale content (old content) while the page is being regenerated.
  • Complexity & Vendors: Not only can caching invalidation be complex to manage for a site that utilizes ISR, but finding a vendor such as Vercel that supports it can be challenging if you like hosting options.

When to use:
When you need a mix of Dynamic data and interactivity as well as SEO. Where content is still being updated, just not as often as a web app that uses CSR.
This is great for websites such as Blogs, Education Platforms, and something like a Real Estate Platform (Zillow / Redfin)

Image credits: React PWA

Client Side Rendering:

Rendering content on the client's browser using JavaScript. The JavaScript is initially sent from the server to the client i.e. (your web browser or phone). Your empty shell of an HTML file is then rendered from the data that is fetched from the JavaScript


Pros:

  • Reactivity: Amazing for applications that have a high demand for constantly changing data, prioritizing a rich user experience over SEO.
  • Reduced Server Load: Since the server only has to send the initial page load, all rendering after that is handled by the client and only content has to traverse with a server to the app.

Cons:

  • SEO Challenges: Search engines traditionally index by crawling HTML pages, As search engines have gotten better, there can still be issues where content can be harder to discover.
  • Slower Initial Page loads: Since the client must download a large JavaScript bundle, and execute it to render the content there can be a noticeable delay before the user sees content on the page

When to use:
Where Rich Interactivity is crucial for your application, requiring dynamic updates to data without needing to re-render the webpage.
Including, interactive dashboards, chat applications, and web-based tools.


MetricsCSRSSRSSGISR
SEO BenefitsLowHighHighHigh
InteractivityHighMediumLowMedium
Dynamic ContentHighHighLowMedium
ComplexityMediumHighLowMedium
Hosting CostsMediumHighLowLow

All in all, it's ultimately up to the Lead Engineer to create the design to pick one or a combination of strategies to achieve successful application development promptly.