Copy to clipboard
Twitter Facebook

When it comes to building websites, fast, speedy and overall performance is the way to go. While this might sound limiting, this couldn’t be further from the truth. With the right selection, we really can have the best of both worlds.

This is why we turn to the JAMstack method time and time again, but the choice of CMS is one of the most common issues we get asked about. Many people are only familiar with the big traditional options, such as WordPress or Bolt, and aren’t aware of the wider options that can better meet their JAMstack and website needs.

Since every site is different, we want to explain the most essential factors you need to consider because, if you know these, then choosing the right CMS becomes much, much easier!


What is JAMstack trying to achieve?

JAMstack - a combination of JavaScript, APIs and Markup - is a tech stack for web development that’s focused on improving overall performance. When we chose JAMstack development, we chose it because:

  • We know static websites load and perform faster.
  • We also know their better for SEO (which makes them great for e-commerce development, by the way).
  • We know they are more secure.
  • We want to update it automatically, such as via a content delivery network.
  • We want to give the frontend the freedom to what is needed for the end-user, rather than shackling them due to choices made in the backend (thus the markup and API approach).

You can think of JAMstack as a form of transformation. More than just choosing only the most web-friendly technologies, we’re breaking up monolithic approaches that forced us to compromise in vital areas.

Which leads us to our choice of content management system…


How does a CMS influence your JAMstack website?

In any website, we need a way to upload content to the frontend. Content Management Systems have filled this need perfectly, giving companies a means to draft, edit, preview and ultimately push content to the website. However, each CMS offers something different and, when it comes to JAMstack development, we need something that works with what we said earlier:

  • It needs to be fast
  • It needs to work with JavaScript and Markup (such as HTML)
  • It needs to push content via API
  • It needs an automated way to update content
  • It needs to keep the website light and performance - (java-heavy elements are out)
  • It needs to keep us free to develop the frontend as needed.

With that in mind, let’s look at the world’s most popular CMS: WordPress. The main problem with WordPress is that it’s the complete package. We are forced to choose templates that fit WordPress, rather than adapting to the website’s needs first. As a result, WordPress sites are far from the fastest and, while they do use Markup, they also run on PHP rather than JavaScript.

We can do better - which is why it helps to know what you want from a CMS.


Hosting

Depending on your website’s setup, you might need to find a hosting solution for your CMS. After all, while it doesn’t need to handle the traffic peaks of the website itself, it does need to be accessible for both your content teams.

Also, given that JAMstack development favours delivery networks that send files over for fast, automatic updates, you need stable hosting that ensures such requests can be made quickly.

Some CMS come with their own hosting options, others do not - especially the open-source or free options.


API Support

The use of API is an essential factor in JAMstack. We want to call only the files that are needed via API to remove much of the strain on the HTML side (an area where loading starts to slow down).

WordPress, for example, isn’t very API friendly because it’s shackled with its own frontend templates. Instead, as far as JAMstack development is concerned, we should look at decoupled or headless options - any solution where we can better control the requests between the backend and frontend.

Generally, we should be happy with API options, but we can also consider Git-based solutions as well. Git is more developer-friendly. It allows for rollbacks and can still enable automatic updates.

However, it also means we’re only pulling from Git, rather than multiple sources, which API leaves us open to do. Consider your specific needs carefully.


JavaScript Support

Nearly every CMS supports JavaScript - it’s hard to be web-friendly at all without it - so this might seem like a foregone conclusion. However, we need to assess the wider JavaScript needs.

Does your website, for example, rely on React for the frontend? If so, many CMS’s use React and other libraries, such as Next.js, to deliver fast results - but some don’t.


Integrations & Compatibility

Like any technology, you need to consider how it interacts with the other options you are making. With JAMstack, we have some technologies already chosen, but every CMS will work with these web essentials. It’s the additional elements that you need to consider.

If you’re using the likes of React and other frameworks based on it, it’s important to choose a CMS that’s either built to work with React in mind. Similarly, if you’re using any other advanced integrations, such as Magento or Shopify for e-commerce, this needs to be considered. Different CMS are built with different integrations in mind and we certainly don’t believe there’s a golden CMS that’s perfect with everything.


Database Functionality

For the sake of a fast website, you need to consider where you want this content to be accessed and pulled from.

If possible, it’s ideal to have the CMS to act as the database, storing all the content and information we need in one accessible repository. Most do this, but some actually sit a little ‘higher’ on the backend and only edit live versions of the website - which means they must be stored elsewhere first.


Users and Roles

This might seem simple but it’s important. While JAMstack is well known for its scalability, we also need a CMS that does the same. Yet most CMS come in the form of subscription packages - and therein lies the problem.

A package that gives us limited user accounts - or even role management - bottlenecks the overall productivity. A team of 5 people can likely use any such CMS as needed but, what happens when you need 20-30 people with different levels of access? You might need to upgrade your CMS package, drastically denting the existing budget.


User Friendliness

At the end of the day, a CMS needs to be used by content specialists. As such, the UI and UX are also essential. For many, WordPress set the industry standard for UI - for good and bad.

Some CMS try to be the perfect WordPress alternative by copying it exactly. This means that it is very intuitive to people moving from WordPress, but that means it brings all the larger navigation issues, too. Others are more simplistic and offer a system where everything is only a few clicks away (as long as this simply isn’t because of a lack of features).

Usability is essential and this is one area where a simple trial run may be the easiest option if you have the luxury of time (or a test server).


Headless or Not?

Finally, there’s one option that’s relatively easy to decide. If you’re obeying the JAMstack principle, you need a headless CMS.

That’s because traditional systems, like WordPress, have a combined frontend that renders complex pages that slow down performance. Headless CMS keeps the content management strictly to the backend and there are a number of such WordPress alternatives to choose from, which we’ve already covered.


Choosing Your CMS

There’s no one right answer - if there was, this post would have only been a couple of words long. Instead, you need to choose the right CMS for your website’s specific goals and needs. This includes:

  • Does your chosen CMS come with its own hosting solutions?
  • Does it support API?
  • Does it support JavaScript?
  • What integrations & technology compatibilities do you need?
  • Do you need the CMS to operate as a database?
  • What users and roles are needed?
  • Is the overall UI friendly for the content team that will be using it?
  • …and do you want a headless CMS? (Yes!)

We hope that helps but, of course, we can always answer any questions you might have!