Headless CMS - SSR as an important part of the platform

The effectiveness and performance of web applications are key to success for any online business. Dynamic and fast sites attract users, provide quality experiences, and increase conversions. One method that helps web applications achieve these goals is Server-Side Rendering (SSR). This technique generates web content on the server side, offering several benefits for users and developers.

Server-Side Rendering is a technique for generating web content on the server side. In SSR, both JavaScript and HTML are rendered on the server and sent as a whole to the browser. This makes the page content visible even when JavaScript is turned off, which, among other things, speeds up page loading and facilitates indexing by search engines. This technique improves performance and enhances user experience and the effectiveness of SEO efforts.

In the context of Headless CMS, SSR increases the flexibility and performance of applications, enabling better use of modern front-end technologies. In this article, we will take a closer look at the definition and applications of SSR.

Technical functioning of SSR

In SSR, the processing and generation of web pages takes place on the server, before the finished HTML code is sent to the user's browser. To better understand how SSR works, let's trace the various stages of the process, from the moment the browser sends a request to the display of the finished application on the user's side.

1. Browser request: The user's browser sends an HTTP request to the server, asking it to display a web page.

2. Request processing: The server receives the request and begins processing. At this stage, the server may collect the necessary data from various sources, such as databases, APIs, or simple markdown text files. This data includes information about the appearance and layout of the menu, the content available on the page, and the components (blocks) used.

3. HTML rendering: The collected data is then used to generate HTML code on the server side. This process can include the execution of templates, integration with content management systems (CMS), and the processing of JavaScript needed for dynamic page elements.

4. Sending the response: The finished HTML code is sent back to the user's browser. Unlike Client-Side Rendering (CSR), where the browser must first download and process the JavaScript, here the browser already receives a fully rendered HTML document.

5. Page Display: The browser displays the HTML code it has received, allowing it to deliver the page content to the user immediately. Thus, even if JavaScript is disabled in the browser, the basic content of the page remains visible.

6. Launching the application: As soon as the HTML code is loaded and displayed, the browser launches a JavaScript application that can add interactivity to the page. JavaScript takes control of the dynamic elements, allowing, among other things, asynchronous loading of content from the server.

   
   

Technology stack

The technology stack for SSR includes several key tools and frameworks that work together to provide application performance and flexibility. In the case of Vue.js, one popular tool is Vite, a modern and ultra-fast bundler that significantly speeds up the processes of building and running applications.

Another framework used for SSR is Vike, which offers a very transparent flow and a rich array of events that can be influenced. It allows you to control the behavior of your application on both the client and server side, also offering its own routing system. 

This makes it easy for developers to manage routing in the application, which is crucial in the context of SSR and internationalization. Vike integrates seamlessly with the Vue.js and Vite ecosystems, creating a powerful tool for building modern, high-performance web applications with server-side rendering.

Why is SSR important?

Server-Side Rendering is mainly used in situations where fast page loading and better indexing by search engines (SEO) are needed. It is especially important for dynamic web applications that update their content frequently, such as news sites, blogs, social networks, and E-commerce platforms. SSR is also chosen when an application requires advanced business logic that is better implemented on the server side, such as user authentication or content personalization. 

Advantages of SSR

1. Better indexation by bots (SEO improvement): Since the page content is fully rendered on the server side, search engines can easily index the page, improving its visibility in search results.

2. Faster page loading: Users are provided with ready-to-use HTML, which significantly reduces the time it takes to load and display the page.

3. Library of reusable components: The ability to create and reuse components, such as a hero slider or a block of recent blog posts, increases the efficiency and consistency of the application.

4. Delivery of HTML along with JS: The site is delivered as finished HTML with embedded JavaScript, providing full functionality even without JavaScript enabled in the browser.

5. Support for SPA (Single Page Application) pages: SSR does not close the way for the use of Single Page Application. Although the HTML code is generated on the server side, we can still take advantage of all the benefits of modern applications running directly in the browser.

6. Hiding server-side logic: The ability to control which logic is executed on the server side and which is executed on the browser side, which can increase security and control access to content.

7. Greater server-side capabilities: The server has access to all cookies, which allows more advanced operations than those available on the client side (HTTP only). We can also send HTTP requests to any external address without worrying about CORS restrictions.

8. The ability to cache rendering results: The server can cache rendering results, which speeds up subsequent requests, reducing server load and improving performance.

Disadvantages of SSR

