Getting to Know Sitecore XM Cloud Development: Part Two

In our experience helping numerous Rightpoint clients architect their Sitecore XM Cloud projects, we’ve seen firsthand how to choose among XM Cloud’s many features to create a custom CMS that meets your team’s performance requirements.

In Part One of this series, we discussed setting your project up for success by choosing the right local development approach, scaffolding, and sprint 0 essentials. Now, we’ll dig into best practices for other elements of Headless development with XM Cloud.

Focus on Front-End UI Options

Organizations with a packaged design system of front-end UI elements may have a head start—provided the system is editable within XM Cloud and consumable by the head application. It may be possible to modernize an existing design system defining types for or exposing each property that’s editable from the CMS as a 'ReactElement' for the head application to consume.

For teams starting from scratch, we recommend using an open-source, flexible headless UI library. As with any project, decisions about which UI library to use require careful consideration. For full starting control over styling, our go-to recommendation is Radix Primitives. For a proof of concept (POC), or if your design team can work within the system you’re going to build, we typically recommend Material UI, Tailwind, or ShadCN.

Choosing a design system is just as important from a developer's perspective. The focus should be on readability rather than trying to squeeze out minor performance improvements at the expense of clarity. Given the need for customizations, it can be very tempting to allow any value of 'className' from the outside. Set boundaries through styling variants, letting developers choose the look and feel of an atomic part of the component, so that maintaining style is structured. The cleanest code isn’t optimized to be written, instead it’s optimized to be read.

Optimize for Performance

As you build, closely monitor your application’s web vitals within your CI/CD process or a hosting platform like Vercel or Netlify. Incorporate React and Next.js performance optimizations such as:

• React memoization to cache key results of expensive calculations and event handlers, minimizing re-rendering calculations.

• React Suspense to show component UI skeletons for any long-running blocking requests during the page load cycle. This allows parallel loading of the rest of the page, improving the Cumulative Layout Shift score.

• `Next/image` for image sources, to improve Largest Contentful Paint scores for above-the-fold componentry with images. Set the attributes as 'priority={true}' and 'fetchPriority="high"' to prioritize those images during the page load cycle.

State management

We recommend keeping the state as close to the component as possible and avoiding unnecessary component re-renders, especially when sharing across multiple components, such as an add-to-cart button within a product detail page. Dividing components into atoms makes re-renders easier to detect and limits state management request lifecycle rehydration to atoms instead of the full page, making it easier to detect and debug performance complications.

Client-side data fetching

The React hook library SWR is our standard recommendation for data fetching. SWR encapsulates fetch calls, handles caching and revalidation, and even fetches on intervals. If your application requires mutating data (CRUD operations), a jump to TanStack Query for built-in mutation support is ideal.

Static Site Generation with Revalidation

By default, Sitecore SSG/ISR rendering hosts have a static revalidation interval of 5 seconds. The revalidation interval is configurable via the revalidate property in the getStaticProps function, which determines how often the static cache is refreshed. The 5 seconds interval can be excessive in most cases. If you choose static site generation over server side in XM Cloud, we recommend architecting Sitecore pages to include a customizable revalidation interval field. This lets you tailor revalidation times so that high-priority pages can revalidate every few seconds, while those with less dynamic content can revalidate as infrequently as every 24-48 hours.

Planning External Data Integrations

The key question for your XM Cloud third-party data integration strategy is, “How frequently will the data change?” Frequency options include:

• Real-time, using SSR or component-level data fetching to ensure that every page load has up-to-date data.

• Interval, leveraging an ISR strategy to regenerate static pages every 24 hours.

• When data changes, using the next.js revalidation route signaled through 3rd party webhooks.

In all these scenarios, efficient API usage depends on latency, rate limiting and error handling by caching layers at the application and/or the edge.

• For SSR-rendered pages, cache the fully rendered HTML page at the edge and invalidate the cache when the underlying data changes.

• For component-level fetching or page-level SSG, leverage the Vercel data cache with a time-based revalidation.

XM Cloud DevOps Optimizations

To control which serialization modules are deployed as Item as Resource (IAR) files and to automatically publish to your DEV sandbox, we recommend setting up an 'xmcloud.build.json' file for each environment. Within the DEV sandbox web.config file, you can turn off 'CustomErrors' in the 'transforms' section for easier authoring debugging.

Effective Authoring Strategies

If you’re using Sitecore Experience Accelerator (SXA) to build multiple sites, custom scaffolding modules can speed up the process. Start by defining the types of sites the team needs to build—such as campaign, blog, and product—and then create a shared SXA site to centrally manage data sources, page designs, and other configurations.

Next create custom SXA scaffolding modules, through Sitecore PowerShell scripts, for each site type to run during and after the site-wizard creation. This scaffolding will generate preview-able sites with the appropriate settings, sample pages, and starter content.

Composable Requirements

Identifying your composable landscape needs in advance is crucial to your project's success. One key composable area is search experience. Although XM Clouds Graph QL search queries can handle pagination through beginning and end cursors, there are some limitations to how content can be queried and how often content snapshots are updated from the edge.

To build a better search experience, look at the composable headless search landscape and find a "Search As A Service" platform that fits your requirements. Two options we recommend are:

• Sitecore Search, a straightforward search platform from Sitecore, with typical search service features, that works well with Sitecore CDP to provide seamless streaming of search analytics.

• Coveo, a third-party search solution that stands out for its search features and flexibility in implementation.

To manage your digital assets from an end-to-end content lifecycle, look no further than Sitecore Content Hub DAM. With built a built-in integration to XM Cloud, Content Hub DAM is an excellent choice for asset management and helps in improving site performance through it’s asset transformation ability and CDN.

Build the CMS You Want with Sitecore XM Cloud

Successful XM Cloud development starts with strategic preparation, access to resources, and adoption of best practices. Working with an experienced XM Cloud development partner can optimize your CMS project and accelerate its delivery.

As a Sitecore Platinum Partner, Rightpoint has assisted clients in multiple industries on hundreds of digital experience delivery projects. To learn more about working with Sitecore XM Cloud or with Rightpoint, reach out to our experts.