Server-Side Rendering Explained

Introduction

The world of web development has changed rapidly. Over the last fifteen years, web pages have evolved from simple HTML text to multimedia interactive experiences, elevating web development to art. That’s like a civilization going from stone houses to space exploration in a century. 

Two of the most significant advancements in web development during this period have been the adoption of JavaScript frameworks to build web pages and the field of Search Engine Optimization.

Ironically, JavaScript development and SEO are often at odds with each other. JavaScript makes websites fun and interesting to use, while SEO makes them available for people to find in the first place.

Server-side rendering (SSR) was created to make them both possible. Read on to learn about what SSR is, why you should care, and how you can use it for yourself.

What Is SSR?

Server-side rendering (SSR) is a method of loading your website’s JavaScript on your own server. When human users or search engine web crawlers like Googlebot request a page, the content reads as a static HTML page.

Historically, search engines have had difficulty crawling and indexing websites made using JavaScript rather than HTML.

Google indexes JavaScript-based web pages using a two-wave indexing system. When Googlebot first encounters your website, it crawls your pages and extracts all of their HTML, CSS, and links, typically within a few hours.

Google then puts the JavaScript content in a queue, rendering it when it has the resources. Sometimes that takes days or weeks. During that time, your web pages are not being indexed and, therefore, are not being found on Google. That’s a lot of traffic you’re missing out on. 

What’s worse, if your JavaScript pages aren’t able to be crawled and indexed properly, Google reads them as a blank screen and ranks them accordingly, which can be catastrophic to your website’s SEO health.

Google has claimed that Googlebot is able to crawl and index Javascript-based web pages just fine, but this has yet to be proven. Other search engines such as Bing, Yandex, and DuckDuckGo cannot crawl JavaScript at all.

Regardless of the search engine, JavaScript presents a problem because it needs additional processing power to crawl and index, thereby eating up more of your website’s allotted crawl budget.

SSR is designed for this problem. It renders JavaScript on your own servers rather than putting the burden on the user agent, making the content fast and easily accessible when requested.

What Is Client-Side Rendering and How Is It Different From Server-Side Rendering?

Client-Side Rendering (CSR) is the increasingly popular alternative to SSR. The difference between the two is similar to ordering a prepared meal kit from a service like Blue Apron or Green Chef, or buying all the ingredients and making the meal yourself. 

Client-side rendering loads a website’s JavaScript in the user’s browser, not the website’s server. It’s ordering the prepared meal kit.  

Websites built with front-end JavaScript frameworks such as Angular, React, and Vue all default to CSR. This is problematic from an SEO standpoint because when web crawlers encounter a page on your website, all they see is a blank screen. 

Server-side rendering, meanwhile, is the more traditional option; it’s buying the groceries and cooking the meal yourself. It loads your JavaScript content on your website’s server. 

SSR dates back to the time when JavaScript and PHP were primarily backend technologies, and Java was used simply to make HTML-based websites more interactive rather than building them from scratch. 

SSR converts your HTML files into information that’s readable for the user-end browser. Googlebot can see the basic HTML content on your web page without JavaScript in the way, while the user sees the fully-rendered page in all its glory. Your website is ranked properly on Google, and your user is treated to a web experience that’s a feast for the eyes and ears.

Advantages of Server-Side Rendering

We’ve already discussed some of the SEO benefits of server-side rendering: flawlessly crawled and indexed JavaScript pages, no more wasted crawl budgets or plummeting search rankings, no sluggish two-wave indexing process; just smooth, seamless indexation and the steady stream of Google traffic that comes with it.

SSR has even more advantages than the ones above. 

It optimizes web pages for social media, not just search engines. When someone shares your page on Facebook or Twitter, the post includes a preview of the page.

It comes with a number of performance benefits that improve your website’s UX. SSR pages have a much faster load time and a much faster first contentful paint because the content is available in the browser sooner. That means less time your user has to look at a loading screen. 

JavaScript is resource-heavy and code-intensive. Downloading it onto a browser using CSR contributes significantly to page weight. A single JavaScript file averages out to about 1MB, whereas web development best practice advises keeping the entire page under 5MB max. 

The performance enhancements that come with SSR also have their own SEO benefits.  

Google gives preferential search rankings to the sites with the fastest page load speed. Faster load times improve user metrics such as session duration and bounce rate; Google algorithms look at these metrics and give you an extra SEO boost.

Faster web pages. Happy search engines. Happy user.

Server-Side Rendering Disadvantages

If SSR is so much more technically well-optimized and SEO-friendly, why don’t all websites use it?

Turns out, using SSR for your website does come with some significant drawbacks. It’s expensive, difficult to implement, and requires a lot of manpower to set up. It also puts the burden of rendering your JavaScript content on your own servers, which will rack up your server maintenance costs.

Websites that use JavaScript frameworks need universal libraries to enable SSR; Angular requires Angular Universal, React and Vue need Next.JS. All of them require additional work from your engineering team, which costs you money.

SSR pages will have a higher TTFB latency and a slower time-to-interactive. Your user will see the content sooner, but if they click on something, nothing will happen. They’ll get frustrated and leave.

SSR is not a fix-all solution. You need to assess your website’s technical needs and challenges before putting it in place.