1. Slower response to user interactions: Each interaction requires contact with the server, which can slightly delay responses compared to client-side rendered applications.

2. High entry threshold: SSR technology requires advanced API support. If the script encounters a server-side error, it will be visible in the server logs and the user will receive an HTTP 500 error, requiring front-end developers to pay attention to the backend.

3. More difficult to run on shared hosting servers: Setting up and running SSR can be more complicated than for standard web applications. In this case, it is necessary to run an application that acts as an HTTP server and configure ReverseProxy to the appropriate port. In most SharedHosting services such options are unavailable to clients. You can then use cloud solutions such as Netlify.

4. Tougher debugging: In SSR, debugging is more complicated, as problems can arise from both the generation of server-side content and how the frontend interprets that data. This often requires checking server logs and verifying data consistency between the server and client parts.

5. Hydration mismatch: The "hydration" process assumes that the generated content on the server will be identical to the content running in the browser. Differences between these environments can lead to errors and synchronization problems.

SSR offers numerous benefits, but it also requires proper understanding and skill to use it effectively.

Some common elements in projects

Projects using Server-Side Rendering often have some common elements that help manage and render content effectively. Here are the most important of these:

Menu

Menus in SSR projects are a key element that must be dynamically sourced and rendered. Typically, the server sends a request to the appropriate API to retrieve the menu structure and then generates the appropriate HTML code, which is sent to the browser. This ensures that users always see the current menu, regardless of their language preference or location.

Breadcrumbs

Breadcrumbs help users navigate the site. Generating breadcrumbs can be problematic in that not all API services allow for their simple generation. Sometimes this requires sending additional queries to the API which, of course, negatively affects server-side generation time. In such cases, it is useful to implement automatic scripts that determine the path of breadcrumbs for each page and store it in the cache.

Internationalization

Internationalization is a key element in international projects. It requires special queries to the API to handle different language versions. Each language version of a site may have a different URL, but lead to the same components. This requires the server to properly process and return content in the appropriate language.

Renderer

The Renderer in SSR projects receives an array of data objects that must be generated one by one. The process involves recognizing whether a component is registered in the application, anonymously assembling it, and injecting the data. We aim to use the renderer in the same way so as not to create excessively customized views and to maintain application consistency.

Router

The router is especially important in the context of internationalization. Different language versions have different URLs, but they lead to the same components (e.g. "Contact us" = "Kontakt"). This needs to be taken into account in the router settings, where paths are defined to correctly redirect users to the correct version of the site.

API

The methods of connecting to the API vary dramatically depending on the content manager chosen for the project, Regardless of the content management system and the standard of communication (RestAPI, GraphQL, text files), the data structure in the components should be identical to maintain the reusability of the blocks. It requires providing additional translation layers between the CMS API and component API, but in the end, we get a project that is relatively easy to migrate to other systems. We can use the blocks in other projects and deliver more products faster. 

Is SSR necessary for the Headless approach?

Server-Side Rendering is not always necessary with a headless approach. SSR works best for dynamic content that changes frequently and requires frequent publishing. With SSR, a page can be rendered on the server every time a user visits it, allowing the most up-to-date data to be displayed. This is especially important for high-traffic sites, where users expect data to always be fresh and updated in real-time. 

However, implementing SSR can be complicated and requires advanced management of server resources. For many projects, an alternative may be Static Site Generation (SSG), which offers slightly different advantages and is often easier to implement.

From an SEO perspective, it is crucial to provide correctly rendered content to both users and search engine robots, regardless of the technology used. It is also important for the website to load quickly and efficiently. In the case of Headless CMS, Server-Side Rendering (SSR) is a great solution because it speeds up the loading of subpages and provides full control over the presented content, which guarantees correct indexing and eliminates potential problems related to JavaScript rendering. You just have to make sure it doesn’t overload the server - says Adam Halbersztadt SEO Specialist at Salestube

What is Static Site Generation?

Static Site Generation (SSG) is a technique that generates static HTML files based on all available URLs on the system. This process is done before the site is deployed to the server, which means that the entire set of HTML files is ready to be loaded, without the need to run the NodeJS server.

Advantages of SSG

SSG is simpler to implement and deploy because it doesn't require running the NodeJS server. Static HTML files load very quickly, which improves user experience and benefits SEO. Additionally, static sites are less vulnerable to attacks because they don't have a dynamic server layer to target.

SSG disadvantages

