JavaScript and single page applications (SPAs) are the cornerstones of the modern web. In contrast to traditional websites, typical SPAs use client-side rendering (CSR) which happens on the client browser. It has the advantage of providing new opportunities to create richer and more complex user experiences than ever before. But with great power comes great responsibility, and client-side rendered websites come with their own set of challenges. This article will explore the advantages and distinctive aspects of server-side rendering (SSR) versus client-side rendering and its relation with SEO.

The Differences Between Client Side and Server Side Rendering

• Where the rendering happens. In CSR, rendering happens in the client browser, while on the server-side the render happens in the server, this means in scenarios where real-time updates are needed, SSR is going to add a big latency penalty since the whole page needs to be retrieved on each call.
• Whose resources are we using? CSR uses the client web browser, therefore their CPU RAM and GPU. In SSR we need to allocate the CPU GPU and RAM for it.
• How many times do you render? Because of the previously mentioned performance considerations, in SSR we use to render once, cache it and serve it multiple times, while in CSR we render it every time on the client's browser.

What Is Server-Side Rendering?

A page is said to be rendered when its HTML fully represents the final state we want to display. Meaning, when we serve a single-page application since we need to render the final state in the client web browser using JavaScript, if the client cannot interpret JavaScript, they will not render our page. Server-side rendering consists of rendering our web application on the server then serving traditional HTML to the client.

When the client requests a traditional page, the server responds with a rendered HTML page containing all the necessary information. Still, on a single page application, the HTML we receive is not fully rendered. In most cases, the site relies on subsequent AJAX requests to get information and various JavaScript operations to render the website fully.

We can also server-side render those single-page applications. We can either run a headless browser in our server, run the single page application there, generate the final HTML fully rendered, or use some tool’s specific scripts to render the HTML.

There are different kinds of Server Side Rendered websites:

• Traditional SSR, serving static HTML or doing HTML pre-processing using Freemarker or any other server-side preprocessor language, generates a fully rendered HTML page that gets served to the client.
• Static SSR, here our web app is built as a single page web application (SPA), but all pages get pre-rendered on the server, and the JS is removed before serving it.
• SSR with (Re) Hydration, where our web app is also built as an SPA, and we create and cache a pre-rendered version of the website for JavaScript disabled clients, like search engines and social media crawlers. At the same time, we serve regular users the full SPA for them to Client-Side Render it.
• CSR with Prerendering, an SPA with the initial shell and skeleton pre-rendered in our server, could add simple meta tags to our SPA for social media crawlers and basic SEO improvements.

Why is Server Side Rendering Growing in Popularity?

The rise of single-page applications and modern JavaScript frameworks is driving the need for server-side rendering to improve SEO.

There are various types of server-side rendered (SSR) websites. The traditional kind we are used to — serving plain HTML or using Freemarker or any other server-side preprocessor language— generates a fully rendered HTML page that gets served to the client. And also the modern take of server-side rendering, where we fully render on the server a single page application that would traditionally be CSR, and generate and serve the fully rendered HTML based on it. The popularity of SSR is confirmed by the rapid growth of questions on Stack Overflow related to server-side rendering over the last few years.

Modern web development is all about components and reusability; the more reusable your components and services, the less code to write and maintain. That’s how we end up with single-page applications, a full JavaScript web application that fully renders in the client web browser, allows us to create rich interactive experiences as never seen before, decent performance, without any installs, easy to access since it's always just a single click away.

But there is a major drawback to single-page apps, as they tend to be bad out of the box in their SEO. The way we deal with that is using server side rendering.

How SSR Affects SEO

Google can interpret JavaScript websites, but we are not sure to what extent since Google won’t reveal many details about how they parse JavaScript-heavy web apps. Aside from that, here are some reasons why solely relying on the search engines to interpret your JavaScript might be a bad idea:

• It is slower, your page updates will take more time to be reflected in search results, and this single-handedly could reduce your traffic opportunities!
• It is less reliable. Even if the search engine renders it, we cannot be sure to what extent, so we could end up with no-follow links, a bad parsed structure overall, or a broken mobile experience.
• If our website can’t handle no-JavaScript scenarios, that could impact our search score.
• There are many other search engines besides Google, many of which cannot crawl heavy JavaScript websites whatsoever.

Social media platforms use meta tags to create previews of your posts and articles, and when shared, most of those sites won’t interpret JavaScript. Therefore, it cannot render CSR pages. Here SSR can also help prevent broken previews.

SSR Best Practices for SEO

SEO in CSR and SSR is not black and white. There are degrees of interoperability that we can navigate, but you should avoid full CSR web apps. Regardless of the approach you take, please consider the following when implementing an SSR solution:

• Confirm your page is being rendered correctly, take a deep dive into your rendered HTML, and check snapshots of the website based on the rendered HTML.
• Ensure your HTML result is mobile-friendly.
• Some SSR may be slow, so if you serve it on request, you will be penalized by the search engines if your response was too slow. Cache your results, and do it before the bots ask to be as part of your DevOps pipeline. And consider using a headless CMS like Crafter that natively supports high-performance SSR.
• Use Google's mobile-friendly tool test to ensure you are correctly rendering your page.

CrafterCMS Provides First-Class SEO Support

CrafterCMS enables SEO-friendly websites to be built with a wide variety of content authoring capabilities, including a best-in-class content authoring environment that allows content creators and editors to optimize URL structures, metadata, mobile experiences, and more. Moreover, CrafterCMS provides developers with total freedom to implement sites using technologies and methodologies that work best to solve the challenges they face.

CrafterCMS supports both client-side and server-side rendered approaches. For sites that require the best SEO, Crafter supports traditional SSR with Freemarker, as well as SSR for SPA development using React, Angular, Vue and any other JavaScript framework of choice. Moreover, Crafter provides native server-side scripting support for Groovy that enables you to deliver high performance results. In addition, Nodejs, Nextjs, Nuxtjs and other server-side technologies are supported via Crafter's JavaScript SDK. 

Major enterprises use CrafterCMS to build and manage large-scale, SEO-friendly websites that deliver top-ranked search engine results for their content. To learn more, read the Case Study Penn Mutual: CrafterCMS Enables Modern Digital Experiences for Life Insurance Leader.