Overview

eCommerce exploded in the last 10 years, and many technological platform shifts have happened since. A flood of shopping carts such as Magento and Shopify has made it easier than ever to set up an online store, but at what cost?

A technological shift around 2004 with the advent of web 2.0, client-side rendering to make pages more dynamic took a strong foothold.

Developers began to move away from server-side rendering to client-side rendering which makes the experience more “dynamic.”

Business logic that was performed on the server was pushed off and onto the client, or browser rendering.

There is a trade-off of rendering on the web that you will see a performance hit, especially on mobile devices.

A shift has happened where mobile penetration has taken over the desktop, and now, we have to revisit these architectural design decisions so that we deliver the best possible experience with little trade-off in terms of functionality.

Terminology

When it comes to performance, we have to think about the 4 primary types of rendering techniques today.

Rendering Techniques

— Server-Side Rendering (SSR): A method of rendering an app through business logic on the server side and it returns final HTML markup from the server to the client to process.

— Client Side Rendering (CSR): The business logic of rendering has been pushed off to the client/browser which renders the app into the DOM.

— Rehydration: A method of leveraging Javascript “views” on the client which server rendered JSON data to “hydrate” the view and build out the HTML DOM.

— Prerendering: Similar to server side rendering. During build time, static pages are generated beforehand. This is a lot like how CDNs work today. It is to “prime” the cache by rendering the output and caching the resulting HTML markup to be served to the client.

Performance Metrics

— Time to First Byte (TTFB): The length of time between when the user has clicked or opened a link, to the first “bits” of content coming in the response’s body.

— First Paint (FP): The time it takes before any pixel is “painted” or visible to the user.

— First Contentful Paint (FCP): The time it takes before a significant piece of content such as article, body, images, etc. is rendered and visible to the user.

— Time to Interactive (TTI): The time it takes for a page to become interactive (user can perform search, scroll, click events, etc.)

Server-Side Rendering

Server-side rendering executes business logic and templates to generate the full HTML markup before it hands off to the client. The benefit of this UI design architecture is that it reduces round trip for getting data from APIs or DB to produce the DOM.

Server side rendering can produce a really fast first paint and first contentful paint because all the HTML markup is ready before it reaches the client. The client browser job will be less because it doesn’t need to make any additional round trip API calls to get data and generate the DOM. It avoids having to fetch business logic encapsulated inside Javascript code and evaluating.

Javascript evaluation is the most expensive job in the lifecycle of a webpage creation.

By reducing or “defer” Javascript evaluation, you can also achieve a fast Time to Interactive (TTI). All the heavy lifting is done beforehand.

This unblocks the browser from performing any CPU bounded client-side logic via Javascript that would need to be processed before the user is able to interact with the website.

While not all JS business logic can be performed on the server side, the logic that you do control will give you more budget and time for 3rd party scripts.

The one drawback to server-side rendering is a delayed, Time to First Byte (TTFB). 

Instead, this issue can be mitigated by “priming” the cached result of the HTML markup by using a CDN or caching it locally. 

This method works well for sites that do not need any personalization.

Depending on your website, you can work with a hybrid model by rendering static landing pages. Good candidates for this approach would be pages that need a high conversion such as a sales page, registration page, or checkout page.

And for interactive heavy pages, these static landing pages can leverage browser “prefetching” to begin fetching JS in anticipation that user will navigate to it. 

An example would be a user registration page to a web app would be rendered server side that prefetches JS to the app code. When the user has successfully registered, they are redirected to the app page with all the JS assets ready.

There are universal, isomorphic frameworks that allow you to work between these experiences. For React, there is Next.js and Vue, there is NuxtJS. Many of these frameworks use a hydration method, so make sure you to test and measure these metrics with Chrome’s Lighthouse.

Static Rendering

Static rendering is a method that takes server-side rendering one step further.

In the case with a CDN or a mechanism to prime the cache for first-time users, there is a performance hit for “first-time users” to build the cache if it’s expired or the cache needs to be created.

If you have a high traffic website, a CDN or creating caches on the fly will suffice.

However, if you want to make sure you have a consistent experience for all users, on any page, regardless if they are first-time visitors, then static rendering design offers this benefit.

The rendering happens during build time. Thus you get the benefit of fast first paint and first contentful paint and time to interactive.

Because the markup is created beforehand, it bypasses any server-side interpretation and accesses a compiled, final HTML output. And from this, you also get the benefit of a fast Time to First Byte.

