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.
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.
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.
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.
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.
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.
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.
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 is 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).
At the same time, SSR might contain some disadvantages:
- Costs. Implementing SSR requires a lot more time and thus, money.
- “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.
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.
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.
Keywords & social sharing
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.
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 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 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.
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.
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.