This website uses cookies to ensure you get the best experience on our website. Learn More.

In the name of SEO: Server-side rendering for single-page apps

The mobile-first application development trend has reshaped the way we expect our content to be delivered to us. There are not a lot of areas where web-based applications prevail over the mobile ones. At least entertainment-wise, we are totally sold on the iPhone or Android apps. One of the most accustomed to and secretly painstaking qualities of mobile apps is the speed and smoothness of transitions between screens.

In the name of SEO: server-side rendering for single-page apps | Shakuro

The amount of wait time we are ready to grant to our apps these days is extremely short, which puts developers into deep waters of optimization and improvement. More so, web-based applications have to follow through and emulate the mobile speed in order to stay friendly to the impatient user of 2018.

Single-page applications

The mobile UX does rely on real-time transitions and animations to illustrate user input. The traditional page refresh/reload which is an attribute of website experience had to go in order to create a continuing seamless interaction. As the result, a notable number of websites started running as single-page applications (SPA).

Technically, SPA is one page that loads entirely once you open the website. As you move along the site, different pages load dynamically. This allows smooth mobile app UX to be emulated on the desktop.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Gregory Muryn-Mukha

With that said, there is a substantial drawback which results in a fairly small amount of websites being built as SPA as compared to the traditional multi-page platforms. The drawback is search engine optimization or SEO.

SEO-friendly SPA

The standard behavior of a search engine robot (a.k.a web crawler) is irrelevant for SPA because all the content that SEO relies upon is absent. It is generated, pulled, and displayed upon demand on the client side. For that, a lot of websites use async AJAX calls, which are basically JavaScript injecting new content code from a server depository into a specific page without reloading the entire site in the browser.

So, for a web crawler, SPA is an empty shell with no remarkable content, which is good for UX as users don’t have to see the page reload and staying in the pocket.

In the name of SEO: server-side rendering for single-page apps | Shakuro
This architecture allows fast interactions and mobile app-ish feel to it, but how does it perform SEO-wise? It makes a lot of sense when you think about a quality content which is hardly indexable by search engines, as well as for understanding how the rankings work.

It’s almost counterintuitive to see how many SPA websites rely on content. Their primary promotion media is the original content they produce which also has to be presented in a proper way. This puts us in a weird state where you have to either push the UX and strive for seamless transitions, or make the best out of the content you produce and make sure it googles well.

SEO for web crawlers

A common misconception about SEO is that web crawlers won’t be able to go through a page without it being completely rendered in the browser. They see the HTML code sent from the backend and don’t consider it to be meaningful content at all.

So if you have your content page modified with JavaScript, Google made a tool called “Fetch as Google” to show you what it sees on a page. It turns out, Googlebot can work with async JavaScript.

Googlebot will give a webpage at least 20 seconds to complete asynchronous calls.

At the same time, while client-side content rendering is fairly safe for Googlebot to see it, there are still some concerns:

  • There might be edge cases with some websites’ specific architecture which might result in Googlebot’s inability to render the content.
  • Modern CSS can cause issues for Googlebot and prevent content from being crawled.
  • Even the indexed page might not be ranked properly.

In order to be relevant, Googlebot works like a browser. As stated in 2017, GoogleBot is based on Chrome v.41 to crawl the web and it hasn’t been updated yet. The current version of Chrome is 66, which means the bot doesn’t see everything the latest version of Chrome sees when crawling the web. On top of that, since 41 there has been a lot of new APIs released, and allegedly, Googlebot can’t render and index the pages based on those APIs.

This puts us into a rabbit hole where we have to consider old browsers when building our web apps, as well as the web crawlers based on those older versions.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Denis Krol Krasavchikov

The solution

Since we want our web apps to not only look good, feel right, and work fast, we want them to be visited, that means, to be found by the search engines. SEO, in that regard, is a crucial tool (the only, safe to say) and it has to be approached wisely.

SPAs are good for UX but might not perform right business-wise if not tweaked correctly. One of those tweaks is Server-side rendering.

Server-side rendering (SSR)

The SSR principle is based on the SPA architecture of rendering a page on the web server part during the request & response exchange. Typically this is achieved by running the web app through a Virtual Document Object Model (VDOM).

When the state of application changes, the VDOM translates into an HTML code string which is then injected into a page and sent in response to the client. On the client end, JavaScript distributes the received data over the existing shell.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Leo Leung

The SSR approach makes a page visible for SEO because the content is there whether or not the web crawler works with async JavaScript.
At the same time, SSR might contain some disadvantages:

  • Costs. Implementing SSR requires a lot more time and thus, money.
  • Limited backend environment. SSR only works with Node.js. The functionality of non-Node environment backends (like V8 Javascript Engine for PHP or React Pre-Rendering via RPC)  is functional, but still quite minimal.
  • Bulky code. The SPA code has to be able to work both in the client-side browser and the server-side JavaScript environment in terms of APIs and objects.
  • Complicated UI interactions. The amount of JavaScript code required to fulfill modern UI principles almost nullifies the benefits of SSR. It might be better to use static app shell instead.   
  • “Six of one and half a dozen of the other”. The SPA will have the additional load on requests which depending on the type of content, might slow down the responses, at least at the initial cache load.

