Server Side Rendering Visualized

Lets take a look, nowadays, how a modern web app is displayed in browser. A typical response sent by an Angular app looks like this,

  1. A bare , poor and sad HTML file
<!doctype html>
<html lang="en">
<head>
   <title>Angular</title>
   <base href="/">
   <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
   <app-root></app-root>

<script type="text/javascript" src="inline.f481c2f5e1589433c6b6.bundle.js"></script>
<script type="text/javascript" src="polyfills.8135eb80f6191ae1578b.bundle.js"></script>
<script type="text/javascript" src="main.7dd036568b70b6284d5d.bundle.js"></script>    

</body>
</html>
  1. A rich main.js file, which is the life for that app.

Browsers take this main.js file and parse and render our app, it makes that bare HTML meaningful. But what if, user disables Javascript on his browser?

Well, he will see this - an empty and dead page -

Server%20Side%20Rendering%20Visualized%205a45fe9dd0d24c1987cdd54313e19508/Untitled.png

but wait? Seriously? Somebody will disable Javascript in their browser at 2020? Who is that dumb?

well, search engine crawlers are dumb. They will. When they want to index our webpage for search results, they will find a plain old HTML file who has nothing, and a big main.js file for which they don’t have any time or respect. When they see that javascript file is too big to parse, they will ignore it. So our Angular app perform poorly in terms of SEO.

What’s the solution?

we can use a quick 3rd party-based solution, prerender.io . It checks the person who requested your webpage, is a bot or human? If it’s a human, it sends the regular response - a plain HTML with a main.js file. But if it’s a bot, prerender.io opens a browser in itself, renders the app there and then sends the contentful html files.

So the SEO problem can be solved. But-

  1. It’s not a good way
  2. There are more problems to solve, the first meaningful paint problem

First meaningful paint measures when the primary content of a page is visible to the user. In the picture bellow we can see user had to wait for 8 seconds to see anything meaningful.

Server%20Side%20Rendering%20Visualized%205a45fe9dd0d24c1987cdd54313e19508/Screenshot_2020-07-27_at_9.03.39_PM.png

A big portion of this 8 seconds time used to -

  1. Download that main.js file, if user’s internet is slow - this time will increase.
  2. Parse and render that main.js file.

And user didn’t see anything meaningful in screen, recent study shows that user leaves any webpage that takes more than 3 seconds to load.

Server side rendering solves both problems. Instead of sending the a dead blank html file, it renders our app in the server ( blessings of Node.js), and sends the html to browser. Now user don’t have to wait for downloading that big main.js file. It can show the server rendered HTML immediately. So user will able see some meaningful content very fast.

Now lets see how this SSR works:

Server%20Side%20Rendering%20Visualized%205a45fe9dd0d24c1987cdd54313e19508/Untitled%201.png

  1. Client makes a GET request to the server for the webpage
  2. Server parses and renders a HTML file immediately
  3. Client shows this HTML to user, user sees a meaningful content but app isn’t ready yet
  4. Server also send the angular/react app (that main.js file)
  5. Client downloads that file in and loads our app background
  6. Once everything is ready client-side, it seamlessly switches from showing the server-rendered pages to the client-side app. Server gives control to the client when it’s ready.

As meaningful HTML is served to user immediately, So first meaningful paint time improves significantly with SSR.

Server%20Side%20Rendering%20Visualized%205a45fe9dd0d24c1987cdd54313e19508/Screenshot_2020-07-27_at_10.16.29_PM.png

In the next post, we will learn how to implement Server Side Rendering with Angular, stay tuned.

Get The Best Of All Hands Delivered To Your Inbox

Subscribe to our newsletter and stay updated.