Static Site Generation vs. Server Side Rendering

So you’ve decided you want to use a JavaScript framework for your next web app, but you actually care about SEO. Fortunately for you I’ve taken some of my fairly valuable time to write an article for you explaining the 2 options you have to ensure your search rankings remain intact whilst using your favourite JavaScript framework: SSR (Server Side Rendering) or SSG (Static Site Generation), You’re welcome.

Spherical ball on futuristic surface

Photo by Michael Dziedzic

By using SSR or SSG you will allow your site to benefit from the interactivity and UX benefits or a Single Page Application as well as the better developer experience from using a JavaScript framework, without the negative implications on your SEO; a best of both worlds.

The issue with Single Page Applications is all the content is injected into the DOM by JavaScript. This means when a crawler visits your site all they see is an empty html template which is far from ideal in the SEO world. By using SSR/SSG you ensure that web crawlers will always see the entire content which, assuming your content is decent, will massively improve your search rankings. 

For this article I will use Gatsby.js as a reference point as this supports both SSR and SSG but other frameworks are available for a range of JavaScript frameworks.

Static Site Generation

Static Site Generation is exactly what it says on the tin – it’s the generating of static html files to serve to your end user. In the case of gatsby this means your react components are built into simple html files. This is great for sites where the content rarely changes as it is much faster to have pre-built html files waiting for a user to request them. 

Static Site Generation is very similar to just building your website as static html files, with the organisation and interactivity of your favourite JavaScript framework injected. This does however pose an issue: let’s say you use a CMS like wordpress to manage the content of your site. The only way these changes can be reflected to your end users is by running a script to build new html files. There are workarounds for this where you can automatically trigger a script when content changes are made but this isn’t the easiest thing to do. 

This approach is also not feasible if you have dynamic content on your site; eg a social network or any other site that relies on user generated content. Fortunately there is another option

Server Side Rendering

Server Side Rendering achieves the same end result of SSG but the way it arrives at this result is vastly different. When a site is built using SSR there are no html files waiting for a user – they must be generated per request. This means that the content served is guaranteed to be the latest without any long build processes. However, as the server has to build the template once the end user has requested it, the response times are noticeably slower. 

Server Side Rendering is also arguably more complex to setup as it requires a node process running on your server. This initial setup complexity could be justified if you are expecting to make changes to content regularly as there are no additional steps; save your content change in your CMS and that’s it.

Overall both of these approaches are a great way to develop a site that has great SEO capabilities, as well as the greater UX of a single page app. For me there’s no real issue with either approach and deciding which is best for you purely comes down to the type of site.

Top Tip

If you have dynamic content or content that is updated frequently then spending a bit longer setting up SSR is definitely worth the investment.

However, if like most sites, your content will change rarely and you just wanted a nicer experience for your end user then go for SSG.

This website uses cookies

This website uses cookies to improve your experience. By using PRISM⁵⁵, you accept our use of cookies.