Faster webpage loading times play a big part in user experience and SEO, with page load speed a key determining factor for Google’s algorithm.
A front-end web developer must decide the best way to render a website so it delivers a fast experience and dynamic content.
Two popular rendering methods include client-side rendering (CSR) and server-side rendering (SSR).
All websites have different requirements, so understanding the difference between client-side and server-side rendering can help you render your website to match your business goals.
Google & JavaScript
Google has extensive documentation on how it handles JavaScript, and Googlers offer insights and answer JavaScript questions regularly through various formats – both official and unofficial.
For example, in a Search Off The Record podcast, it was discussed that Google renders all pages for Search, including JavaScript-heavy ones.
This sparked a substantial conversation on LinkedIn, and another couple of takeaways from both the podcast and proceeding discussions are that:
Google doesn’t track how expensive it is to render specific pages.
Google renders all pages to see content – regardless if it uses JavaScript or not.
The conversation as a whole has helped to dispel many myths and misconceptions about how Google might have approached JavaScript and allocated resources.
Martin Splitt’s full comment on LinkedIn covering this was:
“We don’t keep track of “how expensive was this page for us?” or something. We know that a substantial part of the web uses JavaScript to add, remove, change content on web pages. We just have to render, to see it all. It doesn’t really matter if a page does or does not use JavaScript, because we can only be reasonably sure to see all content once it’s rendered.”
Martin also confirmed a queue and potential delay between crawling and indexing, but not just because something is JavaScript or not, and it’s not an “opaque” issue that the presence of JavaScript is the root cause of URLs not being indexed.
General JavaScript Best Practices
Before we get into the client-side versus server-side debate, it’s important that we also follow general best practices for either of these approaches to work:
Don’t block JavaScript resources through Robots.txt or server rules.
Avoid render blocking.
Avoid injecting JavaScript in the DOM.
What Is Client-Side Rendering, And How Does It Work?
Client-side rendering is a relatively new approach to rendering websites.
It became popular when JavaScript libraries started integrating it, with Angular and React.js being some of the best examples of libraries used in this type of rendering.
It works by rendering a website’s JavaScript in your browser rather than on the server.
The server responds with a bare-bones HTML document containing the JS files instead of getting all the content from the HTML document.
While the initial upload time is a bit slow, the subsequent page loads will be rapid as they aren’t reliant on a different HTML page per route.
From managing logic to retrieving data from an API, client-rendered sites do everything “independently.” The page is available after the code is executed because every page the user visits and its corresponding URL are created dynamically.
The CSR process is as follows:
The user enters the URL they wish to visit in the address bar.
A data request is sent to the server at the specified URL.
On the client’s first request for the site, the server delivers the static files (CSS and HTML) to the client’s browser.
The client browser will download the HTML content first, followed by JavaScript. These HTML files connect the JavaScript, starting the loading process by displaying loading symbols the developer defines to the user. At this stage, the website is still not visible to the user.
After the JavaScript is downloaded, content is dynamically generated on the client’s browser.
The web content becomes visible as the client navigates and interacts with the website.
What Is Server-Side Rendering, And How Does It Work?
Server-side rendering is the more common technique for displaying information on a screen.
The web browser submits a request for information from the server, fetching user-specific data to populate and sending a fully rendered HTML page to the client.
Every time the user visits a new page on the site, the server will repeat the entire process.
Here’s how the SSR process goes step-by-step:
The user enters the URL they wish to visit in the address bar.
The server serves a ready-to-be-rendered HTML response to the browser.
The browser renders the page (now viewable) and downloads JavaScript.
The browser executes React, thus making the page interactable.
What Are The Differences Between Client-Side And Server-Side Rendering?
The main difference between these two rendering approaches is in the algorithms of their operation. CSR shows an empty page before loading, while SSR displays a fully-rendered HTML page on the first load.
This gives server-side rendering a speed advantage over client-side rendering, as the browser doesn’t need to process large JavaScript files. Content is often visible within a couple of milliseconds.
Search engines can crawl the site for better SEO, making it easy to index your webpages. This readability in the form of text is precisely the way SSR sites appear in the browser.
However, client-side rendering is a cheaper option for website owners.
It relieves the load on your servers, passing the responsibility of rendering to the client (the bot or user trying to view your page). It also offers rich site interactions by providing fast website interaction after the initial load.