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.
Before we dive head-first into an explanation, let’s briefly recap the current context for a lot of modern web applications.
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>
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.
There are many advantages to SSR, to name just a few:
SSR is great for websites that are static, such as blogs, documentation, portfolios and landing pages where interactivity is usually limited.
Whenever someone shares your application on Facebook or Twitter, a preview of it will be displayed, including a title, description and an image.
Of course there are some drawbacks, it all depends on the type of application you’re developing.
Each new page requires a new server request. Although these are short and usually lightweight, it’s important to keep it in mind.
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.
Here are some of my recommended links:
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 ✨