- Server side rendering (SSR) — the traditional rendering method, basically all of your page’s resources are housed on the server. Then, when the page is requested, the HTML is delivered to the browser and rendered, JS and CSS downloaded, and final render appears to the user/bot.
The Main Differences between SSR and CSR?
Server side rendering can be a bit faster at the initial request, quite simply because it doesn’t require as many round trips to the server. However it doesn’t end here, performance also depends upon some additional factors. All of which can result in drastically varied user experiences:
- The internet speed of the user making the request
- How many active users are accessing the site at a given time
- The physical location of the server
- How optimized the pages are for speed
Client side rendering, on the other hand, is slower at initial request because it’s making multiple round trips to the server. However, once these requests are complete, CSR offers a blazing fast experience via the JS framework.
Here’s a useful metaphor describing the difference between SSR and CSR:
With server-side rendering, whenever you want to see a new web page, you have to go out and get it, this is analogous to you driving over to the super market every time you want to eat. With client-side rendering, you go to the super market once and spend 45 minutes walking around buying a bunch of food for the month. Then, whenever you want to eat, you just open the fridge.” — Adam Zerner
Why is this Trend Happening?
In the past, JS was predominantly used to add various levels of interaction to a web page. This was achieved by referencing JS libraries like JQuery. Because the JS was simply manipulating the HTML content already present in the source code, there was little issue with search engines discovering and indexing the content. However, with the JS frameworks and CSR of today, all of a sudden the source code for a webpage is practically blank and the content exclusively rendered by JS execution on the client side.
This complicates things for search engines, but Google is really the only search engine today that is even somewhat posed to handle it. None of the other search engines have anywhere near the JS rendering capabilities being employed by Google presently. This means that even if your CSR content can be indexed by Google, it’s probably not being indexed by any other search engines.
Google has recently revealed their current two wave process for JS rendering and indexing at Google I/O.
The first wave requests source code, crawls and indexes any present HTML and CSS, adds any present links to the crawl queue and downloads page response codes.
- On a client side rendered site however, there’s basically nothing for Google to index in the source code during this first wave.
The second wave can occur a few hours to even a few weeks later, Google returns to the page when additional resources are available to fully render and index the JS generated content.
- This means that where as in SSR there is generally no issue with Google’s rendering delay because the content is all in the source code and indexed during the first wave. In CSR, where the indexable content is only revealed at render, this sizable delay can mean the content may not be indexed or appear in search results for days or even weeks.
You may be asking yourself,
This additional work to render JS is not unique to just search engines though, you can also witness the effects of increased JS rendering strain on your own devices as well:
- For user comps (user desktops, laptops, mobile, tablets, etc.), their CPU capabilities can differ greatly for each device type, for example a mobile device’s CPU will generally struggle more with a heavy JS laden site than a desktop comp.
- As a result, it is always a good idea to test the pages using Chrome Dev Tools’ “Performance” tab to test the run time performance. Here you can test device performance via network “throttling”, which helps to simulate different mobile device CPU capacities, different internet speeds, and how well your pages are handled at those specifications.
What are the SEO Implications of SSR and CSR?
For server side rendering, all of the HTML content is present in the source code which means the search engine can request, crawl and index it immediately. Resulting in faster time to actually appearing and ranking in search results.
For client side rendering, the HTML needing to be indexed is only revealed when the JS is fully rendered on the client side. Thus, with the two wave system Google currently employs, it can take anywhere from a few hours to a week before the content can be crawled, indexed and begin ranking in search results.
This time frame is also not taking into account whether there is prioritization logic at work on Google’s end. If so, in some instances it could potentially take even longer.
What’s the Solution?
There are two primary solutions to this problem:
1. Pre-rendering — Essentially consists of listening and sending a pure HTML snapshot to the search engine bot when it requests your page. This ensures that the user can still enjoy the fast speeds provided by CSR, while also serving the search engines the HTML content needed to index and rank your pages.
- Implementation can be tricky, and many developers struggle with it. It can also be quite expensive given the resources needed to successfully implement. Extensive research should be done to determine the best way to perform SSR with your JS framework. Here are some resources on how to do SSR for both Angular and React.