Since the dawn of time, the conventional method for getting your HTML up onto a screen was by using server-side rendering. It was the only way. You loaded up your .html pages on your server, then your server went and turned them into useful documents on your users’ browsers.
Server-side rendering worked great at the time too, since most webpages were mostly just for displaying static images and text, with little in the way of interactivity.
Fast-forward to today and that’s no longer the case. You could argue that websites these days are more like applications pretending to be websites. You can use them to send messages, update online information, shop, and so much more. The web is just a whole lot more advanced than it used to be.
So it makes sense that server-side rendering is slowly beginning to take a backseat to the ever-growing method of rendering webpages on the client side.
So which method is the better option? As with most things in development, it really depends on what you’re planning on doing with your website. You need to understand the pros and cons, then decide for yourself which route is best for you.
How server-side rendering works
Server-side rendering is the most common method for displaying information onto the screen. It works by converting HTML files in the server into usable information for the browser.
Whenever you visit a website, your browser makes a request to the server that contains the contents of the website. The request usually only takes a few milliseconds, but that ultimately depends on a multitude of factors:
Your internet speed
the location of the server
how many users are trying to access the site
and how optimized the website is, to name a few
Once the request is done processing, your browser gets back the fully rendered HTML and displays it on the screen. If you then decide to visit a different page on the website, your browser will once again make another request for the new information. This will occur each and every time you visit a page that your browser does not have a cached version of.
It doesn’t matter if the new page only has a few items that are different than the current page, the browser will ask for the entire new page and will re-render everything from the ground up.
Take for example this HTML document that has been placed in an imaginary server with an 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 were to type the address of the example website into the URL of your imaginary browser, your imaginary browser would make a request to the server being used by that URL and expect a response of some text to render onto the browser. In this case, what you would visually see would be the title, the paragraph content and the link.
Now, assume that you wanted to click on the link from the rendered page which contains 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 the previous page and this one is that this page does not have a link and instead has another paragraph. Logic would dictate that only the new content should be rendered and the rest should be left alone. Alas, that isn’t how server-side rendering works. What would actually happen would be that the entire new page would be rendered, and not just the new content.
While it might not seem like a big deal for these two examples, most websites are not this simple. Modern websites have hundreds of lines of code and are much more complex. Now imagine browsing a webpage and having to wait for each and every page to render when navigating the site. If you have ever visited a WordPress site, you have seen how slow they can be. This is one of the reasons why.
On the bright side, server-side rendering is great for SEO. Your content is present before you get it, so search engines are able to index it and crawl it just fine. Something that is not so with client-side rendering. At least not simply.
No comments:
Post a Comment