WordPress vs Contentful for Building Websites – A Frontender’s Perspective

But of course it is not entirely fair to compare those two together, since under the hood they are entirely different. To make the decision for which CMS to use I think this is really important to understand. So let’s dive into this a little bit more.

1. Contentful is headless

   Contentful is a headless CMS that can easily run on a cloud and mostly enables one thing: Retrieve Data, efficiently and quickly. It is up to the developer to create a beautiful website and there are limitless options to go. In my recent project I was using GatsbyJS to create a website with Contentful data.

2. WYSIWYG is technically impossible in Contentful

   Obviously demanding any form of WYSIWYG from Contentful is impossible, since it has literally zero overlap with the actual representation of the data. There is not a single line of CSS that Contentful has to deal with. If you want to put it cynically Contentful is just a huge google-docs table somewhere in the cloud.

3. Contentful is not just for websites:

   Contentful can be a backend to anything from a website, app or a toaster, it does not assume that the data will be presented in any specific way, which makes it very versatile at the expense of being user-friendly when it comes to a specific use-case (like building a website). Again cynically Contentful is like a really snazzy knife, good for a lot of things, but not necessarily a superb screw-driver.

4. WordPress is mostly for websites:

   WordPress on the other hand is a PHP backend that handles everything about a *website*. It comes pre-organized in pages, posts, it assumes you will have a navigation and that each website has its own url, users, with roles etc. That can be overwhelming at first, but essentially you end up using almost every single aspect of it when building an actual website. So WordPress is specialised for a website. (Even though it is technically totally possible to use WordPress as a headless CMS and pull content to display on the said Alexa-enabled toaster).

5. WordPress runs on your server

   WordPress renders (in the most common configuration) all of your content on the server, that has access to all the data, as well a any global configurations – ergo the way the content is displayed and the data live in the same space, which makes for a far superiors WYSIWYG experience. Contentful on the other hand leaves the rendering entirely to the frontend, which is a more modern solution, since we have so many different media devices these days.

6. Built on entities

   Both platforms share a similar approach that data is stored inside some form of Entity: A PostTypes (WordPress) or ContentTypes (Contentful) that have a set of configurable fields like texts, images and so on. Each Entity becomes a Page or Form or some modular component. As opposed to WordPress however Contentful does not support global/option settings like WordPress does. (This can be remedied by ContentType “Option” fairly easily though).

• PostTypes/ContentTypes

  Creating PostTypes (WordPress) in Contentful is a breeze. The CMS is made for really quickly clicking those things together and is very much reminiscent of the AdvancedCustomFields Plugin in WordPress, that feels much more natural to use.

• Image Handling

  Contentful comes with a marvellous Image handling. Instead of defining sizes like in WordPress and then picking the right ones for the right occasion in Contentful you simply upload a file and request it in any size necessary, it will be cropped, resized, compressed and cached just as you need it to. No more Minifier plugins, no more 15 versions of each image in the uploads folder and god forbid changing the size definitions mid-way in WordPress!

• Localisation

  Localisation is supported right out of the box and as you define your ContentTypes in Contentful you can decide wether you want to localise a specific field or not. If you choose to, you will have a duplicate for the localised field for each of the languages. There is an automatic fallback to your default language. No need to deal with any plugins for that.

• GraphQL

  The Contentful API supports GraphQL. Although when building WordPress sites you usually won’t need fancy queries, remember that Contentful is headless, that is everything has to be imported through an API that retrieves data in some JSON format. Using a REST API gets very messy quickly since you have to fire multiple calls to get your data. GraphQL is readable, easily testable and completely abstracts the developer from dealing with any calls – just tell what data you need and you shall be given! Using TypeScript in conjunction with the GraphQL queries even allows for code completion and a much saner and joyful developer experience.

• Snappy, Concise UI

  The Contentful Web UI is a react web application, so it is really really fast and a pleasure to work with. It is not burdened by plugins, options etc. WordPress with its PHP backend is clearly no match when it comes to snappiness or the emotional disposition of an impatient person.

• Scalability

  Big websites require lots of resources to run smoothly and that is where WordPress has a harder time keeping up, since in its basic form it is limited to a mysql database and a single server. Contentful in this instance has no inherent limitation since it is cloud based and can scale up dynamically as needed. You can entirely focus on your frontend performance which makes might save some headache on the backend.

• Security

  Since there are no plugins, no backend customisation and nothing to hack into, contentful is not as prone to malicious code that gets snuck in through a form or a plugin – you basically don’t have to worry so much about your servers being compromised and start sending out spam emails. It is rare on WordPress with Wordfence but in my career I had this happen too, so definitely a big pro for Contentful.

As you can see almost all the points here make a non-tech-savvy crowd look somewhat puzzled. Contentful is made with developers in mind, WordPress on the other hand has a much broader audience. So there is no surprise here, that most of the Cons will be exactly about this aspect:

• Overview

  Contentful has basically 2 main views. One that defines the content types and one that defines the content. Both of which are a huge and at some point painfully long lists. No hierarchy, no conditional rendering, no grouping. So if you have 20 blogposts with 35 different galleries embedded in them, you will end up with a list of 55 entries (yes you can filter an all this, but honestly this doesn’t help that much). What you would want is for example to display each gallery under the post where it is used. You can’t do this in Contentful. The only workaround is to stick to a naming convention like [PostName] – [GalleryName] and sort your galleries alphabetically.

