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.
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.
Get hands on with an Elastic Path Free Trial
Start building the commerce experience your unique business demands with a free Elastic Path Commerce Cloud account. Get in touch with us and we will setup a Free Trial store for you for six weeks.Sign up for a free trial
Client-Side Rendering (CSR)
The term Single Page Application comes from two parts:
- The server only has a single HTML page.
- 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.
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.
Like what you’re reading?
Check out some of our other great content here
Get actionable insights on ecommerce trends and best practices
You'll receive a welcome email shortly.