Client-side rendering vs server-side rendering vs static site generation

Niels Stubbe profile picture
Niels Stubbe
Wednesday, November 24, 2021

A road sign pointing in different directions

There's more to developing a website than throwing some HTML and back-end code together. An important consideration that is often overlooked, is how a website gets rendered and delivered to users. This can make or break the experience users have, and even severely influence a website's rankings in search engines.

In this article we'll be taking a look at 3 different approaches to rendering websites with dynamic content, alongside their pros and cons


1. Client-side rendering

Currently the most popular approach when it comes to web applications. Client-site rendering means the client (our user's browser) is responsible for rendering the dynamic parts of our website by leveraging JavaScript and a separate back-end API.

React, Angular, Vue, JQuery, ... are mostly used for this approach.

How it works

Let's say we have a website that shows a list of products. When a client loads the website, the browser fetches all the HTML, CSS and JavaScript files needed to initially display the page.

However, our list of products isn't in those files. That's because we want our list to be dynamic. We want users to be able to sort, filter and search our list to find exactly what they are looking for.

Instead the client will send a request to our back-end API to retrieve a list of products that match the selected filters. We get that list as a response, and then our client generates the necessary HTML elements to show the products on the page.

✅ The good

  • Excellent for pages with a lot of dynamic and interactive content.
  • Cost. We offload processing power (and thus costs) to our clients. Rendering the page is almost entirely done on their machine.
  • Easier to scale. We can set up load balancers in front of our back-end API, without having to make changes in our client-side rendered application.

🅾️ The bad

  • Client performance. Offloading the work to the client can have an impact on clients with lower end machines. This could be problematic when trying to provide services in lower income areas of the world.
  • Bad for SEO. Not a good approach for pages that need to score high in search rankings. The dynamically loaded content could be missed by the crawlers that visit our website.

When to use

Client-side rendering is best used when dealing with websites that have a lot of dynamic and interactive content, where scaling is important and where we don't really care about SEO. Usually these types of websites are web applications.


2. Server-side rendering

Another approach to showing users dynamic and interactive content, is rendering the page on the server and then sending the page to the client with all dynamic content already filled in. This approach is usually found on pages that don't have too many users and have 'basic' interactivity such as internal applications in companies.

PHP and .NET MVC typically use this approach. We can also configure front-end frameworks such as Vue, React, etc... to use server-side rendering.

How it works

Looking back at the previous example, we can still create a website with a dynamic list of products. However, instead of retrieving the list of products every time we change one of the filters and letting the client generate and render the HTML, we'll send the filter parameters to a back-end service. This back-end service will then generate the entire page and send it back to the client to display.

✅ The good

  • Faster setup time. Since all logic is in our back-end, there's a lot less boilerplate code we need to write, which can save a lot of time at the start.
  • Can be faster than client-side rendering, depending on the clients machine and the complexity of the page that is being loaded.
  • No JavaScript needed to create a functioning, interactive website.
  • Good for search engines. Since all content is already included in the page on first load, this approach works much better for pages that need to have high search engine scores (such as product description pages).

🅾️ The bad

  • Higher cost. A website with a lot of traffic will be much more costly to run when using server-side rendering, since all that rendering work on the server requires a lot of extra processing power.
  • Does not scale as well. The required resources are directly proportional to the traffic on our website.
  • Not using JavaScript has certain limits. It's important to know these limits and to accept them, instead of trying to work around them down the line. That last situation is something seen a lot in legacy applications, resulting in an unmaintainable mess for a code base.

When to use

Server-side rendering is best used for sites where we have a good idea of what traffic we can expect. An example of this is a corporate portal that's only accessible to employees. Here we know exactly how many users we can expect, and the amount of users will not be growing x1000 over night. A server-side rendered website that is open to the public however, can see its costs sky-rocket if the service suddenly goes viral.


3. Static site generation

The final approach to rendering pages is to actually generate them up front. Both client-side and server-side rendering are 'on demand' approaches. The client visits our website and then our server or the clients renders the page they requested.

Static site generation however will already have all the pages and their content stored on the hosting server, exactly how they'll be shown in the clients browser. This is also why the word 'rendering' is absent here. We don't render anything, because we generate everything up front, removing the burden of rendering content from both the server and the client.

How it works

A static site it basically the default of how the web worked for a long time. We created the pages we wanted our website to have (home, about, contact, ...) and then hosted those on a web server. However, if we have a product catalogue, we don't want to create a new HTML page manually for each of the products we offer.

Instead, we can use a static site generator. This way we can provide the list of products from an external API, and the static site generator will then use that list to create a page for each of our products that has all the information needed such as description, pictures, etc...

My personal website, www.nielsstubbe.com, is created using a static site generator. I use Nuxt.js which is based on Vue.js, but there are plenty of others such as Next.js, Hugo, Jekyll, etc...

✅ The good

  • Scales incredibly well. The page generation step only runs when deploying a new version of our website, so the bulk of needed processing power is limited to a short moment in time during each new deploy.
  • Very cheap. Static pages can be hosted on almost any server. Combined with a form of caching, we can easily have thousands of visitors with almost no costs.
  • Fast and lightweight. Because the pages already exist, clients only need to download and view the page. Neither the client nor the server need to waste any time processing logic.
  • Excellent for SEO. Indexing a static website is a breeze for a crawler. The fast load times will also positively impact our ranking in most search engines.

🅾️ The bad

  • Not for interactive pages. A fully searchable and filterable product list page is impossible to make static.
  • Updates aren't instant. If we add a new product to our catalogue, we will need to re-generate and deploy our website before the product page can be visited.

When to use

Static site generation is best used when we have content that doesn't change often, and where our ranking in search engines is important. A blog is an excellent example of this. Another example are product description pages.

More interactive pages such as tables, comment sections, etc... are not suitable to use with static site generation, since we expect them to change often due to actions of our users.


In conclusion, which one should we use?

As with anything programming-related, there's no 'one size fits all' answer. I recommend taking a look at the pros and cons listed in this article and doing some further research before committing to an approach.

Finally, keep in mind it's possible to combine different technologies. It would be great for interactive pages to be client-site rendered, because we want our user to be able to sort or filter our products, or edit their own profile. Meanwhile we want our product pages to score as high as possible in search engines, so why not statically generated those for the best possible performance?


Thanks for reading

I hope you enjoyed this article. If you have any questions, remarks or feedback, feel free to reach out to me via hello@nielsstubbe.com.

If you would to stay up-to-date with the articles I publish, please consider subscribing to my newsletter via the form below.