SEOs talk about how things are ‘rendered’ on websites all the time, but what exactly do we mean when we’re talking about this? Well, in typical SEO fashion, say it with me: it sort of depends.
Rendering, in website terms, simply means how instructions in code are turned into something users can see or interact with on a website.
For instance, your browser turning HTML and CSS into styled text and images is rendering. In the example below, you can see the HTML code on the left — these are the instructions. And on the right, you can see how that code is rendered by your browser to become the stylized text users see on a page.
HTML is not a programming language — you can’t write software with it. HTML (usually coupled with Cascading Style Sheets, or CSS) is just code that instructs a browser on how text, images, and other content should be displayed on a website (controlling things like where they appear on a page, the fonts used, colors, etc.).
Enter “client-side” vs “server-side” rendering (and enter the Hamburger Analogy)
This is useful because it means the page you’re looking at can be updated constantly—in real-time. For example, an eBay listing is updated in real-time so that everyone is aware of what the winning bid is at any given moment.
(I’m getting to the burger bit, I promise.)
Effectively, server-side rendering is like going to a restaurant and ordering a burger — the kitchen receives that order, puts the burger together, then sends it out to you.
Client-side rendering, on the other hand, is like the kitchen sending you the things you need to make a burger and telling you to get on with it yourself.
The Hamburger Analogy for Client-side vs. Server-side Rendering:
Obviously, in this instance, client-side rendering is great because you have more power to customize the burger however you want, rather than asking the kitchen to do it — but the problem for a long time in SEO was that Google would either refuse to put their own burger together or try to do it, make a huge mess, and get ketchup on their shirt and mustard in their eye.
Prerendering is really useful if, for example, you have a data source that doesn’t change very often, but the process for checking the most up-to-date price takes a long time to run. Let’s imagine a price comparison site that checks prices in 100 different stores.
Running the price-checking script every single time a page is requested is enormously inefficient and in some cases, could take a very long time, which would delay getting the full page back to the user. So instead, what the website creators may elect to do is run that script at a set time every day, then use the information that is returned to build pre-made HTML pages that can be served on request — it’s kind of like ordering at McDonald’s.
The potential issue with prerendering, just like with McDonald’s, is that as soon as the webpage is made, it begins to become stale or out of date. And if those pages aren’t refreshed frequently, then the content in them may no longer be valid. However, it’s a balancing act for website developers; often the ability to get the pages out quickly and without fuss may well outweigh the potential concern around slightly out-of-date information.
Where things start to get a little bit spicy is when sites send a pre-rendered version of a page to Google and a client-side rendered version to users, based on the requester’s user-agent.
Why might this be done? Well, while Google can nowadays fairly reliably crawl and index client-side rendered pages, doing so requires more computational power than simply requesting a standard HTML page and analyzing the response. Due to the additional computational power required, pages that need to be client-side rendered are processed based on the initial response, then go into a separate queue for rendering.
Here’s what that looks like, per Google Search Central:
Image Source: Google Search Central
And as such, if your page relies on JS to generate important, structural content, you may find that Google takes longer to process and index it—which is often far from ideal from an SEO perspective.
So, should I use client-side or server-side rendering for SEO?
There’s no single answer to this, as usual, because it depends enormously on what your site or page does.
However, as with most technical SEO recommendations, the fewer barriers you can give to Google when it comes to loading your pages, the better.