共计 841 个字符，预计需要花费 3 分钟才能阅读完成。
在 Angular 应用程序中应用服务器端渲染，出于以下几种起因：
- SSR 有助于搜索引擎优化。搜索引擎爬虫能够解析通过服务器端渲染的 HTML 页面源代码。而运行在 CSR 模式下的单页面利用，页面源代码是在客户端浏览器里执行简单的 JavaScript 生成，古代很多爬虫对此内容无能为力。
- Facebook 和 Twitter 等社交媒体平台，能够在共享时显示 SSR 渲染出的网站的预览。
- 在服务器上出现网页后，页面内容能够被缓存，从而可能更快的响应用户雷同的页面申请。
要在 Angular 应用程序中实现服务器端渲染，能够应用 Angular Universal package.
当咱们应用 Angular Universal 时，向 OCC 服务器发动业务数据申请的 API 触发两次。首先是在服务器渲染页面时履行一次，第二次是在客户端应用程序启动时触发。这种 API 反复触发的形式会导致提早问题和蹩脚的用户体验，因为产生这种状况时屏幕通常会闪动 (flickering).
此外，SAP CCV2 上的 SSR 容器是运行 Node.js 代码的中央，因而更容易受到性能降落的影响。在抉择 Node.js 和 server.js jsapps-* 之后，能够从 Dynatrace 中的技术和过程页面查看 CPU 和内存。留神 SSR 利用文件的名称可能不同，默认为 main.js.
随后的页面将显示所选任何给定指标的均匀利用率。单击单个 pod 将进入其过程详细信息页面，其中能够查看无关 cpu/ 内存利用率和重新启动工夫的信息。对于 SSR，无关 CPU 的详细信息将在零碎性能选项卡下，而无关 V8 内存应用的详细信息将在 Node.js 指标选项卡下。
当发现 SSR Pod 的 CPU 利用率居高不下时，基于 Node.js 的设计，只管咱们能够通过垂直扩大来缓解这个问题, 另一方面，如果并发申请的数量很大，那么也能够思考通过程度扩大的形式来升高每个 Pod 的 CPU 利用率。
尽可能多地打消 Spartacus Storefront 中 CPU 密集型代码，必要时能够钻研是否可能将逻辑转移到 OCC 层执行。
