When it comes to choosing how to render your website or application, a common term you’ll hear being thrown about is “pre-rendering,” whether it’s in the context of rendering methods and JavaScript frameworks or, more generally, in relation to browser technologies. This can often get quite confusing, especially if you’re new to the technology and the various ways it can be applied.

So in this post, we’re going to cover what pre-rendering is (both in terms of how you build your application or website and how the term applies to technologies implemented by browsers like Chrome) and the benefits it can bring. Then we’ll take a look at how we can get started with pre-rendering in our own applications and how to choose the best type of pre-rendering for us.

Key terms to understand first

Before jumping into the main portion of the article and looking at pre-rendering in more detail, along with the problems it solves, we need to establish the definitions of some keywords that are important to understanding pre-rendering in general.

Run time

In the context of pre-rendering web pages, run time refers to any code execution that happens after the user has requested the page. You can consider that the website is running after the user requests a page so any code that is executed after this point would be classed as running at run time. For example, if a website performs an API request when a button is clicked, this would be happening at run time.

Client-Side Rendering (CSR), which is the default for an application built with React, for example, would be a good example of code running at run time. The user visits the page and sends a request to the server for a pretty bare HTML file and the required JavaScript to render the page. Then the browser receives the bare HTML file from the server, and the JavaScript executes on the client device to render the interface for them. All this happens after the user requests the page; in other words, it happens at run time.

Build time

Unlike run time, where the code runs in response to the user’s request, build time is where the code runs prior to any user requests and is used to prepare your application’s code for deployment or production.

A good example of build-time code execution would be static site generation with a JavaScript framework like Next.js. At build time, Next.js takes all of your code, pages, and files and transforms them into them production-optimized files that are ready to be deployed to the servers that will host the files for users to request and consume.

This all happens through a series of scripts that compile everything so that it’s ready for a browser to simply display when it arrives in response to a request.

What is pre-rendering?

Finally, we have pre-rendering, the core focus of this article. Pre-rendering most commonly refers to compiling code at build-time and is the process of generating a website's pages and content while the website is being prepared for deployment. In the case of Chrome’s pre-rendering feature, it means that the browser predictively renders the pages before the user has requested them.

By using pre-rendering, as soon as a user requests a page, there is no page rendering required and instead, they can be sent the fully rendered page ready for viewing and interactions.

What problems does pre-rendering solve?

Pre-rendering is great at solving some common issues with websites, and in particular, the ones experienced by Client-Side Rendered (CSR) applications and websites like single-page applications (SPAs). Let’s explore those problems and how pre-rendering helps solve them.

Slow rendering times / bad performance

CSR websites have multiple steps involved when it comes to actually rendering the website to the user (read more here if you’re interested in learning about how it works). All these steps need to be executed after the user has requested the page, and they can take a fair bit of time on slower devices and connections.

Pre-rendering aims to resolve this by shifting the rendering step to occur before the user requests the page. This means when the user requests a page from the website, they can be immediately responded to with little to no delay. This near-instant response by the server drastically improves rendering times and overall performance.

Bad SEO scores

CSR applications are infamous for their poor SEO support and scores because search engines often can’t render their pages very well, leading to poor indexing and, in turn, poor performance in search engine results.

Pre-rendered websites, on the other hand, can have much better SEO scores. This is because pre-rendered websites generate the final HTML output for a page at build time. This means when it’s deployed, every search engine is able to read the pages without any issues making it much easier to parse and index your pages. It’s worth noting that there are some edge cases to this, such as Google Chrome’s pre-rendering we’ll explore later in this post. But, on the whole, pre-rendering will lead to better SEO performance.

How to pre-render your website

When it comes to pre-rendering your website, there are a few options at your disposal to actively implement pre-rendering. In this section, we’re going to look at a few of them.

Static site generation (SSG)

Pre-rendering using static site generation (SSG) is the approach most people are familiar with. It’s when we take a series of pages and content and transform them into production-ready static HTML files at build time.

