理解 React + SSR 整體架構

前言

隨著前端技術發展更新的越來越快，這幾年陸續推出了許多新框架，像是 Vue, React 等等，此外，也對於前端性能上越來越重視其性能、資源消耗等。本篇文章要來介紹關於 SSR 這個技術，為什麼有 SSR 德出現，適用場景以及原理。

正文

SSR 的全稱是 Server Side Rendering，顧名思義就是服務端渲染。要了解 SSR，有一個重要的概念『同構』，必且也要理解客戶端渲染和服務端渲染的區別，這邊就來先釐清下這三個概念。

客戶端渲染

客戶端渲染指的是說：

頁面初始加載的 HTML 頁面中沒有內容展示，啥都沒有，需要加載執行 JavaScript 文件中的 React 代碼，通過 JavaScript 渲染生成頁面，同時，JavaScript 代碼會完成頁面交互事件的綁定，詳細流程可參考下圖：

• Client Side Render

（圖片來自 fullstackacademy.com）

服務端渲染

服務器端渲染指的是說：

用戶請求服務器，服務器上直接生成所有需要的 HTML 內容並返回給瀏覽器。一般來說，服務器端渲染的頁面交互能力有限，如果要實現複雜的交互，還是要通過引入 JavaScript 文件來輔助實現。

（圖片來自 fullstackacademy.com）

同構

同構這個概念存在於 Vue，React 這些新型的前端框架中，同構實際上是客戶端渲染和服務器端渲染的一個整合。我們把頁面的展示內容和交互寫在一起，讓代碼執行兩次。在服務端執行一次，用於實現服務端渲染，在客戶端再執行一次，用於接管頁面交互。

• Server Side Render

（圖片來自 fullstackacademy.com）

其實一般情況下，當我們使用 react 時，頁面都是交給客戶端的瀏覽器直接執行 js 生成 DOM 的，我們常聽到的 SPA(Single Page Application)單頁面應用實際上就都是採用 CSR 模式。那既然這樣，為什麼需要引入 SSR 呢？

Why SSR ?

SSR 之所以出現以及越來越主流，主要是因為下面兩個因素：

1. 傳統的 CSR 的 TTFP(Time To First Page) 會比較長，因為在 CSR 的頁面渲染流程中，首先要先加載 html 文件，然後要下載頁面所需要的 js 文件、css 文件等，然後具體其實由 js 文件渲染生成頁面。在這樣的渲染過程中至少涉及到兩次 http 請求週期，請求 html 文件和 js 文件。其實這也就是為什麼有時候我們在網路狀態較不好的環境下訪問普通的 react 或是 vue 項目時，會加載比較久甚至出現白屏的情況。

2. CSR 的 SEO 能力極差，基本在搜索引擎中不可能會有好的排名。這是因為其實目前主流的搜索引擎還是以識別 html 為主，對 js 文件的識別能力還是較弱。如果項目的流量入口來源主要依賴於搜索引擎，這個時候還使用 CSR 進行開發就不太合適了。

</