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.
When it comes to performance, we have to think about the 4 primary types of rendering techniques today.
— 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.
— 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.
— 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 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.
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 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.
And reducing the RTT calls to a minimum.
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 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.
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.
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.
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.
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.
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.