Put simply, rendering is what your browser does when navigating a webpage. When you open a web browser like Chrome, Firefox, or Safari and click a link or type a URL, your browser requests the computer hosting the website for the data to display the page in question. It then decodes that data and uses it to construct and display — in other words, render – the webpage.
The decoding process involves multiple steps, which result in the browser constructing two models: the domain object model (DOM), which defines the relationships between each of the HTML elements on the page, and the CSS object model (CSSOM), which defines how those elements are styled.
Having done this, the browser combines the DOM and CSSOM to determine how to lay out the content on the page. Once this stage is complete, the browser finally starts drawing the pixels to the display.
The HTML file returned in response to the initial request contained most of what was needed to render the webpage, so the browser could immediately start decoding the content and building the page (subject to a few calls to fetch images as needed).
<meta name=“description” content=“Hello World”>
<img src=“example-image.jpg” alt=“Here is some alt text”>
Instead of receiving an HTML file with all the content set out in divs and paragraphs, the browser receives a file referencing one or more scripts.
Because these scripts can change both the page content and styles, the browser has to fetch and execute them before it can construct the DOM and CSSOM, and, therefore, before it can determine the layout and start drawing pixels on the screen.
<meta name=“description” content=“Hello World”>
var addImg = document.createElement(“img”);
addImg.src = “example-image.jpg”;
addImg.alt = “Here is some alt text”;
Using scripts to construct the page has several advantages. Because you can pass values into the script each time it is run, you can tailor the response to user inputs and create an interactive experience.
You can also update content dynamically (rather than requiring the user to reload the page) and provide functionality that was previously only possible using an installed application.
Why does rendering speed matter?
For your content to appear in search engine result pages, it must first be crawled and indexed by that search engine. The process starts with a search engine crawler discovering the URL and making a request for the page content –— just as your browser does when you click a link — and waiting for the response in the form of an HTML file.
Slow and unresponsive pages are frustrating for users and result in higher bounce rates, damaging your search rankings.
As we’ve seen, the time taken to fetch and execute scripts can make pages slower to load and prevent search engine crawlers from reading the content on your site, harming your search rankings. That’s not to say that client-side rendering should never be used — if your page response varies with each request, then it may be the best approach.
Various strategies have been developed to improve performance on client-side rendered pages, such as keeping script size down by splitting code bundles, lazy-loading, and caching scripts that are re-used across multiple pages.
Using these techniques helps reduce load times for users accessing your site on mobile devices and increases the likelihood and speed with which search bots will index your content.
Server-side rendering (SSR) refers to how websites used to be served; when a request for a URL is made to the server, the HTML is generated on the server and then sent to the browser for display. Generating the response on the server means fewer and faster roundtrips to fetch resources (such as scripts and images) compared to client-side rendering but at the expense of slowing down the initial response.
Static site generation
Static site generation, also known as pre-rendering, is an alternative to server-side rendering that works well for some use cases. Whereas server-side rendering requires the page to be generated on the fly when it is requested, static site generators produce the HTML for each URL ahead of time — usually as some kind of build step for the site — so that it’s ready to serve whenever it’s requested.
This means you can use a CDN to cache content on edge servers, further reducing page load times. Gatsby and Jekyll are two popular static site generators, while Next.js combines static generation with server-side rendering.
Generating pages in advance works well for sites with a lot of static content, such as blog posts, product listings, articles, marketing pages, or help documentation.
The downside is that you can’t respond to “live” data in the request, so it isn’t suitable if the content is frequently updated or changes with each request. In these cases, you need to render the page dynamically on the client, the server, or a hybrid combination of the two.
Hybrid rendering options
There are advantages to both client-side and server-side rendering (and its cousin, static site generation). Rather than choosing one over the other, combining both techniques within a single page is possible.
Multiple variations on this theme need to be implemented carefully to avoid creating a disjointed experience or presenting users with an unresponsive page.
Dynamic rendering is a workaround to the SEO issues associated with client-side rendering and is recognized as a legitimate technique by search engines, including Google and Bing.
With this approach, you have two versions of each page: a statically rendered version that is served only to bots and the regular client-side rendered version for human users.
For each request, you first need to detect whether the request is from a real person or a crawler (for example, via the user agent) and then serve the relevant response.
When using dynamic rendering, it’s essential that both pre-rendered and client-side rendered content are very similar. Returning substantially different content is considered cloaking – something you want to avoid at all costs.
Of course, this approach doesn’t speed up content delivery to real users. If performance is an issue, you will also want to use other techniques to accelerate time to interactivity for your client-side rendered pages.
While no single approach solves all problems, you’re not limited to choosing just one strategy.
You might choose sever side rendering or static site generation for pages with little or no interactive content, such as product listings and blogs, and keep client-side rendering for highly interactive pages and add dynamic rendering to improve their crawlability.