Breaking Down the Acronyms: SSR vs. SSG

Acronyms are always fun -- they're helpful for reducing the effort of saying out a full long-winded technical term, but they can also look like alphabet soup and be really confusing to newbies! I want to use this post to explain two terms that are often seen in tandem and start with the same two letters, but are pretty different concepts. Static Site Generation (SSG) and Server-Side Rendering (SSR) are both (back to being) hot topics in web development, but what are they? And why are they so widely talked about?

SSG

Static-site generators enable developers to create many pages all at once using templates with content plugged into them. For example, you may have a blog page for your application, each one has a header, title, the author's name and image, and the content itself all using the same layout from post to post. You don't want to code a new HTML page for each blog post. Instead, each blog post could be written in a markdown file and then plugged into the correct template format so that each web page is standardized using a static-site generator. This pattern is much faster for the developer than writing out an HTML boilerplate for each web page. The site is generated at build time meaning that you have a script that plugs every single piece of content into a template generating the HTML needed to properly render the page.

This is awesome for performance -- whenever the user goes to the page they are served a static HTML page -- the data is already plugged in and won't need to be plugged in by the server. BUT there's a catch -- since the process is done at build time, the site must have the build script re-run and re-deployed whenever you want to make changes. Say you write a new blog post, you'd need to re-build and re-deply the site. There are ways to automate this, like web hooks, but it's still not as flexible as a dynamically generated site.

SSR

Server-side-rendering has been a common pattern in web development for years. Frameworks like Ruby on Rails and Django used it to dynamically populate HTML templates with variable content. If the user navigated to /blog-post/2, for example, the server-side logic would plug the correct title, content, and author information into an HTML page and then send that back to the user. So, with SSR, the templating process happens at the time of the request instead of on build.

This pattern fell out of favor as more logic got pushed to the client side, and front-end frameworks became more predominant. That being said, server-side rendering still has many benefits, such as end user performance since JavaScript can be used much more minimally. Also, search engines often struggle with parsing JavaScript generated web-pages.

Recently, more JavaScript libraries have swung back in the server-side-rendering direction, Next.js being one of the most notable! That being said, React has also discussed adding server-side rendered components directly within the library itself.

With these modern web frameworks, you get the developer experience that comes with a library like React, but you can serve HTML to your end user giving them a potential performance boost.

Conclusion

I hope this blog post helped to break down the differences between SSR and SSG and when you would use each in your app! In one sentence, SSR fetches data when the user requests the content, and SSG fetches data when you build a site.