What to Consider Before Making Your CMS Composable

So, you’ve decided to go composable to obtain more control over your website tech stack, gain higher performance, lower maintenance costs, and stop yourself from being held hostage by your tech vendors. Before you start the migration over to a headless content management system (CMS) though, you need to make sure you're prepared. We can help you get there by exploring the things you should consider before making your website composable.

Higher Performance

Site and page speed are critical components of user experience. Fast sites are more efficient so they're linked to higher engagement and lower bounce rates.

With a composable site, you can gain speed by generating static pages on an edge network and moving personalization to high-performing API calls. This seems simple enough, but now you need to review each page and identify if it can be static. If the page can't be static, then you must determine what sections of it can be. This is like an exercise you may have performed for caching strategies. When your marketing team changes the content on a page, that page is eventually regenerated as a static page and published into your edge network.

Areas that can’t be static are backed by API calls and populated into the page's HTML via JavaScript. Remember, you must take advantage of your edge network as much as possible to achieve the desired performance. I advise you not to populate all content with API calls in the browser, especially if you have a large site. You may end up with large amounts of JavaScript to manage and download to a user’s browser and may tax the browser’s performance, especially if it's on a mobile phone.

Migration

Historically, when moving your site to a different CMS, you had to migrate the entire site or put a proxy in front of the old and new sites to create the illusion of a single site. Sometimes, companies wanted more value out of their CMS migration and introduced a redesign into the process. In that case, a full migration was your only option.

Now, you can realize value early and not introduce additional risk by redesigning and migrating together. You can break functionality into smaller parts when changing to a composable architecture and using a headless CMS. One possibility is to begin leveraging API calls from your vendors to deliver content and functionality. For example, Optimizely, a DXP vendor, provides experimentation, content recommendations, and content via API calls. These all can be used to populate areas within webpages.

Moving your content can be challenging, but it's an opportunity to clean up HTML and reinforce your branding and development standards, by limiting the CSS styling within your HTML. Doing this will significantly improve the speed at which your content can be migrated and tested.

Gotchas

There are some critical gotchas that will need additional thought when you switch to a headless CMS. If you go down the path of a single-page app (SPA) or close to it, you must pay close attention to the third-party software that uses JavaScript. For example, while you navigate a site or a page, events fire within your browser, allowing functionality to key off the interaction. However, there are times when those events don’t fire as expected. This can make it challenging for the development team and it's incredibly frustrating if critical functionality like your analytics doesn't work. But analytics aren’t the only functionality that can be disrupted when events don't fire as expected. Ad-blockers within a browser can pose challenges, and impact third-party tools like Google Tag Manager, Facebook events, and many more. The bottom line is that you must understand the events your vendors use in their JavaScript code and ensure they fire.

SEO

SEO doesn’t change for static pages. However, how developers implement SEO can change based on the programming frameworks you use. When dealing with dynamic content instead of a static page, you need to remember that even though search engines try to understand the changes that JavaScript makes to the page, they're not perfect. When you need SEO, you need to generate a static page and make changes to the DOM after it has been delivered. If SEO is a concern, your development team needs to make it a priority.

Team Considerations

A key leadership role for composable architecture will be your architect. The architect, or the combination of an architect and lead developer, is the gatekeeper who ensures code quality and that your code base doesn't constrain your business. If they do their job well, they'll understand your business strategy and vision and be influential in making that a reality with your website. Given the number of systems involved, the architect and supporting team members must evaluate several vendors and make their selection based on high standards around security, performance, SLAs, and the service's value.

Because a composable architecture is built from independent software units, your team must understand this approach. Otherwise, it can become the Wild West. This means technical discipline. For example, standard best practices for front-end development, API development, and DevOps are a requirement. Some best practices are based on the frameworks you use. Others will be long-standing development practices like source control management, naming conventions, architectural structure, and test coverage, to name a few.

Next, the technical team needs to understand the value that the previous CMS brought to the table for your marketers. The marketing team needs the ability to do their job, promote the brand, and bring in leads. The site is one of the tools that they use to accomplish that task.

Both your marketers and developers need the site to be a win.

Having numerous services means you must manage capacity closely — the capacity of your developers who understand those services. If someone is out on vacation, another team member needs to be able to provide expertise on that service. This gets taken for granted, but your legal team also must be able to review the contracts from multiple vendors that provide software as a service (SaaS) products.

Lastly, current JavaScript libraries are complex, with a steep learning curve. So, if your team members are new to this type of programming, you should allow time for them to get up to speed.

Continuing Your Composable Journey

Unlocking additional speed from your CMS using an architecture that provides more business options is enticing. But don’t approach CMS migration like you did with the traditional CMS. Take advantage of the flexibility you get from a headless CMS, but remember that moving to a composable architecture is a recommendation from your development team and, ultimately, a business decision that lets you go to market faster.

The key to success with a headless CMS is aligning your development changes with your business. Find out what should change and when, by asking, "Where are the business opportunities? What area on the site could be a proof of concept, or what current pain points will benefit the most from a composable architecture?" Use your business priorities to drive your project to completion. By doing this you'll capture small wins along the way, gain the necessary experience, and lower the risk of a more significant change to your website.

Combine this approach with good project and management practices, like ensuring the work is easily consumable and testable. When you can, avoid changes that add complexity to the migration project. The more complex, the less consumable and testable, which will challenge the quality and possibly the project. Finally, ensure you have the right team to make it a win-win for your marketers and developers.

Want more guidance on what to consider before making your CMS composable? Contact us. We can help you better understand the pros and cons, implement a headless CMS, and make the most of the opportunities it provides.