Christopher Kade

Posted on Jun 7, 2019 • Edited on Oct 17, 2019 • Originally published at christopherkade.com

Understanding Server Side Rendering

#javascript #webdev #beginners #tutorial

What is Server Side Rendering (SSR) ?

That's often a tricky question for a lot of people, where answers range from "it's good for static websites" to "I used it for my blog". But what is it really? Let's cover that together, including its pros & cons and some useful links.

What is Server Side Rendering?

Before we dive head-first into an explanation, let's briefly recap the current context for a lot of modern web applications.

Single Page Applications (SPA)

In our current web ecosystem, with our multitude of Front-End libraries and frameworks, a server will often respond with something like this when requested a page:



<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <link rel="shortcut icon" href="/favicon.ico">
    <title>React App</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/app.js"></script>
  </body>
</html>

Where the <div id="root"></div> element will have pages injected into it using Javascript as the user navigates through the application.

This implies that all of the website's Javascript needs to be downloaded to the browser before being able to display anything. Meaning that a slow internet connection could have a great impact on the initial load time of your application. But, once loaded, the subsequent pages load fast and the website can be super interactive.

Server Side Rendering (SSR)

On the other hand, when navigating to the same page, a server-rendered approach would have the server send your browser a readable HTML file with the page's content. When you'd navigate to another page, the same process would occur again.

Why should I use it?

There are many advantages to SSR, to name just a few:

🔎 Better SEO

Google's crawlers have a limited capacity to execute Javascript for a website before indexing it, meaning that the content of your page might have trouble being referenced. SSR on the other hand renders the page fully, meaning better SEO all around.

🏎 Faster first meaningful paint

As stated earlier, SSR won't have you download the website's Javascript fully, meaning a faster initial load speed. Which is great for individuals with older hardware or slower connections. Depending on your target audience this may be an important factor.

✅ Great for static websites

SSR is great for websites that are static, such as blogs, documentation, portfolios and landing pages where interactivity is usually limited.

👥 Social media optimization

Whenever someone shares your application on Facebook or Twitter, a preview of it will be displayed, including a title, description and an image.

Any drawbacks?

Of course there are some drawbacks, it all depends on the type of application you're developing.

📈 More server requests

Each new page requires a new server request. Although these are short and usually lightweight, it's important to keep it in mind.

🐌 Slower page rendering

SPAs injects and renders each page faster as the Javascript is initially loaded when accessing the website for the first time. Since SSR fetches the whole page, the rendering will be somewhat slower.

🕹 Less interactivity

Imagine if Trello or Gmail were using SSR, you'd have to reload the page completely at each user interaction, which impacts the overall experience.

Useful links

Here are some of my recommended links:

To build Vue.js server-rendered applications: Nuxt.js.

To build React server-rendered applications: Gatsby.js, Next.js.

This great explanation of SSR by the Firebase team.

I hope you enjoyed this article and learned a couple of things along the way.

Feel free to follow me on Twitter @christo_kade for any updates on my future articles. I also share a lot of interesting stuff about JS & CSS overall ✨

Like that article's banner? Check out a banner generator I made for DEV!

Top comments (21)

Brandon Benefield • Jun 7 '19 • Edited

Hi @christopherkade , thanks for sharing your thoughts. I never put in the effort to play with SSR libs/frameworks until this morning after reading this post so thank you for that as well! I do have some questions about the drawbacks you mentioned concerning SSR.

📈 More server requests
Each new page requires a new server request. Although these are short and usually lightweight, it's important to keep it in mind.

Can this just be mitigated and no longer a concern if your "server", aka your Next.js app, was only handling the frontend: rendering and routing, while your actual server, let's just go with Express.js, handles your data: REST, CRUD operations, user auth, etc.? Of course, in this scenario both ends would be hosted on different machines.

🕹 Less interactivity
Imagine if Trello or Gmail were using SSR, you'd have to reload the page completely at each user interaction, which impacts the overall experience.

This one is a little confusing for me to understand. Is this suggesting that we can't use a fetch request to send or receive data and just replace the DOM content?

Christopher Kade • Jun 7 '19

Hi Brandon, I'm really glad the article pushed you to start working with SSR !

If I understood your first question correctly, you'd have an Express server that handles usual operations while having a client built using Next and server-rendered.

Either way, your individual pages would be queried to the server at each route. Doing REST, CRUD and authentication operations by querying your server is one thing, but getting the HTML on each route is another.

For your second question, I understand the confusion, so let me clarify:

Imagine you have an e-mail under /inbox/42 where 42 is the e-mail's ID. The index.html page related to this specific e-mail would need to be already rendered on the server in order for it to be SSR. This way, when you reach this page, the complete page (and therefore its content) would be received by the client.
In an SPA case, the data for the e-mail with an ID of 42 would be queried to the server as you'd normally do.

I really hope this helps, and thank you for your feedback !

Brandon Benefield • Jun 7 '19

Gotcha, definitely cleared up what I was thinking, thank you.

So I guess another question is what is technically SSR? You touch on it a bit in this post but with everything getting data from a RESTful endpoint this would typically mean even a simple blog grabbing a posts' content from a database wouldn't be considered SSR correct?

