Sitecore XM Cloud: Snapshot Publishing Vs Edge runtime Publishing
Introduction
Publishing in XM Cloud works differently compared to XP/XM. For items with layouts, a JSON representation is generated, and the structure of this JSON varies depending on the type of publishing selected.
Snapshot publishing (v1) - stores the JSON as a single entity on Experience Edge.
Edge runtime publishing (v2) - stores the main structure layout, with separate references to each data source. The layout is assembled at delivery time (runtime) instead of publishing time. If there are any Integrated Queries even those are executed at Runtime
In Snapshot Publishing, whenever a datasource is updated, the entire page needs to be republished because a new layout JSON must be generated.
If the change happens in a global datasource (for example, the header), then all pages need to be republished — which is similar to doing a full site publish. This is why Sitecore recommends not including global data in the Layout Service output. Instead, Sitecore suggests fetching global data through a GraphQL call from the rendering host.
Additionally, integrated GraphQL queries are executed during publishing, they can further increase the publishing time.
To address these issues, Sitecore offers an option to opt in to Edge Runtime Publishing. In this approach, changes in a datasource do not trigger page publishing. Instead, the layout is assembled at delivery time (runtime) rather than at publishing time. This significantly improves publishing speed, but comes with a trade-off: the initial page delivery may be slightly slower.
Decision Guide
| Parameter | Snapshot Publishing | Edge Runtime Publishing | Notes / Impact |
| Publishing Speed | Not preferred, but can be considered if global datasources are fetched via GraphQL queries from the rendering host and if there are no integrated graphql queries. | Preferred | In edge runtime Publishing dependant pages are not published and Integrated graphql queries are Not Executed during publish time which improves the publishing speed |
| Initial Page Load | Preferred | Not Preferred, can be considered if ISR is implemented | In Edge Runtime, pages are assembled at runtime, and any integrated GraphQL queries are executed on the fly. This means the first page load after a cache clear can be slower. However, if Incremental Static Regeneration (ISR) is implemented, this impact can be minimised or even eliminated. |
| Capability to publish only Specific Sections of a page | Not Preferred, Can be considered if workflows are implemented and there are no shared fields | Preferred | In Snapshot publishing the complete json is regenerated which can update other sections of the page |
| Large Layout Size | Preferred | Not Preferred | In Edge runtime publishing there is threshold set for the layout size, publishing fails if size is more than the specified threshold |
| Content Freshness of Integrated Graphql Query Response | Not Prefered. Calculated at publish time. Only refreshed after a republish of the page | Preferred | In Edge runtime publishing integrated graphql response is fetched at runtime and therefore rendered correctly |
| Content Resolvers | Supported | Supported with Configuration changes | In edge runtime publishing an additional configuration change is required to ensure accuracy |
| Additional publishing | If you use a local datasource, the page is not treated as a dependency, so the page item must be published explicitly | if a datasource item has dependencies. for any change in dependency(eg child items) the datasource must be published explicitly | In Snapshot publishing if datasource changes are not reflected on the page we would need to explictly publish. In Edge runtime publishing we would need to publish the actual datasource items for any datasource dependency changes |
How to Enable Edge Runtime Publishing
In the Deploy app, create an environment variable:
Sitecore_ExperienceEdge_dot_WorkerStoreEnabled and set it to trueRestart the environment
Republish All the Sites
How to Revert Back to Snapshot Publishing
In the Deploy app, create an environment variable:
Sitecore_ExperienceEdge_dot_WorkerStoreEnabled and set it to falseRestart the environment
Delete Edge Content
Republish All the Sites
Conclusion
In conclusion, the choice between Snapshot Publishing and Edge Runtime Publishing in XM Cloud depends on various factors such as publishing speed, initial page load time, and content freshness. Snapshot Publishing is suitable for scenarios where global datasources are fetched via GraphQL queries, and large layout sizes are involved. However, it requires republishing the entire page for any datasource updates. On the other hand, Edge Runtime Publishing offers improved publishing speed and content freshness by assembling layouts at runtime, making it ideal for dynamic content scenarios. It is important to weigh the trade-offs, such as the potential for slower initial page loads, and consider implementing strategies like Incremental Static Regeneration (ISR) to mitigate these effects. Ultimately, the decision should align with the specific needs and priorities of your project.
