DEV Community

Cover image for Server Side Rendering Visualized
saadnoor salehin
saadnoor salehin

Posted on

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 -

Alt Text

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.

Alt Text

A big portion of this 8 seconds time used to -

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

And the user didn't see anything meaningful in the 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 dead blank HTML file, it renders our app in the server ( blessings of Node.js) and sends the HTML to the browser. Now the user doesn't have to wait for downloading that big main.js file. It can show the server-rendered HTML immediately. So the user will able see some meaningful content very fast.

Now let's see how this SSR works:

Alt Text

  1. The client makes a GET request to the server for the webpage
  2. The server parses and renders a HTML file immediately
  3. The client shows this HTML to the user, the user sees a meaningful content but app isn't ready yet
  4. The server also sends 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. The server gives control to the client when it's ready.

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

Alt Text

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

(This post was originally published at https://saadnoor.com/server-side-rendering-visualized/ )

Top comments (0)