I recently worked on a project where a lot of effort was spent on optimizing publishing experience for Content Authors using Sitecore XM Cloud. I have summarized the key concepts below so that you find most of the information related to publishing here.
Publishing in Page Builder
By default, when a page is published using page builder, the publishing is using smart mode with related items. After publishing a page using Page Builder, the page builder gets the context item and sets it as a root item. Then the page builder gets all the data source items that should be included in the publishing as well. The data source items are fetched from layout json data (layout { rendered } result if you query graphql endpoint) of the current page. Then all the found data source items will be set as "rootitems" (it's not only directly referenced items). The page builder sets the "rootitem" and "rootitems" param in the graphql query and sends the query to cm service. The cm service then does the publishing operation for all the "rootItems".
So, if your content is not architected carefully, this could result in a lot of items being published.
Edge Runtime Publishing (V2) vs Snapshot Publishing (V1)
We had two instances of XMCloud in Prod. We used version V1 in one instance because all the data was coming from the page item and very minimum data was from data source. We needed faster initial delivery of pages and there was not a lot of publishing happening during business hours. The content tree was simple.
On the other XM instance, we used V2 because the page was composed using lot of components reading data from global, local data sources and we needed faster publishing experience for content authors.
It is not that V2 is necessarily better than V1, you will have to investigate the content architecture and decide which one works for you.
On a high level -
Publishing V2 (Edge Runtime Publishing)– more granular, light mode. Smaller jsons are on edge, it has faster publishing time. Edge stores the main structure layout, with separate references to each data source. Publishes the requested item and references to its dependencies, with the final layout assembled at the Experience Edge during a delivery request. The layout is assembled on demand, which can add to the initial delivery time of a page. Static Site Generation builds can take longer because the initial request cost is higher and is less likely to be cached on the Edge.
Publishing V1 – Similar to traditional XP publishing. Publishes a complete snapshot of content and its dependencies on Experience Edge. Layout is assembled at publishing time. Publishing a single item might trigger a cascade of related items to be published, potentially causing performance issues. No impact on initial delivery performance. Publishing can be slow and resource-intensive due to large dependency graphs, especially with complex content trees.
Some settings to improve publishing time
We had a complex content tree and over 200K items in the content tree. Support provided some settings that can be applied using a patch file to increase the performance of publishing. The serializationMaxDepth setting was initially set to 4. We changed it to 3 since we did not have any graphQL that went 4 level deep.
- ExperienceEdge.IncludeDependencyAncestors set to false
- Publishing.DeepScanRelatedItems set to false
- serializationMaxDepth under layout service to 3
Vercel’s role
We used ISR for the app. The timeout was set to 15 minutes initially, then we changed it to 10 mins. This is a balance between cost and content refresh time for the organization. You will have to carefully work with the architects to meet in a common ground between cost and data refresh. Essentially, a timeout of 10 mins means that Vercel will check every 10 minutes if a new version of page is available or not. If a content author has publishing something 5 mins ago, it may not be available. If the timeout is set to 60 seconds, then Vercel will check every 60 seconds but then what is the point of ISR. You will approach rate limits and some performance thresholds plus additional cost from Vercel.
I hope this information helped you in understanding and fine-tuning publishing experience. If you need any more information, please reach out to me or contact me on Kautilya Prasad | LinkedIn