What is server-side rendering?
The most common approach for displaying information on the screen is server-side rendering. It works by converting HTML files on the server into information that the browser can use.
When you visit a website, your browser sends a request to the server that contains the website’s content. The request usually takes only a few milliseconds, but this is determined by a variety of factors:
- Your internet connection speed
- the server’s location
- how many people are attempting to access the site
- and the website’s optimization, to name a few.
When the request is completed, your browser returns the fully rendered HTML and displays it on the screen. If you then navigate to another page on the website, your browser will make another request for the updated information. This will happen every time you visit a page for which your browser does not have a cached version.
Even if the new page only contains a few items that differ from the current page, the browser will request the entire new page and re-render everything from the ground up.
Consider this HTML document, which has been placed on an imaginary server with the HTTP address of example.testsite.com.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Example Website</title> </head> <body> <h1>My Website</h1> <p>This is an example of my new website</p> <a href="http://example.testsite.com/other.html.">Link</a> </body> </html>
If you type the address of the example website into the URL of your imaginary browser, the browser will make a request to the server used by that URL and expect a response of some text to render on the browser. The title, paragraph content, and link would be visible in this case.
Assume you wanted to click on a link on the rendered page that contained the following code.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Example Website</title> </head> <body> <h1>My Website</h1> <p>This is an example of my new website</p> <p>This is some more content from the other.html</p> </body> </html>
The only difference between this page and the previous one is that this page lacks a link and instead contains another paragraph. Logic would dictate that only the new content be rendered, leaving the rest alone. Unfortunately, that is not how server-side rendering works. What would actually happen is that the entire new page, not just the new content, would be rendered.
While it may not appear to be a big deal in these two examples, most websites are not this straightforward. Modern websites are much more complex, with hundreds of lines of code. Consider browsing a website and having to wait for each page to render as you navigate the site. If you’ve ever visited a WordPress site, you’ve probably noticed how slow they can be. One of the reasons for this is as follows.
On the plus side, server-side rendering is beneficial to SEO. Because your content is there before you get it, search engines can index and crawl it just fine. This is not the case with client-side rendering. Not easily, at any rate.
What is client-side rendering?
When developers discuss client-side rendering, they are referring to the process of rendering content in the browser using JavaScript. Instead of getting the entire HTML document, you get a bare-bones HTML document with a JavaScript file that will render the rest of the site using the browser.
This is a relatively new approach to website rendering, and it didn’t gain traction until JavaScript libraries began incorporating it into their development style. Vue.js and React.js are two notable examples, and I’ve written more about them here.
Returning back to the previous website, example.testsite.com, assume that you now have an index.html file with the following lines of code.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Example Website</title> </head> <body> <div id="root"> <app></app> </div> <script src="https://vuejs.org"type="text/javascript"></script> <script src="location/of/app.js"type="text/javascript"></script> </body> </html>
When rendering with the client, you can immediately see that the index HTML has undergone significant changes.
To begin, rather than having the content within the HTML file, you have a container div with the id root. There are also two script elements just above the closing body tag. One will load the Vue.js JavaScript library, and the other will load the app.js file.
This differs significantly from using server-side rendering in that the server is now only responsible for loading the bare minimum of the website. The primary boilerplate. Vue.js, a client-side JavaScript library, and custom JavaScript code handle everything else.
If you only used the code above to access the URL, you would get a blank screen. Because the actual content must be rendered using JavaScript, there is nothing to load.
To fix this, add the following lines of code to the app.js file.
var data = { title:"My Website", message:"This is an example of my new website" } Vue.component('app', { template: ` <div> <h1>{{title}}</h1> <p id="moreContent">{{message}}</p> <a v-on:click='newContent'>Link</a> </div> `, data: function() { return data; }, methods:{ newContent: function(){ var node = document.createElement('p'); var textNode = document.createTextNode('This is some more content from the other.html'); node.appendChild(textNode); document.getElementById('moreContent').appendChild(node); } } }) new Vue({ el: '#root', });
If you go to the URL, you’ll see the same content as in the server-side example. The main distinction is that if you click on the link on the page to load more content, the browser will not send another request to the server. Because you are rendering items in the browser, JavaScript will be used to load the new content, and Vue.js will ensure that only the new content is rendered. Everything else will be ignored.
This is much faster because you are only loading a small portion of the page to fetch the new content rather than the entire page.
However, there are some drawbacks to using client-side rendering. Because the content is not rendered until the page is loaded in the browser, the website’s SEO will suffer. There are workarounds, but they are not as simple as they are with server-side rendering.
Another consideration is that your website/application will not be able to load until ALL of the JavaScript has been downloaded to the browser. This makes sense given that it contains all of the necessary content. If your users have a slow internet connection, their initial loading time may be prolonged.
THE BOTTOM LINE:
Summing it all up, when a user requests a webpage in SSR, the server prepares the HTML page by retrieving the necessary data from the database and sending it to the user’s machine via the internet. The browser then displays all of the requested actions on the user interface. All of these processes, from retrieving data from the database to creating an HTML page and sending it to the client, are completed in milliseconds or less. Furthermore, because client and server code can be developed and released independently, a clear client-server separation scales better for larger engineering teams. This is especially true at Grab, where multiple client apps access the same API server.
Hire us for your next project.
Image Credits: medium