• ContentTypes

  Contentypes are very easy to click together and if you have a ContentType that defines a page on your website, you might very quickly end up adding dozens of different fields to it (like section titles, images, texts etc), if you have any localisation you will end up with that many fields times the number of languages. Also each field takes up a row in this form and you end up with a very long list of fields. In WordPress + ACF you can alleviate this by using tabs for fields that belong to certain sections, WPML splits the content for each language into a separate post. And not to mention ACF offers the possibility to conditionally show or hide certain fields when an option is selected. The Contentful Web-App loves flat lists above all else, which is a pity for website-content.

• Lack of Blocks or Repeater fields

  This is an issue that the Contentful community has been complaining about for years. Let’s say you want to render a table with more or less rows. Obviously each row will only be used in this table and probably only once. In WordPress + ACF you can make use of repeater fields (or blocks if using the WP block editor) to quickly create a thing like a table, plus and minus buttons and so on. It is clear and concise. In Contentful on the other hand you will end up creating a post-type for the table and a post type for each row-entry. Which ends up cluttering the UI unnecessary, lacks any preview and counts towards your limit of some 50 contentypes that you may define in the non-enterprise package.

  You can use the rich text editor in Contentful to create a something that is reminiscent of the ACF Flexible field though, which offers some consolation – but again your options for somehow previewing the content are very limited. (In conjunction with Gatsby or NextJS that do server side-rendering you end up running a build every time you want to preview things. Oh the patience it demands! )

• Lack of Media Library

  Coming from WordPress the Contentful MediaLibrary feels marginally better than a comandline representation that you would get when typing “ls” into your console inside a folder containing images. It has absolutely tiny thumbnails (30px height) and no possibility to upload more than one asset at a time. A problem I ran into a lot is replacing an image, a good discipline with naming your files is absolutely necessary if you want to keep your sanity here.

• Navigation

  WordPress offers the possibility to define menus and handle URLs quite easily and for about 80% of the websites you don’t need to customise much here – The handling is easily replicated in your workflow. In Contentful you have to take care of the urls your pages will have yourself. Making Menus in Contentful boils down to define a contentype and explicitly stating what can go in there. It gets a little bit more complicated with hierarchical menus. It is possible, but you will end up tinkering with it for quite a while before getting it right.

  The biggest burden in my development was to create url-structures like “product/category/productname” Since you have to define these 3 slugs in 3 different locations in contentful (product on shop-page, category on category page, and productname on the actual product page), then assemble those links in your frontend correctly and then also honouring these assembled urls in your menus, richt-text-links etc. Obviously all of that is not very relevant in an app-environment, for a website, you will have to deal with it

• Lack of backend Customisation

  Contentful lets you do some basic validation field-validation, like that a text-field is not empty or only contains a certain values, but nothing beyond this and nothing customised.  Well why do I need it you say?

  One such example would be URLs for pages. Certainly you can’t have 2 pages having the same URL. WordPress would handle this particular example out of the box, but any other validation can be easily done by hooking into the post update mechanism to run any kind of checks having access to the whole database. Another example I run into frequently are forms that send out emails to the user and the admin. You would want to make sure that all the data is sent out and that your email template does not contain placeholders that can’t be filled, because they have no corresponding field.

  Unfortunately there is no way to add any backend customization in Contentful and no way to help the user, by adding custom error messages and sanity checks beyond the basics, like non-empty fields, or fields with certain values.

• Cost

  Contentful is not cheap, if you are not working with corporate budgets. Going into business will cost you a solid 500$ a month. Unless you know that you will need the power, reliability and scalability that comes with Contentful and understand all the implications, the budget is quite substantial.

  On the bight side: There is a community version available for free which is more than enough for
  non-commercial, personal or philanthropic projects. It is a great way to tinker with the way CF works.

• No local development

  Unfortunately you can’t use MAMP or XAMPP to just run a local Contentful repo and will always need an internet connection to develop. Server Side rendering libraries offer caching capabilities, that alleviate this, but you still would not be able to create new content, unless you do it online.

Overall I think it is clear that Contentful is not the greatest backend for curating content for a website, even though with some discipline you can make it work for you quite well and benefit of its speed, scalability and the wonderful image-handling.

With a little bit of more work on the Contentful Web-app itself, the CMS would become so much more powerful and usable for website builders like me – at the time of writing though I think it is not a straight-forward choice. Let’s hope that there might be an “ACF” for Contentful type of revolution ? .

The comparison here is clearly strung on one dimension that spans between the two extremes “Database” on the one end and “WYSIWYG” on the other. The former excels at performance and querying, the latter gives broader possibilities for editors and content creators to create unique content, which is one of the most important parts for maintaining a dynamic website.
So if you are making a website that will need a lot of dynamic customisation, many media files and so on Templates and Blocks in WordPress will be a better solution. If you need a largely scalable, fast content repository and are willing have the discipline to adhere to some naming conventions in order to make things more clear, use Contentful.
Personally I enjoyed working with Contentful for it’s clean and super fast backend but when editors started demanding more dynamic options things got cumbersome and tedious to implement and explain.

Check out my Ten Tips to stay content with contentful if you decide to go with it.