However, SSG has its limitations. Updating content generally requires re-generating and deploying the entire set of HTML files, which can be time-consuming, especially if you have a lot of content. SSG does not work well for highly dynamic content that is updated frequently. In such cases, SSR may be a better solution. There are implementations where only a selected collection of subpages is generated however, there is then a risk of data inconsistency if the generated pages have external relationships to other content, which is not easy to track. The surest method is to regenerate everything.

SSG is great for smaller sites with more static content, where changes are less frequent and implementation time is not critical. The choice between SSR and SSG depends on the project's specific needs, content characteristics, and performance requirements.

Examples of SSR implementations by Salestube

Alokai - a project based on Contentstack

In the Alokai project, built on the Contentstack platform, we used SSR to optimize page loading. As a result, it only takes one request per page to load all the necessary elements. In the response (response), we immediately get information about the structure of the menu, footer (footer), and content on the page. This way of working significantly speeds up page loading and improves the user experience.

Our website - a project based on Storyblok

In the Salestube project based on Storyblok, the page-loading process required a slightly different approach. Despite sending a single request for the page, it was necessary to send an additional query to get the full data. Fortunately, Storyblok's infrastructure is efficient enough that it does not require an additional caching layer to ensure satisfactory loading times. As a result, it was possible to maintain high performance and speed of the site, despite the need for additional queries.

myERP.pl - a project based on WordPress

In the myERP.pl project, built on the WordPress platform using WPGraphQL, we must first query the content page, after which we get an array of objects containing values with unresolved associations. For example, if we want to get recommended posts from a blog, we get the numbers of those posts and perform another request to get the full objects of those posts, such as image, title, or description. Then we make another request for menus, languages, and footer (footer). One request collects page settings from several places, which can increase processing time. 

We solved this by using GraphQL, which allows us to retrieve many different contents in a single request. We also implemented a double layer of caching: Full Page Cache, storing all generated HTML until updated, and additional caching at the GraphQL query stage. Everything is stored in a high-speed Redis database. Such a solution is only possible with SSR - on the client’s side, it would not be possible in this form.

Alternatives to the SSR approach

There are many frameworks and tools that offer alternative approaches to Server-Side Rendering (SSR) or combine different rendering techniques to optimize performance and user experience. Here are some popular options:

• Next.js - Next.js is a React-based framework that allows easy implementation of SSR, as well as Static Site Generation (SSG) and incremental static regeneration (ISR). It is especially popular among React developers, thanks to its flexibility and support for the latest web technologies.

• Nuxt.js - Nuxt.js is a framework based on Vue.js, which offers similar features to Next.js. It allows server-side rendering, static page generation, and Single Page Application (SPA) development. It is an excellent choice for projects using Vue.js.

• SvelteKit - SvelteKit is a modern Svelte-based framework that supports SSR, SSG, and hybrid rendering approaches. Thanks to its performance and simplicity, SvelteKit is becoming increasingly popular among developers looking for modern solutions.

• Gatsby - Gatsby is a React-based framework that focuses on static page generation (SSG). It is ideal for sites with content that rarely changes, but can also be used in conjunction with dynamic data sources, thanks to its flexible architecture and rich plugin ecosystem.

• Universal (Angular Universal) - Angular Universal is an extension for Angular that enables SSR. It allows Angular applications to take advantage of server-side rendering, which improves SEO and page load times. It is a natural choice for Angular-based projects.

One might get the impression that such a wide range of technologies requires an individual approach and separate team onboardings, which calls for additional resources. This is partly true - only because different CMSs may have specific beneficial features in one area but at the cost of certain limitations. However, based on our experience to date, we managed to obtain a consistent approach regardless of the selected system. Thanks to this, work on subsequent projects is faster, and more efficient, and developers can improve their skills in the technology stack we have designed - says Justyna Leśnikowska Tech lead forntend developer at Salestube powered by hmmh

Server-Side Rendering (SSR) is an effective web page generation technique that optimizes loading speed, improves indexation by search engines, and provides a better user experience. 

The most important information to keep in mind is:

• SSR for dynamic applications: Among other things, it ensures fast page loading and better indexing.

• Technological flexibility: Tools such as Next.js, Nuxt.js or SvelteKit allow you to customize your approach according to project requirements.

• SSG as an alternative: It offers simplicity of implementation and faster loading times for static content.

SSR and SSG offer a wide range of possibilities, allowing you to create powerful, modern web applications tailored to different needs.

Facing challenges in implementing Headless CMS or Headless E-commerce? Contact us to discuss fields for collaboration.