CSR, SSR, & SSG: Which Rendering Model to Use, and When
Have you ever considered the idea that different types of websites are actually built differently? It’s clear that websites all function differently. In fact, there seems to be no limit to what we can do online, from shopping to exercising to investing to planning a trip, along with myriad other tasks and activities - but websites are also uniquely constructed. In that sense, they’re similar to buildings. Websites, like buildings, are specifically designed and built to address a range of unique factors and considerations:
What is its primary purpose?
How frequently will it need to be accessed or updated?
How easy should it be to find?
Depending on the answers to these questions, a front-end web developer must decide which tools to use to most effectively build a website, which can quickly become confusing. For example: workflow management or file hosting sites may opt for CSR, especially if a site is an SPA, but that could potentially compromise SEO. Alternatively, a business website with a static list of service offerings would probably rely on SSG, but may want to consider SSR if there’s any concern about keeping content up-to-date. Getting lost in this sea of acronyms can easily become a source of frustration for a developer (not to mention those without a technical skillset or education), especially as more options for rendering models become available. This article aims to demystify these tools, and provide a clear roadmap for when they should be used, and why.
Client Side Rendering (CSR): When Functionality Matters Most
CSR is the tool of choice for web applications, and for web pages where discoverability is irrelevant, and/or data updates frequently. With CSR, the server/computer sends a near-blank HTML page accompanied by a signal to the client/browser to render the contents of the page using JavaScript. Said otherwise: CSR allows a developer to create a website that is rendered entirely in the browser. Instead of generating an individual HTML script for every route on the server, CSR creates each individual route directly in the browser. This means that CSR works fast, once it’s loaded, which makes it the tool of choice for web applications and certain web pages. CSR facilitates the frequent update of data, and so it works well for web apps. Web apps are designed to allow users to quickly progress through specific, interactive tasks, like data entry or generating reports. Each individual click through these apps must happen quickly and without interruption, and so CSR is optimal where these tasks are completed through web apps. Unlike web apps, websites are simply places where information is stored. That being said, certain sites lend themselves well to CSR, especially sites where SEO is not relevant, like sites with user dashboards, log-ins, or paywalls. CSR’s ability to support frequently updating data works well for certain interactions, but it isn’t ideal where SEO is a primary concern. CSR works quickly because virtually no HTML is being created on the server and transmitted to the client. Less HTML, however, means less discoverability. For sites intended to attract a lot of users, SSR or SSG are preferable.
Server Side Rendering (SSR): When Access Matters Most
SSR is the tool of choice for sites with dynamic data that require SEO. With SSR, HTML content is generated on-demand on the server and compiled before it’s sent to the client, where it is displayed immediately. This is unlike CSR, where only a bare-bones HTML page is sent to the client for rendering. For sites with dynamic content that changes frequently depending on the user, SSR is the best option. This is because the server is sending completely rendered content to the client, which the client sees almost immediately, and without interruption. Social media sites and large e-commerce sites rely on SSR to constantly refresh their content and keep the User Experience seamless, and up to date.
Due to the fact that the web page (HTML) content is rendered on the server in the first instance, SSR is a fantastic option for sites where SEO is front of mind. Search engines like HTML content, and can fetch it easily, and quickly. While SSR is a prime tool for facilitating discoverability and keeping information up-to-date, there’s a third rendering option that might work even faster.
Static Site Generation (SSG): When Speed Matters Most
SSG works well for sites with static content that require SEO.SSG works a lot like SSR, but instead of asking the server to generate content on-demand (at ‘request time’), it asks the server to generate HMTL content at ‘build time.’ Essentially, this means that a site relying on SSG won’t change or update unless new components or content are added. Thus, this tool works best for sites with ‘static’ content: content that doesn’t tend to change very often, and looks the same for most users. For sites that mainly serve to provide information (like a website for a business, for example), SSG works well because it’s low-maintenance, fast, and great for SEO, which favours fast loading times. With SSG, page loading times tend to be very quick, given the absence of calls back to the server.
CSR, SSR, or SSG: How to Get From A to B?
It can be difficult to sift through these tools and decide which is best for a given project. After all, it’s often desirable that a website be functional, discoverable, and fast, and the reality is that there are myriad tools and plug-ins available to ensure that a site runs optimally, regardless which rendering model was originally employed to construct it.
Ultimately, building a website is just that: a construction. It’s the development of a resource for a specific purpose. In that way, it requires consideration similar to that involved in the construction of a building:
What is its primary purpose?
How frequently will it need to be accessed or updated?
How easy should it be to find?
Where a site must be primarily functional - easy and fast to use, but not necessarily discoverable - CSR might work best, as it efficiently facilitates processes through web apps or dashboards. Alternatively, where a site must provide uninterrupted, up-to-date information that’s easy to find and access, SSR might be the best option, as it supports a constant flow of content, and works well for SEO. And where speed and searchability are the primary considerations, SSG most appropriately supports a site with relatively static content designed to promote and provide information. The key with building a website - as with anything - is to build a strong foundation. Deciding which rendering model to use is part of that foundation-building process, and it’s one of the first steps towards creating something that’s not simply fit for purpose, but built to last. Come join us! Visit our xDesign Careers page.
