DEV Community

Cover image for Rendering Strategies - Basics of SSR, SSG, CSR & ISR
Josefine Schfr
Josefine Schfr

Posted on

Rendering Strategies - Basics of SSR, SSG, CSR & ISR

When trying to understand the different data fetching methods in Next.js, I was very much confused at first - especially as all these abbreviations sound so similar but aren’t quite.

If you are anything like me and are trying to figure out what the difference between SSR, SSG, ISR and CSR are, maybe it helps hearing it from a fellow newbie. However, this is me documenting what I understood, absolutely no guarantee for 100% accuracy. If you spot a mistake or feel like something isn’t clear, please let me know in the comments, I’d much appreciate it!

Ok so what’s the deal with all these abbreviations?

Let’s get those out of the way first:

  • SSR = Server Side Rendering
  • SSG = Static Site Generation
  • ISR = Incremental Static Regeneration
  • CSR = Client Side Rendering

Now let’s dive in a little deeper…

Server-Side Rendering (SSR)
The name kind of teases it already: the webpages are rendered on the server-side and then sent to the client. Meaning that if there is any data to fetch, that is done - then, together with the markup, it is sent to the client. This happens for every single request - so instead of putting the website together in the browser (like CSR), the effort is done in the background. You might have a little slower loading times in general, but the initial page load is quicker than with CSR. Because the client receives the HTML document (instead of generating it on their side), it is easier for crawlers to assess the page and therefore better for SEO.

Static Site Generation (SSG)
SSG means that the content is only rendered on build time - so if you make a change, it won’t be visible unless you trigger a re-build. This is a good default option for websites that don’t change a lot - like a service page or blog where content isn’t frequently updated. It’s great because it’s really fast, but the more pages you have, the longer it takes to build.

Incremental Static Regeneration (ISR)
This is sort of a hybrid between SSG and SSR - the best of both worlds if you will. With Incremental Static Regeneration, web pages are regenerated after a predefined time. This way, the data can still be statically generated and is ready for the client, but we can define the interval in which this happens. To me, this sounds like a good solution for websites that require high performance, yet should be updated quite regularly. This, however, only applies if it doesn’t matter if changes are not immediately visible (e.g. would make me very nervous if I had to wait for a specific time to see whether my online banking was successful or not).

Client-Side Rendering (CSR)
Client-side rendering means the pages are directly rendered in the browser using JavaScript - rather than on the server. That might mean that the initial load is a bit slower than when using Server Side Rendering. As the HTML is only first generated in the browser, there isn’t much for Google’s crawlers to go on - they only see a blank page and can therefore not rank the site properly. This doesn’t make it a great fit for pages where SEO performance is crucial. However, large applications with dynamic data might benefit from CSR.

This is the extent to which I understood the different rendering methods - as with so many things, it seems to depend heavily on your use case and your requirements which will serve you best.
What are your thoughts on the different rendering methods? Did I miss crucial points in my summary? Let me know :)

Image by Mo & massive thanks to Nikita for proofreading.

Sources that helped me:

Top comments (0)