#ASKTHEINDUSTRY 11: I hear a lot about Server Side Rendering. Can you explain how it works and why it matters?
At my first job when I was in Paris I developed a Single Page Application for the company I was working for. I conducted a perf audit and tried to optimize for the First Paint at the best of my abilities. However I couldn’t go below a certain threshold.
At the time, a fundamental piece was missing in my education: Server Side Rendering (or SSR, as the cool kids call it).
Once upon a time, all the work used to be done on the servers. Take Medium for example, when you first navigate to the homepage, you’re presented with a list of the most recent articles. Then, when you click on an article, the page reloads and there you have the content of the article.
This is how a regular website works. However, ambitious web apps aim to offer a more interactive experience to their users and, when an article is clicked on, an app would simply replace the list of articles with the content of the chosen article, without reloading the page (e.g — the navigation bar doesn’t get re-rendered). Much like the native Android/iOS Medium app, the resulting experience is much more immersive and pleasant. There’s a trade off, though: for this to be possibile, the rendering of the content needs to happen on the client.
What this implies is that the First Paint gets delayed since, in lieu of simply fetching the HTML and rendering it, the app now needs to:
- Download the HTML file
- Discover the JavaScript bundle
- Fetch it
- Parse it
- Execute it
- Possibly, fetch the list of articles
- Finally, render
Relying only on client side rendering means that the First Meaningful Paint is entirely dependent on JavaScript. Which slows things down quite a bit.
So, how can we get best of both worlds? If you want to both have a blazing fast First Paint and an interactive experience, keep reading.
The key to solve the puzzle is deploying an hybrid technique: first, you render on the server the initial HTML page that is requested, then the client can have its JavaScript kick in so that it can take over from there.
Let’s see the steps involved for our Medium example:
- The HTML needs to be generated off of a template. Typically this means authoring pages with a templating language, for instance mustache or pug.
- Converting a template into an HTML string is a process composed of two steps: compiling the template into something the computer can understand, and rendering the code into regular HTML, by replacing the placeholders with the actual content. This last step is the one we owe the Server Side Rendering name to.
- When the server gets a request, it goes on and renders the initial page, by taking the template and filling it in with the actual list of articles. (server side rendering)
- The client can render the content for the user immediately upon receiving the response.
- The client will then discover, fetch, parse and execute the JavaScript bundle, which will then take over.
- When the user clicks on an article, everything is set up and the client-side app can fetch the new content and leave the App Shell intact. (client side rendering)
Boom. Win-win.
This piece is part of the #ASKTHEINDUSTRY project, a series of daily conversations with the Web Dev industry. You ask, I’ll answer, or find someone who can.
