To use headless or not, that is the question

Noone can have missed the headless wave going through the web developer community lately. Episerver supports building a headless solution very well with the content delivery api that was added from v11.4. I have personally used it a lot to build SPA (single page application) solutions on top of Episerver using both vue, react and angular and it works great. The latter versions of Episerver also makes it possible to build support for editors too. But what is really the pros and cons with headless? When should you use it and when should you stay away from it?

Pros:

• Easier to implement complex user experience parts with lots of interactions
• Frontend developers get more power and can more easily implement a feature without help

Cons:

• Performance can be tricky to achieve for first page load especially on large enterprise sites, which hurt conversion rate and SEO
• Editor capabilities are limited. It's trickier to support more advanced scenarios like A/B testing, previewing, blocks etc
• Routing and SEO. For a full SPA that also takes care of routing, SEO and deeplinking is more difficult
• Implementing standard functionality that is powered by content made by editors takes longer time with headless than traditional architecture
• Increases complexity of overall solution if used too much
• Javascript frameworks have a best-before date similar to milk
• Can easiliy grow to become a difficult-to-manage monolithic solution which may become difficult to replace in a few years
• Backend developers get less power and will have more difficulty to implement a feature without help

Headless + powerful javascript framework X is great for user interaction-heavy parts of the site

To summarize, headless CMS combined with a rich Javascript framework like react, angular or vue is a great tool to solve a specific problem. Pages or parts of your website that has a lot of user interaction benefit from using a headless approach with a more powerful javascript framework. It can be complex forms, graphs or specific tools (think gmail, google maps, power BI, advanced checkout in an e-commerce and similar views). Be aware of the potential downside of initial load speed can have on conversion rate (especially on mobile) and SEO though. A page that loads in 4.2s will have approximately half the conversion rate that one that loads in 2.4s. Read more here.

Traditional site without heavy javascript framework is best for content-heavy site

For strict content heavy parts headless is not the best match. If your focus is content, rather than fancy user interaction, your site benefit more from a traditional architecture without the headache from headless and heavy javascript and focus more on Episerver pages and blocks powered by standard html, css and backend to give the editors maximum power. To the end user you will be able to get the absolute best performance and load times especially on mobile devices. SEO, A/B testing and a rich experience for editors to experiment with content is very easy to support. Add a content delivery network, (CDN) on top of that will give you the best performance anywhere around the globe. 

Summary

Architecture and design patterns like headless are tools to solve a problem. If you don't have the problem, don't apply the solution.

If you have a part of the site that is focused on content and a part of the site focused on user interaction, use both headless and traditional backend architecture, but avoid mixing them, to get maximum benefits for both users and developers. 

Happy coding!