A few of our current clients have requested a template-based system to render their products for their marketplace, and over the past few years, a number of client side JavaScript frameworks have popped up to help with the development of single page applications. 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 faster and optimizing for search engines. This approach has led to much richer and refined user interfaces and a more pleasant development experience, but there are downsides to doing everything on the client side.
This brings us to a question: “Do all clients benefit from server-side rendering?”. At Transcend Digital, we wanted to lay out the top consideration factors for server-side rendering in order of importance.
Perceived load time
Google often reminds developers that speed matters and load time affects user experience and searchability. The initial load of client side web applications is typically very slow. The average initial page load time for simple Angular 1.x and Ember apps on mobile devices is 3+ seconds for a headless Shopify platform and for a car listing website. 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. At Transcend Digital, 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.
Crawling and indexing
The Google search crawler continues to get better at indexing client side rendered content, but there are challenges. First, the crawler isn’t perfect. There are several 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 a document has been downloaded from the server and is available in the browser.
Further Reading:
It is not as easy to determine when asynchronous 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 “best skincare for pores'' or “best sedan 2020”). 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.
SemRush or Ahrefs? Break the SEO Suspense
Discover the SEO champion between SemRush and Ahrefs in our detailed comparison.
Static vs Dynamic content
With server side rendering, 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 with videos similar to our implementation for PMD Beauty (download the full case-study here). 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 debatable whether there is a benefit to do the partial server rendering at runtime. 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.