The drawback is that since every page must be generated beforehand, the build time increases based on the level of complexity of your app.

Client Side Rendering

Client-side rendering (CSR) means all the business logic, data fetching, script evaluation, and rendering now happens on the client side instead of the server.

The benefit of this model is that it takes the burden off the web servers and the need to scale infrastructure to support the requests. And it pushes this off to clients to do the heavy lifting of script evaluation and execution.

For desktop users, this performance degradation is not as noticeable as for mobile devices.

First, desktop users are generally on a fast internet connection with a high-performance CPU.

Mobile users are at the mercy of their geography, distance/strength to cell towers, network bandwidth, and the device’s hardware.

As mobile penetration outpaces desktop, the “mobile first” tag line is more than just a visual tag line to design for mobile first, but also to develop an architecture for mobile first.

That is, you simply don’t want just a responsive UI, but a UI that loads up fast on mobile, regardless of network or device type.

It is essential in the design process to come up with a budget for Javascript size. We can make assumptions on an upper bound limit of just how much Javascript code is really needed to deliver the core experience.

And reducing the RTT calls to a minimum.

Leveraging provides the browser hints to start fetching Javascript asset and evaluate the parser as soon as possible to make the experience especially on mobile, “feel” snappier as they navigate between pages.

The drawback to client-side rendering is the dependency tree of Javascript grows as your app becomes more complicated.

Inefficient third-party libraries if not audited can bring in “dead” code that never is executed or applicable to the core experience.

Using Chrome’s Coverage tool, you can find these areas to improve on, and leverage code split to tree shake the absolute import only the necessary modules from a package or lazy load components on as needed basis.

Rehydration

Rehydration is a combination of server-side rendering and client-side rendering.

Sometimes called “universal rendering” or SSR, the final HTML is rendered in addition to an inline JSON object ready to be “re-hydrated” into the page.

If you were to turn off Javascript, you would see the page rendered beautifully as expected, and SEO crawlers such as Google Bot will adequately evaluate the Javascript code synchronously.

You’ll get the same benefits of server-side rendering performance of a fast first paint and first contentful paint and time to first byte.

However, the downside to server-side rendering with hydration is the app must re-execute again on the client side.

The time to interactive is hammered with this method as the JS code must be fetched, evaluated, and logic applied on top of the inline JSON model.

This could lead to some frustration to users on mobile who may see the page ready but is unable to click into an input field, submit forms, or scroll as the app is still being executed on the client side.

This can also add an additional tax on the server to perform life cycle updates once on the server side during the pre-render by fetching data from the database and again on the client side to provide.

This method of design should be avoided as it impacts the user experience by making putting the user into an experience that isn’t quite ready for interact which leads to a feeling of bugs and later abandonment.

SEO

Most of the techniques/strategies described in this article are when as engineers, we decide on the optimal solution for SEO without taking into considering of UX impact.

While SEO and server-side rendering are essential, just as important are 4 other metrics of user-perceived performance, first paint, first contentful paint, time to interactive, and time to first byte.

Each of these metrics working in symphony will derive the user’s perceived performance of a website.

Summary

The preferred approach for pages that requires a high conversion rate such as a checkout page, server-side rendering, static rendering, or pre-rendering is a must have over rehydration.

You may have wondered why your website/app may have different conversion rates for desktop vs mobile. In one case, one SAAS company reported that desktop SEO traffic converted at 10X more sign-ups than mobile traffic.

What they were not able to capture in the report is bounce report is based on “if” the page was able to fetch and execute the analytics Javascript code to fire the pixel event of a visitor.

If the JS app is too heavy on the sign-up page, especially on mobile, the user may not see anything, and abandon the page after 3 seconds before the ‘viewed’ pixel event for your analytics software is able to fire.

Here’s an infographic that shows and compares these approaches.

Chum Cart

These UX architectural principles are taken into considering during the design and build out of Chum Cart to be the fastest, mobile checkout experience.

Our ultimate goal or KPI is to focus on the 4 critical metrics, time to first byte, first paint, first contentful paint, and time to interactive to deliver the optimal experience to the user without any significant tradeoffs in features or functionality.

The goal of Chum Cart is to focus on the last page of your checkout funnel to eliminate cart abandonment on the mobile & desktop while increasing the AOV through order bumps, 1 click upsells and downsells.

If you like more information on Chum Cart, be sure to watch out this space for early access invite.

Author

Write A Comment