This type of pre-rendering is often built directly into frameworks and tools like Gatsby, Next.js, Hugo, etc. These frameworks make it really easy to implement and develop websites using SSG. If you’re using one of these frameworks, it will automatically generate the static HTML pages for each page of your application at build time. Then your files can be easily deployed to a hosting provider of your choosing.

This method of pre-rendering should be your first choice since frameworks make the process effortless and a dream to do. So if you’re starting a new project or are already using one of these frameworks, this type of pre-rendering is the best one for you.

Pre-rendering Services

The next method of pre-rendering we’ll be looking at is pre-rendering using an online service such as prerender.io or Netlify Prerendering (BETA). These services aim to offer pre-rendering functionality to applications and tools that don’t have an inbuilt pre-rendering functionality. For example, if you’re using something like Create React App (CRA) that generates SPAs these services would allow you to take your otherwise Client-Side Rendered application and pre-render it.

When it comes to configuring these services, they vary in complexity. Netlify’s service, for example, is largely automated and done for you. All you need to do is enable the option in your dashboard’s settings. Prerender.io, on the other hand, is a bit more involved and requires a web server to be configured using something like Node.js and Express; you can see the entire guide for Node.js and prerender.io here.

This type of pre-rendering isn’t as convenient or as flexible as one of the frameworks or tools for SSG mentioned in the last section, but they’re a great option if you’re unable to use one of those options. If, for example, you’re stuck with CRA and unable to migrate from it, using one of these services could aid you in achieving the pre-rendering benefits we’ve covered.

A different kind of pre-rendering in Google Chrome

In the previous two sections, we’ve covered pre-rendering methods that align closely with the notion that pre-rendering is a way to generate pages at build time before any user requests. But, in this section, we’re going to explore a different type of pre-rendering you may have also noticed while searching around to understand the term, which is pre-rendering with Google Chrome.

When someone is using Google Chrome, the browser will automatically try to work out which pages need to be pre-rendered on your website and will do it in the background for a user as they are searching and navigating to your website. Google implemented this functionality in order to improve user experiences in their browser.

What this means is that this method of pre-rendering is out of your control, unlike the previous two methods, which you make a conscious choice to use. This is largely because Chrome will choose whether to pre-render a page or not based on the user’s settings, the memory usage of their machine, and other heuristics that we’re unable to control or influence. The only way we can influence Chrome’s decision is by using the Speculation Rules API to tell Chrome which pages you’d like to pre-render, but this isn’t guaranteed and Chrome can ignore it. (You may also remember that you were once able to set a rel=“prerender” on links, but that’s been deprecated.)

So, overall pre-rendering via Google Chrome is trickier to set up because, firstly the user must have the “reload pages for faster browsing and searching” setting enabled on their device. And, then even if the setting is enabled, pre-rendering isn’t guaranteed unless their device is in a state that enables it.

While I wouldn’t rely on this method alone if pre-rendering is something you’re serious about, it’s an interesting move on Google’s part and reflects the value of the benefits pre-rendering can bring.

Deciding which method is right for you

To round out this article, let’s cover how you can decide which method of pre-rendering is best for you and your application or website.

First Option: If you’re using or are able to use a framework or tool that natively provides SSG for pre-rendering, then this is your best option because you’re fully in control of whether the page is pre-rendered or not, and it doesn’t rely on an external service.

Second Option: If you’re stuck on using something that uses CSR, like a single-page app, then using a pre-rendering service is a good option to get the benefits of it without changing your website’s core architecture.

Last Option: Finally, Google Chrome’s pre-rendering is something to be aware of, and you could follow the Speculation Rules API to increase the probability of your pages being pre-rendered by it. But you shouldn’t rely on it as your sole method of pre-rendering since it’s largely out of your control.

Closing Thoughts

With that covered, it brings us to the end of our journey of all things pre-rendering. So, I hope you now have a better understanding of pre-rendering and how it works, as well as how it can help you, your website, and your users.