Deciding whether or not to SSR your application can be a giant undertaking. Since SSR is not always beneficial, the opportunity cost of SSR is punitively high. In many cases, a complete refactoring would be necessary to truly get accurate analytics on SSR.

Let’s get into how SSR works and why you may want it for your application. The largest benefit of SSR is the the boost to your application’s SEO. With the emergence of Single Page Applications (SPAs) that provide advantages in speed and UX, SSR is becoming more appealing. All the benefits of SPAs come with one very large caveat: the initial page load is usually an empty HTML file with links to Javascript and CSS but none actually included. This increases the time to “first meaningful paint” (FMP) which is when the primary content on the page becomes available on the screen. FMP varies from Instagram’s list of photos or the map on Google Maps.

The emergence of PWAs can be directly correlated to when Safari implemented service workers in version 11.1 of their browser. Service Workers are an offshoot of web workers that can run scripts in the background of the browser, acting like a proxy server, that can send push notifications, background sync, and a variety of other uses. Safari implementing service workers allowed developers to make one application that emulated native functionality and would be available across all browsers. One such example is Tinder who were one of the first companies to transition to SSR with the release of Tinder Lite. This is great for developers but also poses a problem: with slow FMP and without the comfort and searchability that application stores provide, how will PWAs attract first time users and compete with established webpages that have higher SEO and quicker load times?

Enter SSR. With SSR, search engine crawlers get FMP much faster making them competitive with smaller CSR apps. For example, Google’s web crawlers are better equipped to evaluate CSR apps over SSR apps, but the process is not perfect. From an SEO perspective, SSR apps perform better than their SSR counterparts.. Not only that, but competing search engines have yet to add the functionality to properly evaluate SSR apps. So why not just switch to SSR? Well, there are a few hurdles and SSR is not beneficial to all apps. There are a few libraries and frameworks that are geared directly toward accomplishing this goal.

One popular server-side rendering library is Next.js. Next.js allows for immediate SSR, has greatl documentation, and is updated regularly. As effective as it is, Next.js is not without its downsides. Unlike React, Next.js is a very opinionated framework that is very particular about how you interact with it. This can be a nightmare if you are trying to use Next.js on an established codebase. Conversely, if your application starts with Next.js and you want to refactor your project (e.g. adding Redux), you may find yourself at odds with Next.js.

React-Loadable is a library with a React API that has functionality for component based code splitting instead of the traditional route-based code splitting. Code splitting allows an app to be split into chunks which can be loaded either simultaneously or in a select order. This can make large applications interactive faster. Code splitting by routes can lead to large chunk size depending on the application’s layout and size. Comparatively, component based code splitting provides the option to load only the components needed at any given time. Giving priority to components that have high levels of user interactivity is a great step in improving UX.

Whether or not to SSR is a huge decision for any production level application. Rendering the application on the server is blocking so applications with constant server requests can become slow (which is why SPAs work great with SSR). The faster load time for SSR is just perceived, and applications rendered on the client actually have a better Time to First Byte (when the page is loaded completely). Recently, a powerful developer tool has been released for Create React Apps that can automate the process of converting your application to SSR. It also produces helpful analytics via Google Lighthouse and can help developers determine if their application should be server-side rendered.

See you on the Server Side!