Use Cases for Server Side Rendering

Over the past 4 years, a number of client side JavaScript frameworks have popped up to help with the development of Single Page Applications (SPAs). The standard SPA is loaded from a server into the user’s browser during an initial request but from that point forward, the SPA handles all interactions with the user. This includes rendering pages. This approach has lead to much richer user interfaces and a more pleasant development experience, but there are downsides to doing everything on the client.

I used to think these downsides were obvious, but whenever anything about server side rendering comes up on Hacker News (like for example this discussion on Ember FastBoot), there seems to be disagreement over the value of server side rendering. So, I wanted to lay out what I feel are the top use cases for server side rendering in order of importance (from most important to least).

1. Perceived load time

The initial load of a client side web application is typically very slow. The Filament Group released a study recently that says the average initial page load time for simple Angular 1.x and Ember apps on mobile devices is 3+ seconds. It can be even worse for more complex apps. This is most often an issue for consumer facing apps, especially those that are typically accessed on a mobile device, but can be a problem for any app. Google often reminds developers that speed matters.

Where I work at GetHuman, the goal we try to reach is the full display of real content in under 1 second regardless of device or connection speed. This goal is much easier to achieve consistently with server rendering than client side rendering.

2. SEO

The Google search crawler continues to get better at indexing client side rendered content, but there are challenges.

• First, the crawler isn’t perfect (yet). There are a number of situations where the crawler may not index exactly what is rendered. This is often due to either JavaScript incapabilities or timing issues with async loading.
• With server rendering, the crawler can determine exactly how long it takes before document has been downloaded from the server and is available in the browser. It is not as easy to determine when asychronous JavaScript running in the browser is done doing work (and, as mentioned in the previous use case, when it is measured, it is often much slower than server rendering).
• There is no success story out there for a client side only web app that beats server rendered websites for competitive keyword searches (ex. think any major purchase item like “flat screen tv” or “best sedan 2015”).

There likely will be a future where server rendering is not needed for SEO, but today consumer facing apps that really care about their search ranking need server rendering.

3. Browser support

The downside of using more advanced web technologies like Web Components is that it is hard to keep support for older browsers. However, depending on the app being built, it may be possible to replace certain rich-client behaviors with server-side behaviors. This would potentially allow support of older browsers while letting app developers take advantage of the latest web platform. A couple examples:

• The app is mostly informational and it is OK for users on older browsers to just see the information without any of the client side functionality. In this case, it may be alright to give legacy browser users a completely server rendered website while evergreen browser users get the full client side app.
• An app must support IE9 (not an evergreen browser, but not as bad as IE8). Most of the client side web app functionality works, but there is one component that uses functionality not supported by IE9. For that one component, the app could potentially fetch the fully rendered partial HTML from the server.

Note that a given app may require features in modern browsers and there is no server rendered version that would help. This use case for situations where it is OK to have the app provide a static server rendered version of a component or page or website for legacy browsers.

4. Client side performance

The typical story for server rendering is that it covers the initial page load and then the client handles rendering from that point forward. However, there are situations after that initial page load where it would be faster to fetch a fully rendered page snippet from the server rather than render it on the client. For example, let’s say there is a mostly static, but complex product page. Consider the following situations:

• A section of the page takes a long time to render regardless of the best optimization efforts since it requires pulling down data from a very slow API call. The data for this partial does not change often, so we can cache a fully rendered version of the partial on the server and instead of pulling the data, we pull the cached, rendered partial HTML.
• Same as before except the API call isn’t quite that bad. It is debateable whether there is a benefit to do the partial server rendering at run time. However, you can set up a process where the rendered partial is either pulled asynchronously and cached on the client or, in some situations, even render the partial at build time.

It should be noted that Twitter has used this type of optimization for several years.

5. Link preview

Programs that show website previews for provided links rely on server rendering. Due to the complexity involved with capturing client side rendered web pages, these programs will likely continue to rely on server rendering for the foreseeable future. The most well known examples involve social media platforms like Facebook, G+ or LinkedIn. Similar to the SEO use case, this is only relevant for consumer facing apps.

6. Actual load time

The first and primary use case for server side rendering is perceived load time, but there is a way that server side rendering can also help with the actual load time of the app. In other words, the amount of time it takes for the client side web app to fully download and bootstrap in the client browser.

The initial load for the client web app is generally faster if the client code file is smaller and only executes what is needed to render the initial views. Then, other parts of the application are lazily loaded when needed or in the background. For the most part these types of solutions are implemented at build time. However, there may be additional optimizations that can be made and/or adjusted at runtime based off additional insight gleaned from actually executing the code on the server.

Note that this use case is mostly theoretical as I have not found anyone actually doing this. However, it is something I think is possible and I will be exploring this more in the future.

Conclusion

As you can see, there are many reasons why server side rendering is important for client side web apps. In fact, I believe that all major client side frameworks will have some form of server rendering in the future.

Do you agree? Would you change the priority of these use cases? Am I missing any use case that is important to you?