React 走出新手村 — CSR處方簽

15th鐵人賽 react front-end 前端觀念渲染機制

362 瀏覽

溫馨提示

在之前架構和渲染機制的文章有提到一些渲染機制的基礎，還不熟悉的朋友可以先去閱讀那篇文章。

那麼我們今天就來聊聊如何改善 Client Side Rendering（C.S.R.）的問題吧！

在 Client Side Rendering（以下簡稱CSR）中，伺服器僅呈現頁面的基本 HTML 骨架，頁面內容所需的邏輯、數據獲取、模板化和路由操作由在瀏覽器/客戶端執行的 main.js 處理。

CSR 成為構建單頁應用程式(Single Page Application)的一種流行方法，也使得網站開發更接近於應用程式開發的脈絡，就是我們常講的 web app。

讓我們先深入了解客戶端渲染（CSR），找出它在哪些情況下運作得很好，以及它的缺點是什麼，下面我用之前文章所做的圖面，以便大家理解一下我前面說的內容。

隨著頁面的複雜性增加，例如顯示圖片、從資料存儲中顯示數據以及包括事件處理，類似 state management 那種東西，用於渲染頁面所需的 JavaScript 的複雜性和大小也會增加。

CSR 會產生較肥大的 JavaScript 檔案，這增加了頁面的首次內容繪製（FCP）和初始可交互時間（TTI）。

圖片來源

正如上面的插圖所示，隨著 bundle.js 的大小增加，首次內容繪製（FCP）和初始可交互時間（TTI）被推遲。

也就是說用戶在 FP 和 FCP 之間的整個時間段內將看到空白畫面，CSR 可以讓我們做到無需頁面刷新的網頁應用程式，並提供很好的使用者體驗。

由於處理抽換畫面的數據是有限的，所以在頁面之間進行路由通常更快，使 CSR 應用程式看起來更具響應性，CSR 也讓前後端的 code 實現清晰的分離。

SEO 考慮因素： 大多數網頁爬蟲可以直接解析伺服器呈現的網站，在 CSR 的情況下，大量的數據負載和一系列的 http 請求，可能導致有意義的內容無法被快速呈現，以便爬蟲進行索引，爬蟲可能理解 JavaScript，但也存在限制。
效能： 在CSR中，由於不需要與伺服器來回通信，互動期間的響應時間大幅提升，為了在用戶端首次渲染內容，瀏覽器必須等待 JavaScript 載入並開始處理，因此，使用者在初始頁面載入之前可能會遇到一些延遲，這可能會影響使用者體驗，特別是當 bundle JS 變得更大的時候。
資料擷取： 在CSR中，資料擷取通常是事件驅動的，頁面可能最初會在沒有任何資料的情況下載入，在發生事件（例如頁面載入或按鈕點擊）時，資料可能隨後透過 API 呼叫進行擷取，根據資料的大小，這可能會增加應用程式的載入/互動時間。

這些考慮因素的重要性可能會因不同需求而有所不同，我們會希望找到既能提供更快頁面載入又不會影響互動時間的 SEO 友好解決辦法，根據需求，不同的效能標準可能會有不同的優先級。有時候，僅需在客戶端渲染中進行一些微調，而不必採用完全不同的模式。

控制 JavaScript 預算： 確保在初始頁面載入時，有一個相當緊縮的 JavaScript 預算。初始的捆綁包大小應保持在小於 100–170KB 經壓縮和最小化的範圍內，這是一個不錯的起點，然後可以按需載入程式碼以滿足所需的功能。
pre-load： 這個技術可以用來預先載入在頁面生命週期早期所需的關鍵資源，關鍵資源可能包括 JavaScript，可以通過在 HTML 的 <head> 區域中加入指令來預先載入。
```
// 預載入圖片
<link rel="preload" href="large-image.jpg" as="image">
// 預載入js
<link rel="preload" as="script" href="important.js" />
```
lazy loading： 透過 React.lazy 我們可以分批載入js，並只在需要時載入這些資源，使用這種方法可以改善初始頁面載入時間，因為初始載入的資源大小會減少。例如，聊天小工具元件通常在頁面載入時不需要立即使用，可以進行延遲加載。
code splitting： 為了避免包完的 JavaScript 仍然過於肥大，可以透過包板工具對 bundle 的過程加入分割檔案的工作，例如 Webpack 這樣的包板工具可以支援用來建立多個 bundle.js，這些分開的檔案可以在執行時動態載入，code splitting 也可以延遲加載 JavaScript 資源。