Server side rendering, client side rendering, and static site gen­er­a­tion at a glance

Every time you visit a website, your browser needs to render the site so that it is presented in an appealing way and provides the desired level of in­ter­activ­ity. However, depending on the web project’s pro­gram­ming approach, dynamic scripts and static code can be handled in very different ways. We’ll take a closer look at the three main ap­proaches: server side rendering, client side rendering, and static site gen­er­a­tion.

Server side rendering or server side scripting is a technique used in the de­vel­op­ment of websites with dynamic elements and web ap­plic­a­tions. It is based on the use of scripts that are executed by the web server using the ap­pro­pri­ate scripting languages when you request the cor­res­pond­ing content with the browser. With the initial request, all HTML, CSS, and JavaS­cript in­struc­tions are fully loaded.

Typical pro­gram­ming languages for server side rendering include:

• Java
• Ruby
• ASP.NET
• Perl
• PHP
• Python
• Node.js or JavaS­cript

A great advantage of SSR is that the web pages are preloaded by the server. A request is therefore processed almost im­me­di­ately from the user’s point of view, so the web pages end up being displayed very quickly. This approach to optimised loading speed is par­tic­u­larly useful for static websites. Search engines also see the fast page loading speed as a plus - also because crawlers can crawl pages more easily and more quickly thanks to server side rendering.

Server side scripting requires the server to deliver preloaded HTML pages with every request. In par­tic­u­lar, if a client con­tinu­ously sends further requests to the web server to provide the user with new, modified in­form­a­tion, this means a heavy load on the server capacity. SSR is therefore not suitable for websites that have a high number of requests or require a large number of user in­ter­ac­tions. In projects like these, the response time of the web server would negate the advantage of the optimised page loading speed.

The most sig­ni­fic­ant client side scripting language is JavaS­cript.

CSR proves to be a prof­it­able approach, es­pe­cially for web projects with a lot of user in­ter­ac­tion. If the website initially loads slower, the sub­sequent rendering of further pages is therefore faster. The user ex­per­i­ence is sig­ni­fic­antly better than with server side rendering, since all scripts and content do not have to be loaded com­pletely right away every time the user visits a new page.

Since the scripts are executed in the user’s browser, they have the ability to view the source code, unlike server side scripts.

The focus on client side scripts comes with two key problems. First, it is harder for search engines to crawl and index the pages. Google’s crawlers are able to do this, even though the SEO con­di­tions are not optimal - es­pe­cially since many other search engines are often not able to index client side rendered pages at all.

On the other hand, client side scripting requires JavaS­cript to be supported by the browser. This is basically the case - but since pop-ups and tracking tools are also based on CSR and the client side scripts also in­flu­ences the loading time, there are various browser ex­ten­sions that block the scripts.

Popular static site gen­er­at­ors include the following:

• Jekyll
• Hugo
• Next
• Gatsby
• Gridsome
• Nuxt
• Hexo
• Eleventy
• Jigsaw
• Vuepress

Static site gen­er­a­tion is es­pe­cially useful in projects that have a lot of content that does not change regularly. Typical examples include a personal website or blog, which typically carry little dynamic content and would benefit greatly from fast loading as a result of pr­er­en­der­ing (i.e., page pre­load­ing) by a static site generator. In addition, SSG projects offer few attack options since the risk potential is limited to the single click when the client’s page is loading.

There are a few downsides when it comes to pr­er­en­der­ing with SSG. The approach proves to be extremely im­prac­tic­al when a web project is subject to regular changes - whether of a technical nature or in terms of content. For each change, the static pages of the web project have to be ‘preloaded’ again. The larger the project, the more time this building process takes, making static site gen­er­a­tion un­suit­able for websites with a large number of static pages.

Server side rendering ensures an excellent page loading speed although this requires a lot of the web server’s capacity. Client side rendering is the opposite and actually relieves the server by rendering a large part of the page in the browser first - provided the user has not blocked JavaS­cript. Static site gen­er­a­tion spares both server and client and, thanks to the pr­er­en­der­ing approach, ensures fast delivery of the content, provided it is not in­ter­act­ive and con­stantly changing.

So, all three strategies presented for rendering web projects have their pros and cons. Decide which features best suit your project so you can find the best approach for your web ap­plic­a­tion.