使用 React 進行服務器端渲染

已發表: 2021-05-27

一點關於 React

React 是一個開源前端 JavaScript 庫，由 Facebook 開發者社區創建和維護。 它用於構建用戶界面或 UI 組件。

然而，這個定義對於新手來說可能並不完全理解。 我們有一篇完美的博客文章，它會引導您完成對 React 的簡要說明，一直到非常詳細的技術描述，您可以在此處找到。

網頁之旅 | 從服務器到瀏覽器

要了解什麼是服務器端渲染，首先要了解網頁在屏幕上的顯示方式，如下圖所示：

ssr-with-react-webpage-server-to-browser
  1. 每當您輸入網站的 URL 或單擊該網站的鏈接時，您的瀏覽器都會向由 URL 標識的相應服務器發送對某些文件的請求。
  2. 服務器將一些文件（例如 HTML 和 JavaScript 文件等）發送到您的瀏覽器。
  3. 您的瀏覽器下載並“呈現”或處理這些文件，您可以查看您請求的網頁並與之交互。

這是對網頁旅程的過度簡化，但對於解釋完成此任務的不同子步驟和不同方式（包括服務器端渲染）來說，這是一個足夠好的前言。

“正常”客戶端渲染網頁的旅程

深入研究上一節中提到的過程，我們有一種稱為客戶端渲染或 CSR 的技術，該技術已經使用了很長時間，可以在用戶的屏幕上顯示網站。 下圖中對此進行了解釋：

ssr-with-react-csr-網頁渲染
  1. 在輸入網站的 URL 或單擊該網站的鏈接時，您的瀏覽器會向由 URL 標識的相應服務器發送對某些文件的請求。
  2. 服務器發送 HTML 文件，其中包含對其他資產（如圖像文件、CSS 文件和 JavaScript 文件）的引用。
  3. 瀏覽器再次向服務器發送請求並下載所有文件，包括 HTML 文件中引用的 CSS 和 JavaScript 文件。
    1. 如果用戶連接不良並且 JavaScript 文件很大，這可能是增加網站加載時間的一個因素。
  4. 一旦瀏覽器下載了這些文件，瀏覽器就會執行框架或庫（例如 React）並解析 JavaScript 文件，這些文件負責使網頁具有交互性。
    1. 從速度優化的角度來看，這一點取決於客戶端機器，如果客戶端是低功耗硬件，這可能會花費大量時間。
    2. 執行這些步驟時，用戶仍會看到加載屏幕
  5. 網頁最終完全加載，用戶可以看到網頁並與之交互。

正如上面提到的步驟很清楚，從用戶的角度來看，他們只能在客戶端機器下載和呈現所有必要的文件之後，在最後一步看到網站並與網站交互。

這可能會花費大量時間，因為它取決於客戶端機器在執行框架和解析 JavaScript 文件時的性能。

服務器端渲染網頁的歷程

用一行來解釋它，服務器端渲染或 SSR 是獲取客戶端 JavaScript 框架網站並將其呈現為服務器而不是客戶端上的靜態 HTML 和 CSS 的過程，就像 CSR 中的情況一樣。

下面提到的是一個網頁使用服務器端渲染和 React 所經歷的旅程的圖形表示：

ssr-with-react-ssr-webpage-rendering-with-react
  1. 在輸入網站的 URL 或單擊該網站的鏈接時，您的瀏覽器會向由 URL 標識的相應服務器發送對某些文件的請求。
  2. 服務器，而不是像在 CSR 中那樣僅發送普通 HTML 文件，而是使用從react-dom/server導入的renderToString函數將應用程序呈現為字符串
    1. 然後將其註入 index.html 文件並發送到瀏覽器。
    2. 從功能上講，這就是 SSR 的關鍵所在，因為這是服務器呈現頁面的地方，而不是客戶端機器。
  3. 瀏覽器呈現此 HTML 文件，從而在瀏覽器中填充視圖。
    1. 然而，這還不是交互式的，但用戶可以看到網頁的最終視圖。
  4. 瀏覽器再次向服務器發送請求並下載 HTML 文件中引用的所有文件，包括 JavaScript 文件。
  5. 一旦下載了所有腳本，React 組件就會再次呈現在客戶端上。 然而，這一次，它補充了現有的視圖，而不是覆蓋它。
    1. “水合”視圖意味著它將任何事件處理程序附加到呈現的 DOM（文檔對像模型）元素，但保持呈現的 DOM 元素完整。 這樣，DOM 元素的狀態被保留，並且不會發生視圖重置。
  6. 網頁最終完全加載，用戶現在可以與他們在第 3 步中看到的頁面進行交互。

