https://github.com/SAP/spartacus/issues/3649

SAP Commerce Cloud CMS 页面加载的一些优化点：

• Payload of the CMS page structure - 待加载CMS 页面结构的负载
• Splitting the CMS page structure in both page and page template CMS
• improve cache-ability of the CMS page structure

CMS page structure payload (#3668)

One of the main performance gains will be around the CMS page structure which is loaded when we navigate the storefront. The current payload is polluted and too heavy weighted for the purpose, and is loaded over and over again during navigation.

目前的Spartacus实现里，后台OCC API返回的很多数据，在Spartacus里根本不需要。

Currently the page payload is polluted with data which is required for SmartEdit integration. This includes the page.uuid, contentSlot.slotUuid and component.uuid. These fields contain a pretty long hash, and are only required during the SmartEdit integration and not required for the production storefront.

比如下图这些数据，只是为了和 SmartEdit集成用的。

While there is actually a good reason to reload page data while navigating (in order to support the CMS restrictions which might expose new pages and components during navigation), the possibility that component would actual change on a 2nd page load is fairly low.

尽管每次跳转时，重新从SAP Commerce Cloud 后台读取CMS页面数据，是为了支持 CMS restriction，及下图所示的设置：

但是两次跳转过程中，CMS page Restricted Page Types 在后台发生变化的可能性太低太低。

Therefor we should consider a more efficient API that will be used to evaluate if there’s a change. If any, we could do an additional call, or – even better – introduce server push to preload it automatically.

因此有必要设计一个API，用来评估后台CMS restriction是否发生变化：仅当真的有变化时，才重新加载页面。

https://github.com/SAP/spartacus/issues/3668

Avoid reloading full page data (see #3667)

Additionally, the current page payload contains both the CMS page structure as well as the associated CMS page template structure. As already pointed out, the payload is heavy, and blocks the experience. In order to optimise, we should avoid loading the full payload during navigation.

更多Jerry的原创文章，尽在：“汪子熙”: