SAP Spartacus CMS 页面加载逻辑和性能的优化

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集成用的。

SAP Spartacus CMS 页面加载逻辑和性能的优化

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,及下图所示的设置:

SAP Spartacus CMS 页面加载逻辑和性能的优化

但是两次跳转过程中,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.

上一篇:JProfiler分析CPU占用实用教程


下一篇:四种常见的 POST 提交数据方式