I recently worked on a project where significant effort was spent optimizing the publishing experience for content authors using Sitecore XM Cloud. During this work, we explored different publishing mechanisms, architectural considerations, and performance tuning techniques.
I have summarized some of the key concepts below so that you can find most of the essential information related to XM Cloud publishing in one place.
Publishing in Page Builder
By default, when a page is published using Page Builder, the system performs publishing in Smart mode with related items. After a page is published, Page Builder retrieves the context item and sets it as the root item for the publishing operation.
Page Builder then identifies all the associated data source items that should also be included in the publishing process. These data source items are fetched from the layout JSON data of the current page (specifically the layout { rendered } result if queried through the GraphQL endpoint).
All discovered data source items are then included as additional root items. The Page Builder sets the rootitem and rootitems parameters in the GraphQL query and sends the request to the CM service, which performs the publishing operation for all identified items.
If the content architecture is not carefully designed, this behavior can result in a large number of items being published unintentionally.
Edge Runtime Publishing (V2) vs Snapshot Publishing (V1)
In one project, we had two XM Cloud instances running in production, each using a different publishing model depending on the content architecture and delivery needs.
In the first instance, we used Publishing V1 (Snapshot Publishing). This worked well because most of the content came directly from the page item itself, with very little reliance on external data sources. The content tree was simple and publishing activity during business hours was minimal. The main priority for this environment was faster initial page delivery.
In the second instance, we used Publishing V2 (Edge Runtime Publishing). In this setup, pages were composed using multiple components that pulled data from both global and local data sources. In this case, improving the publishing experience for content authors was more important than optimizing the initial delivery time.
It is important to note that V2 is not necessarily better than V1. The best choice depends on your content architecture, dependency structure, and publishing requirements.
High-Level Comparison
• Publishing V2 (Edge Runtime Publishing): This approach is more granular and lightweight. Smaller JSON fragments are stored on the edge, which results in faster publishing times. The edge stores the main layout structure while referencing data sources separately. The final layout is assembled dynamically at Experience Edge during delivery requests.
• Because the layout is assembled on demand, the first request for a page may take slightly longer. Static Site Generation builds can also take longer because the initial request cost is higher and caching is less predictable.
• Publishing V1 (Snapshot Publishing): This model is closer to traditional Sitecore XP publishing. A complete snapshot of the page content and its dependencies is published to Experience Edge, and the layout is assembled during publishing.
• Publishing a single item may trigger a cascade of related item publishing, which can impact performance in large content trees. However, this model provides faster initial page delivery since the layout is already fully assembled.
Settings That Improved Publishing Performance
In our case, the content tree contained more than 200,000 items and had a fairly complex structure. Sitecore support recommended several configuration adjustments that could be applied through a patch file to improve publishing performance.
One key change involved reducing the serializationMaxDepth setting from 4 to 3 because none of our GraphQL queries required a depth of four levels.
• ExperienceEdge.IncludeDependencyAncestors set to false
• Publishing.DeepScanRelatedItems set to false
• serializationMaxDepth under Layout Service set to 3
Vercel’s Role
Our front-end application used Incremental Static Regeneration (ISR) on Vercel. Initially, the ISR timeout was configured to 15 minutes, but we later reduced it to 10 minutes to achieve a better balance between cost and content freshness.
This configuration means Vercel checks every 10 minutes to determine whether a new version of the page is available. If a content author publishes changes five minutes earlier, those updates will not appear immediately until the next regeneration cycle.
Setting the timeout too low—for example, every 60 seconds—would significantly increase the number of regeneration checks, which could lead to rate limits, performance concerns, and increased infrastructure costs. Therefore, finding the right balance between content freshness and operational cost requires collaboration between architects and business stakeholders.
Final Thoughts
Optimizing the publishing experience in XM Cloud requires a careful balance between content architecture, publishing model selection, and delivery platform configuration. Understanding how Page Builder publishing works, selecting the right publishing model, and tuning performance settings can significantly improve both authoring efficiency and platform performance.
I hope this information helps you better understand and fine-tune your XM Cloud publishing strategy. If you would like to discuss this further, feel free to reach out or connect with me on LinkedIn.