Headless got our heads turning.

A dev’s perspective on the benefits of Headless + Server Side Rendering, and why it will change the way we create front-end heavy websites.

At Have A Nice Day we build all sorts of web based products. Some are small, some are complex. Some focus on digital story telling, while others are built to work with complicated information systems. As a result our development team requires a certain degree of flexibility: projects can be front-end heavy, back-end heavy or heavy on both sides.
Whereas web developers used to be regarded as being able to code both the front- and back-end, the maturing of the web created an environment in which there is a preference for split development stacks. Both front-end and back-end stacks continue to innovate at a fast pace, albeit mostly on separate tracks. Recently though, the combination of two innovations grabbed our attention: Headless CMS/Back-end and Front-end Server Side Rendering.

Decoupled content with a Headless CMS

A Headless CMS is a Content Management System without an integrated front-end, but it serves the content through an API. This means that the front-end is decoupled from the back-end: the CMS only worries about the content, and not the way that the content is being displayed on the front-end. You can use the API that the CMS generates to create multiple front-ends, making it the perfect content system when you have multiple products that use the same content (e.g. a website, a smartphone app, a back-office etc.).

Front-end Rendering

With the CMS decoupled from the front-end, there is no need for back-end templating languages such as Twig (PHP) or Razor (C#) to create CMS templates anymore. We can now use front-end techniques to build the front-end and display the content that is provided by the API.

A depiction of the two flows: traditional CMS development vs. Headless CMS development.

However, only one problem remains: the content that is being provided by the API is rendered in the website using JavaScript. This is a problem because the content is therefore shown after the first meaningful paint. It is therefore probable that Google does not index the page as well as a CMS template would be indexed. Fortunately, a recent innovation found a solution to this problem, and its called: Server Side Rendering (SSR in short).

SSR uses a front-end based Node.js server to fetch the content that the API generates. It then renders HTML and sends this to the browser. This means that the HTML that the client receives already includes dynamic content, thereby fixing the indexing problem. With this technique we can now build SEO friendly websites, using a content-first content management system.

So, we now have a system that is more or less the same as we had before: we display HTML that can be edited by a client using a CMS. Why should I go through all the trouble of learning a new stack? The answer is that we can now use the benefits of a modern front-end javascript framework to create beautiful websites!

The benefits of using SSR

Now we have back-end and front-end split, we can use the benefits of a modern javascript framework. In the following section I will go through some of these benefits, and benefits of going Headless in general:

  1. Rapid development with Hot Reloading: We can now use hot reloading in our SSR projects. With hot reloading, only the component that you are working on refreshes when you change the code. You therefore don’t have to refresh the entire page, which is a lot faster and helps the devs getting into a productivity flow.
  2. Code splitting and Prefetching: SSR frameworks such as (Nuxt, or Gatsby) automatically code split the rendered response. This means that the front-end server only returns what is required to load the requested page, reducing the time to load that page. Interestingly, we can take this concept even further with Guess.JS. Guess uses your Google Analytics data and applies machine learning to predict the next page that the user will visit. Knowing this we can already prefetch the files for the next page. This means that the load time of the next page will be blazingly fast and ultimately provides a better user experience.
  3. Performant out of the box: SSR frameworks automatically build your project in an optimized way, meaning that you directly have a very performant website out of the box. Performance can be measured by for instance using the Google Lighthouse tool.
  4. Progressive Web App ready: Because of its modern infrastructure it’s super easy to make your SSR website a progressive web app. In short, a progressive web app is a website that can be installed on a smartphone. It thereby unlocks new possibilities (such as making photos, or using other hardware sensors). In addition, this app can even be used when the user does not have an internet connection.
  5. Future proof: Many believe that the future in web development lies in combining JavaScript and microservice API’s (a concept that is embodied as the so called JAM-stack). As a result websites would be more performant, more secure, easier to scale and offer a better development experience.
  6. An enhanced user experience: Another great side effect of using SSR is that the browser does not have to refresh when new content is requested. This means that we can now build smooth transitions between pages, which could potentially create a smoother user experience.
  7. Splitting the tracks: As stated earlier, web development has evolved into two separate tracks: front-end and back-end. By creating Headless websites, we remove the requirement of having ‘mixed code’ CMS template files. This means that we now allow both front- and back-end developer to create their own optimized environments to work in. Front-end devs can stick to purely front-end code, and back-enders can stick to purely back-end code. The API serves as a link between both worlds.

Drawbacks & when not to use SSR

Unfortunately, using SSR may also have some drawbacks. For instance, by decoupling the CMS we may lose some of the automation that is built into a CMS system. In addition using SSR in back-end heavy projects may instead increase the amount of work, as back-end developers would have to create custom API endpoints. Some drawbacks are:

  • Hosting: A SSR server is based on Node.js. Unfortunately a lot of shared hosting providers do not allow hosting of Node applications. This means that you may have to look for a different hosting party.
  • Managing two applications: Both the Headless CMS and the SSR node application have to be hosted. This means that you have to maintain two applications, instead of just the CMS system.
  • Losing advanced CMS tooling: Going Headless could mean that you loose some of the tooling that an advanced CMS offers. For instance, a CMS may have marketing automation tools built in that won’t work if the front-end is decoupled from the CMS.

For now we are interested in using SSR for more front-end oriented projects, such as digital story telling websites (where advanced CMS tooling is not a requirement). For these projects a Headless CMS would automatically generate an API that serves the content, which could actually lead to a reduction in back-end developer activities.

Want to get started with Headless/SSR?

Got excited to try out Headless/SSR? The first step is to pick the right Headless CMS. Nowadays you can pick between a Platform as a Service (PaaS) CMS, or a traditional CMS. If you’re interested in a PaaS CMS I would recommend Prismic, or Contentful. Most traditional CMS’s now offer a Headless edition. WordPress automatically generates an API right out of the box that can be used together with a SSR framework.
For the SSR framework I would advice you to pick the framework that is built with your favorite JavaScript framework. For Vue you could use Nuxt (which is my favorite), for React you can pick GatsbyJS, and for Angular you can pick Angular Universal.

Our next steps & final thoughts

Having investigated SSR, I believe that it will definitely change the way that we currently develop smaller projects, such as digital story telling projects, and perhaps even complex projects in the future. Our next steps are to compare Headless CMS systems and investigate whether they suit the requirements of our clients, investigate what the best hosting and deployment solution would be, and create our own SSR starter kit for new projects. In the coming months we will continue to write about our learnings.

Finally, How do you feel about coding projects with SSR instead of using a traditional CMS? Do you have experience coding and hosting a SSR project, or would you like to try it out? Please leave a comment to share your opinion!