HTML Rendering in Digital Commerce Websites

Since the introduction of Single-Page Applications, the web has debated between delivering HTML directly from a server or rendering that HTML within the browser. Each comes with pros and cons favoring either content rich pages or highly interactive experiences. Digital commerce is a blend of both rich product information and robust checkout funnels and must find balance between server-side rendering and client-side rendering.

Play Video

Static Rendering

Static rendering is where a fully formed HTML file exists for each page of a website, the file exists on a hard-drive or cloud storage and is then served to the client when requested. When a client or browser requests the HTML there is no code executed, databases to call, or other changes to the content of that HTML document.

This was the original approach to serving websites and HTML was created or written by hand. Recently, static sites have come back into popularity, but instead of writing and managing each HTML file manually, code is leveraged to combine content and templates to pre-generate the HTML in a build step before copying those files to the server. This is referred to as static-site generation and is a key component to JAMStack.

Dealing with static files comes with multiple benefits, the first being website performance. These files can be quickly served on request, distributed through a CDN, and easily cached. There are no steps required between requesting the HTML file and displaying the content.

Another major benefit is security as it’s extremely hard to hack a basic server distributing files, especially when using modern techniques and a content-delivery network. Since all the code required to build the HTML files happens during a build step there is no need to expose that code to the wider internet and it removes this code as an attack vector.

This speed and simplicity make the content easy to read and crawl by bots, which is beneficial for search engine optimization (SEO) and can improve rankings.

The problem is that these static sites lack any type of dynamic or interactive functionality which is a non-starter for digital commerce. Basic features such as a cart are impossible, let alone highly personalized recommendation engines or A/B testing. So, the best case is to combine static assets with dynamic content driven via APIs. A common JAMStack approach is to statically generate all product pages, but to render the cart through client-side rendering. This brings the second major problem, which is website updates. Since content is updated during an expensive build-step any content changes wait for that build. This can be run through a CRON job, but is far from immediate.

Server-Side Rendering (SSR)

Server-side rendering (SSR) is a technique where a server generates the HTML for a particular page and sends it to the client. This page is created dynamically when requested, often combining templates with data queried from an API or database. When we hear the term Server-Side Rendering the context is often around single-page applications or progressive web apps, but it predates both. This is the default rendering option for most of the web, but was previously not discussed as there was no alternative.

From the client or browsers perspective server-side rendering looks the same as static rendering, it simply includes a slight delay as the server collects the needed information and builds the HTML. It is also great for SEO. These pages can also include dynamic content based on the user information.

The main drawback to server-rendered pages is the level of interactivity and the overall user experience. Clicking a link or adding an item to the cart requires a new request to the server and an entirely new HTML page to be served. This is a large amount of data to transfer when you may only be incrementing the cart count in the header, in addition the entire page will disappear and be reprocessed which is jarring to the customer.

While the initial page load is fast, navigating the website or crafting highly interactive experiences is not nearly as fluid as client-side rendering.

Sign up for a free trial

Client-Side Rendering (CSR)

Client-side rendering (CSR) is a technique where a browser executes JavaScript which generates the necessary HTML. This was popularized with single-page applications (SPA) which instead of serving multiple content rich HTML pages sends a single HTML document that contains the necessary JavaScript includes. In a SPA JavaScript takes the role of generating all HTML, handling navigation, and ensuring the right content is displayed.

The term Single Page Application comes from two parts:

1. The server only has a single HTML page.
2. This technique is designed for applications instead of websites.

When you consider web applications, for example Gmail or the Elastic Path Commerce Cloud, users typically enter the application from a single point (the sign-in), initial load time is less important than a great experience as users will enter once and spend many hours in the application, and SEO is not a concern.

This is in stark contrast to websites where users will come from a search engine or backlink to any relevant page and may only spend a few seconds or minutes on that page.

Despite the fact that SPAs were designed and optimized for applications, users loved the great UX and seamless navigation, and they started being leveraged for more traditional websites or digital commerce.

Having JavaScript load all content made websites difficult to crawl by bots, though the Google bot can execute JavaScript, SPAs suffer for SEO when compared to traditional websites. In addition, the JavaScript files can get very large so when first visiting a website users encounter slower load times and delays before seeing the requested content.

Merging Techniques

With the hopes of getting the benefits of both SSR and CSR, developers looked at merging the two techniques. The first approach was to run the rendering code on both the client and browser, this became known as Universal or Isomorphic rendering. This approach can take the advantages of both SSR and CSR and minimize the drawbacks. By using this technique, the initial load of the page is done by the server using NodeJS which can be rendered immediately with HTML, then the JavaScript takes over and improves the dynamic features of the page. This allowed bots to see the initial HTML improving overall SEO, allowed the browser to paint the content prior to loading and executing all JavaScript, and maintained the streamlined UX of a SPA.

The problem with isomorphic rendering was twofold, the hand-off between server and client execution and the lack of rendering control in the application. After the browser rendered the initial page the JavaScript was required to take over, unfortunately many libraries struggled to re-use the HTML already in place and instead re-rendered the entire page. So while the content was displayed quickly, any interactivity waited for the full SPA to load and execute. In addition, if the server-rendered HTML had any differences to the JavaScript rendered version the page would randomly change soon after initial load.

Isomorphic rendering also required both the server and client to have matching capabilities, both being able to render all parts of the page. While this works, it failed to take into account that server-side execution has security benefits, and some components may be more optimal when rendered client-side.

While isomorphic rendering was an attempt to merge the two with existing tools, web frameworks have evolved to take a more transitional approach. New frameworks allow rendering to transfer seamlessly from server to client with progressive or partial hydration and include opportunities for developers to determine if code should be executed client-side or server-side.

The Elastic Path Composable Frontend leverages NextJS which includes these options. The page is server-rendered and then progressively enhanced in the browser. Where necessary an API route can be created for server-only execution or the “use client” directive can be added to components at the top of the file to ensure client execution.

In summary, the choice between server-side rendering and client-side rendering depends on the specific requirements and constraints of the project. Content heavy websites should lean towards SSR to improve initial load time and SEO, while web applications and highly interactive websites should focus on CSR for improved UX. Digital Commerce should take advantage of transitional apps like Elastic Path’s Composable Frontend to seamlessly move between both techniques depending on the specific site-section.

In conclusion, while server-side rendering and client-side rendering are both valid options, each has its own set of benefits and drawbacks. The specific requirements and constraints of the project, such as performance, SEO, accessibility, and development environment should be considered when making the decision. Also, the choice between them can also be influenced by the needs of the development team, security, and caching requirements.