應用場景

內容豐富，復雜交互的動態(tài)網(wǎng)頁，對首屏加載有要求的項目，對 seo 有要求的項目（因為服務端第一次渲染的時候，已經(jīng)把關鍵字和標題渲染到響應的 html 中了，爬蟲能夠抓取到此靜態(tài)內容，因此更利于 seo）。此方式一些適合的項目：活動模板，新聞通知類，博客系統(tǒng)，混合開發(fā)等等。

SSR的優(yōu)勢：

有利于SEO:

不同爬蟲工作原理類似，只會爬取源碼，不會執(zhí)行網(wǎng)站的任何腳本（Google除外，據(jù)說Googlebot可以運行javaScript）。使用了React或者其它MVVM框架之后，頁面大多數(shù)DOM元素都是在客戶端根據(jù)js動態(tài)生成，可供爬蟲抓取分析的內容大大減少。另外，瀏覽器爬蟲不會等待我們的數(shù)據(jù)完成之后再去抓取我們的頁面數(shù)據(jù)。服務端渲染返回給客戶端的是已經(jīng)獲取了異步數(shù)據(jù)并執(zhí)行JavaScript腳本的最終HTML，網(wǎng)絡爬中就可以抓取到完整頁面的信息。

下面使用 node 寫一個簡單的請求，原來獲取頁面內容

const fs = require('fs')fetch('http://localhost:4200').then(response => response.text()).then(html => {// 使用 fs 將獲取到的內容保存到本地便于比對fs.writeFileSync(`${__dirname}/CSR.html`, html);console.log('HTML:', html);}).catch(error => {console.error('Error fetching the page:', error);});

對 SSR 和 CRS 頁面內容爬取做對比

下圖是 CSR 構建的頁面，通過爬蟲獲取頁面，可以看到只爬取到了項目打包后dist 文件中的 index.html 文件
其中可以用于 SEO 的數(shù)據(jù)只有 Title 一行代碼，對整個項目的 SEO 不太友好

下圖是 SSR 構建頁面，通過爬蟲獲取到了
SSR 構建的頁面可以爬到頁面上的所有內容，包括其中一些在后端渲染好的數(shù)據(jù)，其中讀取到的數(shù)據(jù)都可以用作 SEO

有利于首屏渲染

首屏的渲染是node發(fā)送過來的html字符串，并不依賴于js文件了，這就會使用戶更快的看到頁面的內容。尤其是針對大型單頁應用，打包后文件體積比較大，普通客戶端渲染加載所有所需文件時間較長，首頁就會有一個很長的白屏等待時間。

• 比對 SSR 和 CSR 首頁加載速度
  • 從 Network 中可以看出 SSR構建的頁面初始 HTML 是在服務器上生成的，并在服務器上完成渲染。服務器返回已渲染好的 HTML 內容給客戶端
  • CRS 構建的項目，會先去獲取 JS 文件，獲取完之后再去請求接口獲取數(shù)據(jù)，如果 JS 文件比較大，就會有一個很長的等待時間形成一個首頁白屏的問題

局限

服務端壓力較大

SSR 將頁面渲染移動到服務器端，頁面的每一次點擊、修改都需要調用因此會增加服務器的壓力，以其相比還是 CSR 更方便一點

開發(fā)條件受限

在服務端渲染中，只會執(zhí)行 ngOnInit 、 ngOnDestroy、 ngAfterViewInit、 ngAfterContentInit 等生命周期鉤子，因此項目引用的第三方的庫也不可用其它生命周期鉤子，這對引用庫的選擇產(chǎn)生了很大的限制；

復雜的客戶端交互

SSR： 通常需要更多的服務器端配置和復雜的代碼。前后端更緊密耦合，開發(fā)和維護相對復雜。
CSR： 更容易實現(xiàn)，前后端分離較為徹底，前端負責渲染和交互，后端提供 API。

在一些項目中，也可以采用混合使用 SSR 和 CSR 的方式，這被稱為“漸進式渲染”（Progressive Rendering）。這樣可以充分利用 SSR 的優(yōu)勢來提高首屏加載性能，同時在頁面交互性較高的部分使用 CSR。