The standard way to get HTML up on a page in the browser was by server-side rendering (SSR). It was the only method available before other rendering modes came on board. You simply loaded your website files on a server, and then on request, the server went and converted them into documents that can be understood by the browser.
And this met the needs at the time because most websites displayed non-personalised static text and images, having almost no use for interactive and dynamic features.
But these days websites do way more than just display static content. They are arguably more like applications that use the web as a platform. Websites of today are often used for messaging, streaming, editing, and lots more. Websites have just become a lot more functional than they used to be.
So this means that there has been a paradigm shift regarding server-side rendering as the primary rendering mode in favour of the modern way of rendering web pages on the client side. Let's take a closer look at both rendering modes.
How SSR works
The key aspect of server-side rendering is the generation of HTML, which is done by the server. You request an HTML page - written in PHP, for example - the server runs and compiles the PHP code, includes the data (text, images etc.) and sends the populated HTML file back to the client. The requests and responses put together usually take about a quarter of a second but ultimately depend on several factors which include:
- the server's location
- your internet speed
- the traffic to the website
- the website performance
But on making the same request or even on navigating to a different route, the whole process had to be repeated: get the PHP file based on the new route, compile it and then, as usual, send it to the browser, with the CSS and JavaScript files that may affect the page load time.
Even though the new page differs from the current page by a few lines of content, the server re-renders the new page anew and then sends it to the browser. Although this may not be an issue for websites with little content, many modern websites have thousands of lines of code and are generally complex. This would mean longer load times because every page would have to be rendered and re-rendered when navigating through the site, making the website slow.
But on the other side, SSR is really good for search engine optimization (SEO). It means that the search engine does not have to execute the website's JavaScript to understand what might be on the page, which is the case with client-side rendering as we'll see below in a jiffy.
SSR pros:
- Content is available immediately on the initial page load even on slow connections
- Ideal for SEO
SSR cons:
- Too many server requests and page reloads
- Longer load time due to rendering (both on the server and client)
How CSR works
In the client-side rendering model, the server renders a blank HTML page with a reference - typically through an element with an id - to a JavaScript bundle, which goes up to the client. Then the client renders a blank page and starts executing the JavaScript bundle, which creates DOM elements on the page.
If you've done create-react-app before, you'd notice that there's always an index.html file with an id of "root", which links to the JavaScript framework.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="theme-color" content="#000000" />
<meta name="description" content="Web site created using create-react-app"/>
<link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
<link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
<title>React App</title>
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div>
</body>
</html>
All routes are directed to this file and are handled by the JavaScript bundle, so the browser doesn't make any additional requests to the server, and this makes the overall user experience faster.
This is significantly unlike using SSR because the server is now just responsible for loading a bare minimum of the website. Everything else is handled by a client-side JavaScript library, in this case, React.js.
However, there are some drawbacks to using client-side rendering. The website's SEO suffers a setback because the content does not render immediately until the JavaScript bundle loads in the browser. There are workarounds for this, but they require extra work, unlike server-side rendering.
You should also note that the website won't load until all the JavaScript has been sent to the browser since it contains all the pages and content needed. Because bundle sizes are large nowadays, the initial loading may take relatively long on weak connections.
CSR pros:
- Dynamic site interactions for web apps
- Faster overall experience
CSR cons:
- The initial page load might take longer
- Poor SEO
Both client-side and server-side rendering can also be implemented with frontend frameworks like Nextjs.
Top comments (0)