因此，從用戶的角度來看，最大的視覺變化之一是網頁很快變得“可見”，因為從瀏覽器的角度來看，呈現 HTML 並不是那麼資源密集型。

這本身並不會使頁面加載速度比非 SSR 應用程序更快，但它確實為用戶提供了網頁的視圖，因為 JavaScript 文件在後台下載和解析，之後網頁變為交互式。 這意味著 TTI，即交互時間（這是從用戶請求網頁到網頁完全交互所需的時間）比網頁可見所需的時間多一點在瀏覽器中。

因此，在 SSR 場景中，為了更快的首次渲染時間，您的 HTML 和 CSS 需要對用戶有意義，並且 JavaScript 可以作為 HTML 和 CSS 的增強，因為它的加載是延遲的。

關於 SSR 與 React 的工作方式的一個常見誤解是，在每次更改之後，例如用戶請求任何新數據，服務器再次完成所有步驟並將帶有新 UI 的 HTML 文件發送到瀏覽器，但事實並非如此. 只完成了對頁面的部分更新。 儘管渲染是由服務器完成的，但最終的輸出通過“水合”它被插入到 DOM 中，如前所述。

ssr-with-react-pros-cons-of-ssr

服務器端渲染 | 何時以及何時不使用

  • 如果您需要強大的 SEO，請選擇 SSR，因為它更容易讓搜索引擎抓取。
  • 對於注重內容而不注重交互的網站，例如博客、新聞網站、靜態網站和文本繁重的網站，SSR 可能是一個福音，因為它會加載您網站的關鍵，即內容超快。
  • 在服務器端渲染和生成要發送到瀏覽器的文件需要時間和精力。 因此，如果您的服務器和運營預算較低，最好不要實施 SSR，因為會有很多請求發送到您的服務器。
    • 但是，有了 Firebase 等提供商，我們可以通過雲功能動態生成內容，服務器可以將其存儲在 CDN 緩存中
    • 這將做的是，下次當用戶請求時，服務器不會再次生成文件。 相反，它只是從本地 CDN 邊緣提供服務，從用戶的角度來看縮短了加載時間，同時還使用了更少的服務器資源。

React 對 SSR 有什麼好處？

React 是實現 SSR 的絕佳選擇，因為它結合了虛擬 DOM（文檔對像模型）的概念。

這使開發人員能夠創建 React 應用程序的虛擬版本，並將其安裝在服務器本身中。

這使得使用前面討論的 renderToString 函數更容易將其呈現為 HTML，將其發送到瀏覽器，以便瀏覽器可以非常快速地呈現它並在客戶端計算機上創建虛擬版本。

因此，考慮到這個虛擬版本與我們從服務器發出的 HTML 相匹配的事實，React 不會重新渲染它，從而減少了交互時間 (TTI)，從而“更快”地加載網頁。

SSR，一整天，每一天！

我們希望有一個萬能的解決方案，但情況遠非如此，尤其是在新技術的情況下。 儘管 SSR 有很多好處，但如前所述，在某些情況下，SSR 可能不是一個好的選擇； 高度互動的網站處於領先地位。

這就是 Creole Studios 的用武之地。我們擁有眾多技術專家，他們始終與科技界出現的幾乎每一項新技術保持同步。 我們將了解您的業務需求並為您提供定制的解決方案，無論是 SSR 還是 CSR 應用程序，請放心，在我們為您完成繁重工作的同時，您無需擔心任何事情。 聯繫我們，將您的想法從您的腦海中轉化為應用程序！