In order to make SSR work for your specific app, you have to decide whether you need it in the first place.

You need SSR, or do you?

Truth is, the SEO of your web app might work best with the right SSR. The same way, the UX of your app might be better off without it. It depends entirely on the goals and specifics of your web application. There are workarounds that could save you a ton of resources without breaking the flow.
To define your further actions regarding SSR, consider the following:

The focus of your activity

The value of your SPA has to be based either on textual content or performance. In other words, is your app content-focused or action-focused.

If you expect your users to perform some sort of an action right after they land on a page, you don’t need SSR.

SSR takes a bit of time to complete the request and mount the content. As the result, your users might get caught in a murky state of a page being visible, but not actionable. If you are dealing with an experienced user, this is likely to frustrate them. Clicking and tapping the UI elements will only make it worse.

If your content is text-based, a user expects to see the text right away, the content supply has to be steady and very responsive. At the same time, it has to be crawlable in order to fit your search query.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Zhenya Rynzhuk

Authentication

SSR of your content is required to immediately engage your users in a textual or visual conversation. In our age of anxiety and digital ADD, it is extremely important. However, there is a tolerance window you can squeeze into. That window is the power of habit.

Due to the years of online experience, we are accustomed to certain things like the request-response situation. We do not expect an immediate reaction from a person. That’s why we have this ? Likewise, we can tolerate a page reload if we make a proper input. Log in or sign in is such an input.   

If your web app has user area where it unfolds most of its potential, you don’t need SSR.

Think of it as a door. In order to enter the room, you have to open it, step in, and close it. This is such an autopilot thing, that it does not frustrate us at all. With that said, once you are in the room, you won’t tolerate any hurdles anymore.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Gabriel Avédikian

Content-heavy first page load

If your SPA is content-heavy (with unique textual information), chances are you using deep linking to the specific, generally searchable or indexed, pieces of content on your website.

SPA utilizing deep linking for promotion can benefit from SSR.

The thing about deep links is whenever a user clicks it, they expect to be redirected immediately to the relevant piece of content. That means the content has to be there at the first page load. In order to maintain the flow and present value without breaking the experience, use SSR as the fastest way to process HTML and parse JavaScript, or additional requests.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Igor Gedz

Keywords & social sharing

Like we said, Googlebot can execute JavaScript, parse and rank SPAs. Not all web crawlers are capable of doing that, but all of them can work with the content response from the server.    

If keywords are important for your app’s SEO, for example when running an online store, SSR is mandatory.

The UX of a single-page application, especially in e-commerce, requires the content to be displayed with no delay. In its turn, SEO needs the content to be on-page in order to read it and rank the page.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Oliver Dead

SSR tools

Due to the large spectrum of variables of SPAs where SSR or partial SSR can be used, there is no better way to configure SSR rather than manually. The majority of SSR is done in JavaScript frameworks like Ember, React, or Angular. As we know, SSR is important for single-page applications relying on such frameworks when search engine optimization is important for the business or the initial content render makes the difference.

Ember Fastboot 1.0

Fastboot runs your Ember web application over Node.js and responds with the initial HTML which is then run in the browser.

ReactDOMServer

ReactDOMServer is a part of the React API. Its purpose is to render components into HTML strings. Being still in works, this tool requires a lot of manual labor with React Router and Redux libraries, to make them work under the conditions of partial server/client application rendering.

Vue.js & Nuxt.js

Vue.js works like a glue between a Node.js server and the SPA code. The process of loading the VueJS application in the browser is called hydration. Nuxt is a framework for creating universal applications with Vue.js easier. It is aimed at solving the task of configuring for the usage of SSR with Vue.js.

Angular Universal

Angular Universal is the middleware that lives between Angular and Node.js. Simply put, AU is  “Server-side Rendering for Angular apps” that unifies high performance and UX of SPAs and SEO liability of a static page website.

Takeaways

The idea of giving users a consistent experience regardless of the type of application they are using is dictated by the usability progress of the mobile technologies. However, the web is different in terms of access. You can build a fast and beautiful single-page app but you can’t install it on someone’s laptop like you do a mobile app. This means your SPA has to be searchable and indexable by web crawlers.

Implementing SSR requires a great deal of manual work so you have to consider whether it’s worth it beforehand. For this, look into the UX of your SPA along with the business logic.

In the name of SEO: server-side rendering for single-page apps | Shakuro

Image credit: Sebastiano Guerriero

In 2017, we witnessed the rising developers’ interest in the state of SSR within different frameworks, not only JavaScript. Major frameworks like Ember and Angular that cover the entire architecture of an SPA are interested in integrating a viable SSR solution in them.

At the same time, there are promising side projects, such as Next.js and Nuxt.js looking to establish a solid SSR structure within the existing frameworks.

*  *  *

Written by Moses Kim

May 05, 2018

Subscribe to Our Blog

Once a month we will send you blog updates