How can we help?
Let's Talk
How can we help?
Let's Talk
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.
By Vidya Chokkalingam
Chief Technology Officer. Technology executive and product manager focused on consumer-facing & B2B web companies, big data plays, cloud-based platforms in U.S. and international markets.