在 Angular 應用程式中使用伺服器端渲染，出於以下幾種原因：

1. SSR 有助於搜尋引擎最佳化。 搜尋引擎爬蟲可以解析透過伺服器端渲染的 HTML 頁面原始碼。而執行在 CSR 模式下的單頁面應用，頁面原始碼是在客戶端瀏覽器裡執行復雜的 JavaScript 生成，現代很多爬蟲對此內容無能為力。

2. Facebook 和 Twitter 等社交媒體平臺，可以在共享時顯示 SSR 渲染出的網站的預覽。

3. 在伺服器上呈現網頁後，頁面內容可以被快取，從而能夠更快的響應使用者相同的頁面請求。

要在 Angular 應用程式中實現伺服器端渲染，可以使用 Angular Universal package.

![](https://img-blog.csdnimg.cn/img_convert/71198917bbde23532e82e1ff9476445b.png)

當我們使用 Angular Universal 時，向 OCC 伺服器發起業務資料請求的 API 觸發兩次。首先是在伺服器渲染頁面時實行一次，第二次是在客戶端應用程式啟動時觸發。這種 API 重複觸發的方式會導致延遲問題和糟糕的使用者體驗，因為發生這種情況時螢幕通常會閃爍(`flickering`).

![](https://img-blog.csdnimg.cn/img_convert/08ed53d1cc7ddf405c7dd814b1c6140c.png)

此外，SAP CCV2 上的 SSR 容器是執行 Node.js 程式碼的地方，因此更容易受到效能下降的影響。在選擇 Node.js 和 server.js jsapps-* 之後，可以從 Dynatrace 中的技術和程式頁面檢視 CPU 和記憶體。注意 SSR 應用檔案的名稱可能不同，預設為 main.js.

![](https://img-blog.csdnimg.cn/img_convert/99a27b19dcccfd3ae97ecd90a4a79200.png)

隨後的頁面將顯示所選任何給定指標的平均利用率。 單擊單個 pod 將進入其程式詳細資訊頁面，其中可以檢視有關 cpu/記憶體利用率和重新啟動時間的資訊。 對於 SSR，有關 CPU 的詳細資訊將在系統效能選項卡下，而有關 V8 記憶體使用的詳細資訊將在 Node.js 指標選項卡下。

![](https://img-blog.csdnimg.cn/img_convert/3e3d7fc812cf0bdb44915e4e0042232e.png)

當發現 SSR Pod 的 CPU 利用率居高不下時，基於 Node.js 的設計，儘管我們可以透過垂直擴充套件來緩解這個問題, 另一方面，如果併發請求的數量很大，那麼也可以考慮透過水平擴充套件的方式來降低每個 Pod 的 CPU 利用率。

儘可能多地消除 Spartacus Storefront 中 CPU 密集型程式碼 ，必要時可以研究是否能夠將邏輯轉移到 OCC 層執行。

執行在 CCV2 環境上的 Angular 伺服器端渲染應用的效能瓶頸分析

相關文章