Frontend developers play a critical role in the modern digital experience. As new technologies emerge, they need to use their expertise to determine which tools and design approaches to use.

Regarding websites and other content-rich web apps, frontend developers have several options, from which JavaScript frameworks to use to how the site should be rendered. As new approaches such as Jamstack have heralded the reemergence of static sites, there are three primary approaches to consider: static sites, server-side rendering, or client-side rendering.

Today we’ll break down each of these options and include potential use cases and examples to help you determine which approach is best. We’ll also explain why you need a CMS capable of delivering content using any technique.

What Is a Static Site?

A static site is a pre-rendered web page that is stored in cached files on a server or content delivery network (CDN). The website is delivered to a web browser exactly as the files are stored, enabling a static site to load at lightning speed.

Static sites are built using HTML (either by hand or by using a static site generator), CSS, static assets like images, and basic JavaScript code. Also, since the files that make up a static site are loaded the same way each time, static sites provide a consistent viewing experience.

Some of the benefits of static sites include speed and performance since loading time is significantly reduced compared to alternative dynamic sites. They also provide enhanced security since a static site doesn’t need to interact with a backend database often, lowering the risk of malicious attacks. Due to these benefits, static sites are great options for small enterprise websites, microsites and landing pages.

Read More: Static Sites vs Dynamic Sites: Modern Enterprises Need Both

What Is Client Side Rendering?

Client side rendering (CSR) is an approach that involves rendering content in the browser using JavaScript. Rather than pulling all of the content that is pre-rendered (either statically or dynamically on the server side), CSR uses a bare-bones HTML document that includes JavaScript to render the rest of the site on the browser.

Client side rendering is slow in the initial stages, but then additional pages can be loaded quickly. Using CSR, the browser only communicates with the server at run-time. As a result, the entire page doesn’t need to be reloaded whenever a request is made to the server. Instead, only the changed data on the page is rendered again.

The fact that CSR removes the need to reload every time the user makes a new request means that it’s ideal for websites that involve heavy user interactions, such as social media pages and certain types of single page applications. Any website with a complex user interface and advanced features, tons of dynamic data, or several users are ideal options for client side rendering. However, there are downsides to CSR as well, given the load on the browser at the beginning, and the limitations of SEO for public-facing websites/webapps.

Read More: SEO for Single Page Apps: The Need for Server Side Rendering

What Is Server Side Rendering?

Server-side rendering (SSR) is a web development approach where content stored on a server (usually in a CMS) is dynamically converted into content that can be displayed on a browser. When a user makes a request, the requested data is fetched from the server and then sent to the browser. The process should happen within milliseconds. However, every time a user clicks something on the page, a new request is made to the backend content services. So having a high performance backend is paramount.

Server side rendering is ideal for dynamic web applications, such as those that are personalized for different users, for internationalized sites (to target the right language to the right audience based on profile or location), for employee intranets, customer/partner portals, e-commerce experiences, and for many others where content targeting and personalization are required. Digital web-based products are usually built with SSR as well.

Why You Need a CMS That Can Handle All Three

Most enterprises need several options when it comes to choosing how to build and deploy their websites, portals, intranets, and other content-driven digital experiences. Static sites with the help of a static site generator are incredibly useful for modern approaches such as Jamstack. However, server-side or client-side rendering is better in other situations. Here are a few reasons you should consider a CMS that can handle every situation.

Flexibility and Agility

Businesses and developers need to choose different approaches for various scenarios. Many organizations will have some projects that are best served by static sites, such as landing pages and microsites. For other projects, especially within larger enterprises and fast-growing startups, client-side rendering and/or server-side rendering will be a better fit. Using each of these approaches at the right time allows businesses to remain agile and can also help them save time and resources rather than trying to do everything the same way each time.

Search Engine Optimization

SEO is critical for any business that wants to rank well on Google, so for all your public-facing websites you want to be sure that they are optimized correctly. SSR is great for sites that need strong SEO, whereas sites rendered using CSR will suffer from poor SEO.

Any experience where first-page load performance is key should rely on SSR. A CSR approach will suffice for applications that don’t need such quick loading. Unfortunately, Google and other search engines struggle to crawl client side rendered sites. It is possible, but the site needs to be implemented in a particular way otherwise, the crawler won’t be able to read the links and content on the page. As a result, the slower speed and performance scores can negatively affect SEO rankings.

Handling Dynamic Content

Enterprises also need the option of implementing dynamic experiences in various situations. Personalization is especially important for global enterprise websites, corporate intranets, customer and partner portals, e-commerce experiences, media and entertainment sites, to mention a few. Delivering dynamic content is fundamental to many modern websites and customer experiences.

CrafterCMS: An Agile Headless CMS For All

For modern enterprises, a headless CMS offers the best option when it comes to content delivery across many digital channels and a variety of digital experiences. It provides the flexibility to deliver content to more than just a website, allowing businesses to take advantage of multiple channels and multiple experiences. However, many headless CMSs only provide direct support for client-side rendering and/or static site generation, which limits the options for many enterprises.

To fill this gap, CrafterCMS provides a headless “plus” platform that enables management and delivery of content to multiple digital channels for all types of digital experience, and offers first- class support for SSR, CSR, and static site applications. CrafterCMS provides a comprehensive set of RESTful APIs and a native GraphQL server (any and all of which may be used for CSR, SSR, and/or static site generation), and platform-oriented SDKs (e.g., SSR via Nodejs, Nextjs, Nuxtjs, etc.), allowing developers to choose the tools they prefer for each project.

Instead of being restricted to using SPAs for every project, CrafterCMS also provides native support for HTML5 templated sites through Freemarker templating (also SSR), which can be used to quickly build experiences where templating is better suited, such as microsites, landing pages, and more. CrafterCMS also supports fast and easy Groovy scripting for extending the base APIs, creating new custom APIs and integrations, and for SSR applications.

At the same time, CrafterCMS’s best-in-class authoring experience allows content authors to create and manage content and experiences using powerful WYSIWYG editing and drag and drop tools, for any and all types of use cases - CSR, SSR, and static sites.

See how CrafterCMS fills the gap that other headless CMS platforms miss by watching our webinar: Server Side Rendering: The Missing Component of Headless CMS.