For example, if using Next and React, when requesting a blog post I would have a fetch request inside of the componentDidMount() method which is only called after the initial render() method. The way you've explained the Gmail scenario makes me think that this is no longer considered SSR even if using Next to render the page, correct? Another thought is that perhaps all of this is done on the server side, going through all of the React Component LifeCycle Methods before actually sending the HTML to the client which if that's the case then that would be considered SSR.

Mohammed Foysal • Jun 7 '19

Is there a way to have a SSR SPA hybrid? So on the first request, it acquires a server rendered page and then all clicks after that work with a SPA which makes RESTful calls?

Matteo Rigon • Jun 8 '19

Nuxt and Next already do this. You only reach the server on the first request and then everything else works like a spa

Hammed Oyedele • Jun 9 '19

Same with Gatsby.

Beeno Tung • Apr 15 '20

If you want to go futher, checkout LiveView, it returns complete layout in html/css on the initial get request, then use websocket to push user interaction to the server.
The server maintain the virtual dom, and send the diff patch to the client for partial update.

This way the client don't need to download heavy javascript bundles. It has two implementations so far, in typescript and elixir

David Wickes • Jun 7 '19

I enjoyed reading your article, but I've got to pick some bones:

SSR is great for websites that are static, such as blogs, documentation, portfolios and landing pages where interactivity is usually limited.

You wouldn't do server side rendering for static sites - you wouldn't need to render at all. Just serve up the static html file.

SPAs injects and renders each page faster as the Javascript is initially loaded when accessing the website for the first time. Since SSR fetches the whole page, the rendering will be somewhat slower.

Time to 'load' is shorter for SPAs - but usually that's the time to load the spinner that tells you the rest of your page is loading...

Imagine if Trello or Gmail were using SSR, you'd have to reload the page completely at each user interaction, which impacts the overall experience.

Gmail does still use server side rendering. Try turning off JavaScript (don't panic) in your browser and enjoy your Gmail like it's 2005 again. You'll be surprised how clean it looks and how fast it loads on even the slowest connection or oldest computer. You'll also be surprised that you can still do almost everything you need. Try it now!

What's depressed me about this piece is that it seems that there's a whole generation of (front end) developers who don't realise you can build a web application without building a single-page app.

Christopher Kade • Jun 7 '19 • Edited

Glad you mentioned Gmail, I definitely did not know that. Thanks for sharing.

Depressed does seem like a rather big word for such an assumption. Tools and methods evolve, and the fact that people document themselves here should be inspiring, not depressing.

Either way, thank you for sharing some info

David Wickes • Jun 7 '19

Sorry, yes - in no way do I wish to take away from what you've written. It's well written and a good read! I'm sorry if 'depressed' threw a little shade your way, please don't take it to heart - I'm just being a grognard.

Christopher Kade • Jun 8 '19

It's absolutely fine, I'm glad you shared your experience

ZaneHannanAU • Jun 8 '19

There is quite a lot that I want to disagree with here...

Server side rendering does not mean more network requests. If anything it means less requests.

Server side rendering can be done through various means. It's one of the fundamentals of the web.

There are issues with how it's often done, though...

In many cases, we wait for a DOMContentLoaded/load event listener (jQuery .ready hook) or throw our application at the end of the page. This sort of thing does not lend itself well to pages needing interaction.

An example might be using a click global event listener and filtering by class (or closest) to work it.

I see the idea of server-side rendering as counter-intuitive in most applications. Service workers might make more sense if you think of them as the go-between for a client and a server.

For instance, Jake Archibald is basically the guy who napkined service workers, and uses them... for everything.

SSR is almost always faster than client rendered to have working content, given that you aren't killing the thread.

Serviceworker rendered... is similar. It's midway.

If you're building for it, it's more or less one of three. You attach global listeners and wait until you have some confirmation. I've done it myself, though on a really small scale.

It's everything that you do that makes it work. It may not necessarily work well, but it works.

Sandeep Balachandran • Jun 7 '19

Great article.I think it should be a good practice use SSR in angular projects. Never actually tried that.

Omar Gaston Chalas • Jun 7 '19

Great article.

In the past, i was a fan of SPA and i'd wanted using it for any project. But after that i understood you need to use the tool according to the project needs.

Btw, from time ago i've thought to create my personal blog site with Gatsby, have you used it?.

Christopher Kade • Jun 7 '19

Thank you !

My own blog is made using Gatsby so I'd definitely recommend it

stereobooster • Jun 8 '19

Some of the information in this article is misleading (at least how I understand the wording). For example,

Slower page rendering
SPAs injects and renders each page faster as the Javascript is initially loaded when accessing the website for the first time. Since SSR fetches the whole page, the rendering will be somewhat slower.

Actually they use SSR to improve first paint. It depends on the setup of course, but generally it takes more time to download JS and render the page than download HTML and CSS. As soon as page is loaded it would be faster (typically) to change it with JS instead of navigating with the browser.

There is a good article on the subject: developers.google.com/web/updates/...

Savas Vedova • Jun 16 '19 • Edited

I developed a tool having in mind Server Side Rendering, and it evolved in something more complex :) I'd like to hear your feedback on the tool. Here is the doc page for SSR. It figures out the webpack for server by itself, removes the need to setup a node/express server and has built-in autoscaling :)