Today I learned that a website using Drupal as a CMS is almost twice as likely to have a good web vitals score than one using the most popular headless systems like Contentful or Sanity1.
First off, let me break that down for the less technically inclined. Core Web Vitals2 are a set of measurement tools from Google that quantify the speed and performance of a website. It's important stuff because website performance is tied to user experience, engagement, search rankings, and most importantly conversion rates which directly translate to $$$ in e-commerce. A headless content management system3 is a sofware system that only handles the content and decouples the content from the presentation4.
I was researching this before I found this nugget because I was recently handed a proposal from another company to evaluate which involved a headless content management system. The proposal was chocked full of various buzzwords related to headless. I also played a tennis tournament a couple weekends where one of my opponents was an alumni of my program in college and had just sold his headless content management system for what appeared to be a pretty penny based on his living situation. It got me to thinking again about being on the bleeding edge and getting involved with something new even though talented Drupal developers are harder to find than React developers these days.
As is usually the case, this post is just me talking it out... or just ranting about the buzzwords in the aforementioned proposal.
Background
I've been considering focusing my future work more on entirely Javascript powered frameworks( Remix/Svelte & Supabase/Postgres ). Perhaps this is mostly because of my recent experimenting with vector functionality in Postgres. Luckily, the monolithic frameworks have all embraced Javascript front-ends ( Ruby/Ember, Laravel/Livewire ) so I've been able to blend the two. I've admin'd several headless content management systems for about 5+ years and have had headed various versions running 15+ years. I remember when Node.js first came onto the scene and the JAM and MEAN stacks were buzzwords. Although I know that the fundamentals ( JavaScript/HTML/CSS ) are key , I've learned enough now to know the devil is in the details... efficacy is a matter of usefulness and sustainability is a matter of practice. I think the popularity of headless started in an attempt to have content available as a asynchronous data source for mobile apps and has since evolved into having other advantages and disadvantages.
Advantages
Security, performance, and flexibility are generally the three most cited reasons to move to a headless. Although they provide a much more reduced surface of attack given that the extra distance to the programming language and database, it just means that the security needs to focus on authenticating users at the API level. Although cited as producing a more fault tolerant environment, I've found that debugging various microservices and API's to be as difficult, if not more than a monolithic infrastructure just like debugging Javascript frameworks. As for performance, I think the web vitals report speaks for itself even though it's a bit more complex. Just because you're using server side rendering of static generated pages on an edge network provider doesn't necessarily mean that your SSL connection times, file optimizations, or offsite resource loading is good. Flexibility is the one benefit that is relies highly on the use case particularly if your site needs to consume/feed data or be concurrent.
The one area that the web has vastly improved upon is asynchronous features. Facebook and React were way out in the lead on this because they realized that their engagement rates were closely related to real time data. Although they still use PHP and Python, a large chuck has been converted to Rust because it runs faster like C++ on the server without the security holes. If you look at companies like Facebook, Starbucks, and Walmart you'll find that they rely heavily on these types of asynchronous features and a service oriented architecture because the bumps in performance and personalization equal big money. They generally use a React front end coupled with an assortment of services piped in and out via API5. Amazon is kinda a different animal all together because they run their own infrastructure and often the other companies to boot.
Having multiple components has it's advantages. A huge standout to going headless is for a mobile app. I'd argue that it's the largest driving factor behind the rise of headless cms' and frameworks like Facebook's React and React Native. It's also the reason I joined the W3C working group on web apps even though I rarely participate. Having a universal codebase of a site and mobile app means iterations and changes move faster. Scaling can be done only on the components that need it while code complexity can be isolated. Delivery can be isolated from security and systems administration.
Another advantage is the ability to leverage various SaaS third party components against your site. The buzzword around this is MACH architecture6 which stands for Microservices, API-First, Cloud-Native, Headless. Proponents cite it's advantages as being future-proof, flexible, scalable, composable, with a quicker time to market. Examples include software or services already in use or ones that are too complex to build and manage on site. These may include accounting, artificial intelligence, search as service, customer personalization, inventory, shipping, language translation, behavior tracking, and analytics. It gives the company the ability to focus exclusively on their core operations without having to dedicate an entire floor to developers. The average mid-sized outfit won't hire the staff or contractors to handle this type of infrastructure so they rely on third parties. However, the overwhelming majority of retailers have fewer than 50 employees and a decent consultant or developer will point them in the direction of decoupled services to give them access to the same tools. There are plenty of small businesses on the same Shopify platform as billion dollar companies.
Disadvantages
Service oriented architectures can be a drag and I recently wrote up a post about the monolithic architecture at Stack Overflow7. I've often quipped about the reliance on third party microservices8 and sigh everytime I have a request to debug one because it inevitably means reading their documentation. We used to have tightly coupled frameworks like those in Rails or Django and we've now losing them to API-powered SPAs. Some of the APIs are still powered by frameworks. The fact of the matter is that a lot of the Saas companies are still using a monolithic infrastructure to power these same APIs. Shopify uses Rails. A lot of folks are creating a new buzzword around Local-First9,10, which is re-coupling the application stack creating faster read/write times and simplified state management. Up until now, developers have been building a bunch of custom sync tools to try and deal with the APIs.
Headless as an acronym for microservices or APIs, just means that your content ( media, data, etc ) is elsewhere on the network. Most of the newfangled CMS systems won't tell you that place is actually just Amazon Web Services. Some of the newer offline capable software like Figma or Dropbox offer desktop software that is just essentially repackaged web browsers to seem local. Having more components to system just introduces additional points of failure.
The cost of service as software is why Why Software is Eating the World11 became a thing. By the time you wrangle up four or five various digital services, you're now the middleman. Decoupling services means you have to maintain multiple systems and it will cost manhours to do so. And unless you've got the team and manhours to dedicate to building out some rather complex systems, you're going to be missing out on a lot of features. Another hidden cost of the lack of ownership is access to your data. Although there has been a good bit written about privacy, I mostly referring to the fact that if your product sells well on Amazon, there will be a competing product in exact t minus 0 hours. It's also the reason that every innovative company is spending time on the other side of a regulatory body at some point defending their overarching reach.
Conclusion
Size is at the core of speed. Going headless won't necessarily solve this for you. I spent a good chuck of time yesterday afternoon reformatting some of the markdown in this site because there were breaking changes in the software that interprets it. As much as I like simplicity, it's littered with MDX and JSX syntax. I also recently had an issue where an app I built to consume an external API were kicking errors only to find out the errors were on the user end having to maintain two systems concurrently. Going headless has nothing to do with solving issues like these and more to do with buzzwords floating around the vendor tables at your next conference.
My real world experience has also taught me that no matter how simple you try make the features, users will find a way around it. Even if your headless site is completely decoupled, there may be instances where an end user wants to edit part of the design. I sometimes try to configure templates in such a way so that you don't lose the design to the editors. Likewise with data, I'll build and configure a feature to edit whatever data field and the users will decide to put something else there. I've also learned that no matter whatever sophisticated real-time collaboration tool a company is using for productivity or to communicate, folks will send email attachments with screenshots. The best way to weave a digital system into a company is by using their existing workflow and trying to make it better.
What used to be called a website is now called a digital customer experience platform and an advertising agency is now called a digital solutions transformation consultancy. Personally, I prefer simple but I also like to tinker with all the bells and whistles. I know that simple is more sustainable and I'll always lean toward it while recommending on a case by case basis. For now, I'm just happy I know some of the fundamentals to sift through the shite. There's some part of me that really admires the aesthetics of high value really simple software. If I started a new web project this afternoon, headless or not would likely be whatever is in my wheel house and instead of spending the time here ranting, I could be expanding my strike zone.12,13,14,15,16
- Core Web Vitals Technology Report - https://lookerstudio.google.com/reporting/55bc8fad
- Core Web Vitals - https://web.dev/articles/vitals
- Headless content management system - https://en.wikipedia.org/wiki/Headless_content_management_system
- Frontend and backend - https://en.wikipedia.org/wiki/Frontend_and_backend
- Transforming the Checkout Experience - Formidable Labs - https://formidable.com/work/walmart/
- MACH Architecture Alliance - https://machalliance.org
- Monolithic Infrastructure - https://davidawindham.com/til/posts/monolithic-infrastructure
- Microservices - https://en.wikipedia.org/wiki/Microservices
- Local-first software - https://www.inkandswitch.com/local-first/
- Some notes on Local-First Development - https://bricolage.io/some-notes-on-local-first-development/
- Why Software is Eating the World - https://a16z.com/why-software-is-eating-the-world/
- End-to-end typesafe APIs - Typescript - https://github.com/trpc/trpc
- Build reactive, realtime, local-first apps directly on Postgres - Postgres/Elixir - https://github.com/electric-sql/electric
- Automerge - Typescript - https://github.com/automerge/automerge-repo
- Payload CMS - Typescript - https://github.com/payloadcms/payload
- Directus - Typescript - https://github.com/directus/directus