DEV Community

Cover image for Static Site Generation vs Server Side Rendering
Dima Odintsov
Dima Odintsov

Posted on • Updated on


Static Site Generation vs Server Side Rendering

As a web developer, one of the most important things you need to care about is performance.
How fast the page loads while providing a good user experience is extremely critical. At some point or another, we have all wanted to know if SSG (static site generation) or SSR (server side rendering) is faster in terms of page load times and availability for users.

In this little article I will talk about SSG vs SSR and which technique is the best when it comes to speed and user experience.

The server side rendering vs static site generation debate is one that has been discussed for years, but it seems to be picking up more and more steam this year. So what's the difference between server side rendering and static site generation?

Firstly, server side rendering (SSR) is an approach where server-side code generates HTML on the server at build time. This can include preprocessing languages like Pug or templating engines like Twig or Handlebars . These templates are then rendered on the server with data from your database or any other service you might depend on. The result of this is Server Side Rendered HTML which is then sent to the browser as a single page application (SPA).

Secondly, static site generation (SSG) refers to a range of techniques where server-side code generates static HTML pages. The server simply returns the HTML as a response without any further logic.

The thing that needs to be known is what SSG actually means:
It's when your rendered HTML pages are saved on disk as static files - think of it as a snapshot of your website. So SSG is very beneficial because no matter how slow or low quality your web server is, you can serve pages that are saved on disk to any device near instantaneously. SSG is different than SSR in that SSG doesn't need a backend and all pages rendered with SSG will be static- SSG only needs the HTML in markdown format and for SSG to work properly, there can't be any external <script> tags in any page.

As I previously mentioned, SSG uses files stored locally to generate websites so when you add new content or update existing content, the changes need to be uploaded manually by updating the which take time especially if you want to update and change a lot in your SSG based website. SSG becomes very slow when it comes to updating existing content especially if there is a large amount of content that needs to be added, updated or removed.

The benefit SSG has over SSR is SSG uses no server resources - SSG can be hosted for free on github pages (we will get to this later) and all you need is a GITHUB account. SSR requires backend requests from the client browser which takes up server resources when processing the request; SSG doesn't have this problem because all requests are served from the local web directory that SSG renders pages from.

Server side rendering, on the other hand, is SSG's complete opposite. SSR is when SSG pages are rendered to be sent to the client browser and then SSG pages are served- SSG is much faster than SSR because SSG doesn't require backend requests and SSG doesn't use any resources from the server. SSR requires a SSG backend which takes up server resources; this is why many people believe SSR to be slower than SSG because of how resource intensive SSG backends can be especially if there are a lot of pages requiring heavy loads on the backend like Medium or Wordpress do.

Server side rendering has an advantage over static site generation in that all pages will need to load assets (css, javascript) from external sources and since these external SSG pages are SSG pages as well, SSG will take up a lot of resources consuming them just like it would with backend requests.

The server side rendering's disadvantage is server side pages need to render those SSG pages before being sent to the client which takes up server resources. Static site generation doesn't have this problem because all it requires SSG backend for server requests and then server caches SSG website as a whole beforehand- you wouldn't have any problems updating your content every now and then even if it was a large amount of contents requiring updates, deletions or additions.

In conclusion, server side rendering has its advantages over static site generation since server side rendering doesn't require server resources but SSR can be resource intensive if there are many pages on the SSG website that require heavy loads of backend resources making them slower than static site generation.

Make sure to visit my portfolio :)

Thanks for reading! ❤️

Top comments (0)

Top Heroku Alternatives (For Free!)

Recently Heroku shut down free Heroku Dynos, free Heroku Postgres, and free Heroku Data for Redis on November 28th, 2022. So Meshv Patel put together some free alternatives in this classic DEV post.