[Rendering on the Web ](https://developers.google.com/web/updates/2019/02/rendering-on-the-web)

作為開發人員，我們經常面臨會影響應用程式整個架構的決策。 Web 開發人員必須做出的核心決策之一是在他們的應用程式中實現邏輯和呈現的位置。 這可能很困難，因為有許多不同的方法來構建網站。

我們對這一領域的理解源於我們過去幾年在 Chrome 中與大型網站的交流工作。 從廣義上講，我們鼓勵開發人員考慮伺服器渲染或靜態渲染，而不是完全重新 hydration 的方法。

為了更好地理解我們在做出這個決定時選擇的架構，我們需要對每種方法和在談論它們時使用的一致術語有深刻的理解。 這些方法之間的差異有助於從效能的角度說明在 Web 上渲染的權衡。

# 渲染

* SSR：伺服器端渲染 - 在伺服器上將客戶端或通用應用程式渲染為 HTML。

* CSR：客戶端渲染 - 在瀏覽器中渲染應用程式，通常使用 DOM。

* Rehydration：在客戶端“啟動”JavaScript 檢視，以便它們重用伺服器渲染的 HTML 的 DOM 樹和資料。

* Prerendering：在構建時執行客戶端應用程式以將其初始狀態捕獲為靜態 HTML。

* TTFB：Time to First Byte - 被視為單擊連結和第一個內容進入之間的時間。
* FP：First Paint - 任何畫素第一次對使用者可見。
* FCP：First Contentful Paint - 請求的內容（文章正文等）變得可見的時間。
* TTI: Time To Interactive - 頁面變為可互動的時間（事件連線等）。

# Server Rendering

伺服器渲染為伺服器上的頁面生成完整的 HTML 以響應導航。 這避免了在客戶端上進行資料獲取和模板化的額外往返，因為它是在瀏覽器獲得響應之前處理的。

伺服器渲染通常會產生快速的首次繪製 (FP) 和首次內容繪製 (FCP)。 在伺服器上執行頁面邏輯和渲染可以避免向客戶端傳送大量 JavaScript，這有助於實現快速互動時間 (TTI)。 這是有道理的，因為透過伺服器渲染，您實際上只是向使用者的瀏覽器傳送文字和連結。 這種方法可以很好地適用於各種裝置和網路條件，並開啟了有趣的瀏覽器最佳化，例如流式文件解析。

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

透過伺服器渲染，使用者不太可能在使用您的網站之前等待 CPU 繫結的 JavaScript 處理。即使無法避免第三方 JS，使用伺服器渲染來降低您自己的第一方 JS 成本也可以為您提供更多的“預算”。但是，這種方法有一個主要缺點：在伺服器上生成頁面需要時間，這通常會導致首位元組時間 (TTFB) 變慢。

伺服器渲染是否足以滿足您的應用程式在很大程度上取決於您正在構建的體驗型別。關於伺服器渲染與客戶端渲染的正確應用程式存在長期爭論，但重要的是要記住，您可以選擇對某些頁面使用伺服器渲染而不是其他頁面。一些網站已經成功地採用了混合渲染技術。 Netflix 伺服器呈現其相對靜態的登陸頁面，同時為互動密集型頁面預取 JS，為這些較重的客戶端呈現頁面提供更好的快速載入機會。

許多現代框架、庫和架構使得在客戶端和伺服器上呈現相同的應用程式成為可能。這些技術可用於伺服器渲染，但重要的是要注意渲染髮生在伺服器和客戶端的架構是它們自己的解決方案類，具有非常不同的效能特徵和權衡。 React 使用者可以使用 renderToString() 或基於它構建的解決方案，例如 Next.js 進行伺服器渲染。 Vue 使用者可以檢視 Vue 的伺服器渲染指南或 Nuxt。 Angular 有 Universal framework.大多數流行的解決方案都採用某種形式的 hydration 作用，因此在選擇工具之前請注意使用的方法。

# Static Rendering

靜態渲染髮生在構建時，並提供快速的首次繪製、首次內容繪製和互動時間 - 假設客戶端 JS 的數量有限。 與伺服器渲染不同，它還設法實現始終如一的快速首位元組時間，因為頁面的 HTML 不必即時生成。 通常，靜態呈現意味著提前為每個 URL 生成單獨的 HTML 檔案。 透過提前生成 HTML 響應，可以將靜態呈現器部署到多個 CDN 以利用邊緣快取。

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

靜態渲染的解決方案有各種形狀和大小。 Gatsby 之類的工具旨在讓開發人員感覺他們的應用程式是動態呈現的，而不是作為構建步驟生成的。其他像 Jekyll 和 Metalsmith 這樣的公司擁抱它們的靜態特性，提供了一種更加模板驅動的方法。

靜態呈現的缺點之一是必須為每個可能的 URL 生成單獨的 HTML 檔案。如果您無法提前預測這些 URL 的內容，或者對於具有大量獨特頁面的網站，這可能具有挑戰性甚至不可行。

React 使用者可能熟悉 Gatsby、Next.js 靜態匯出或 Navi - 所有這些都可以方便地使用元件進行創作。但是，瞭解靜態渲染和預渲染之間的區別很重要：靜態渲染頁面是互動式的，無需執行大量客戶端 JS，而預渲染改進了必須啟動的單頁應用程式的首次繪製或首次內容繪製客戶端以使頁面真正具有互動性。

如果您不確定給定的解決方案是靜態渲染還是預渲染，請嘗試以下測試：禁用 JavaScript 並載入建立的網頁。對於靜態呈現的頁面，大多數功能在沒有啟用 JavaScript 的情況下仍然存在。對於預渲染頁面，可能仍然有一些基本功能，如連結，但大部分頁面將是惰性的。

另一個有用的測試是使用 Chrome DevTools 降低網路速度，並觀察在頁面變為可互動之前已下載了多少 JavaScript。預渲染通常需要更多的 JavaScript 才能獲得互動性，而且 JavaScript 往往比靜態渲染使用的漸進增強方法更復雜。

# Server Rendering vs Static Rendering

伺服器渲染不是靈丹妙藥——它的動態特性會帶來大量的計算開銷成本。許多伺服器渲染解決方案不會提前重新整理，可能會延遲 TTFB 或將傳送的資料加倍（例如，客戶端上的 JS 使用的內聯狀態）。在 React 中，renderToString() 可能很慢，因為它是同步的和單執行緒的。使伺服器渲染“正確”可能涉及為元件快取找到或構建解決方案、管理記憶體消耗、應用記憶技術以及許多其他問題。您通常會多次處理/重建同一個應用程式 - 一次在客戶端上，一次在伺服器中。僅僅因為伺服器渲染可以使某些東西更快地顯示出來並不突然意味著您要做的工作更少。

SSR 為每個 URL 按需生成 HTML，但可能比僅提供靜態呈現的內容慢。如果您可以進行額外的工作，伺服器渲染 + HTML 快取可以大大減少伺服器渲染時間。與靜態渲染相比，伺服器渲染的優勢在於能夠提取更多“實時”資料並響應更完整的請求集。需要個性化的頁面是不能很好地與靜態呈現一起工作的請求型別的具體示例。

在構建 PWA 時，伺服器渲染也可以提供有趣的決策。使用全頁面 Service Worker 快取還是僅伺服器渲染單個內容更好？

# Client-Side Rendering (CSR)

客戶端渲染 (CSR) 是指使用 JavaScript 直接在瀏覽器中渲染頁面。 所有邏輯、資料獲取、模板和路由都在客戶端而不是伺服器上處理。

對於移動裝置，客戶端渲染可能難以獲得並保持快速。 如果做最少的工作，保持緊張的 JavaScript 預算並以儘可能少的 RTT 交付價值，它可以接近純伺服器渲染的效能。 使用 HTTP/2 伺服器推送或 \<link rel="preload"> 可以更快地交付關鍵指令碼和資料，這可以讓解析器更快地為您工作。 像 PRPL 這樣的模式值得評估，以確保初始和後續導航感覺即時。

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

客戶端渲染的主要缺點是所需的 JavaScript 量會隨著應用程式的增長而增長。 新增新的 JavaScript 庫、polyfill 和第三方程式碼後，這變得尤其困難，它們會爭奪處理能力，並且通常必須在呈現頁面內容之前進行處理。 使用依賴於大型 JavaScript 包的 CSR 構建的體驗應該考慮積極的程式碼拆分，並確保延遲載入 JavaScript——“只在需要時提供您需要的服務”。 對於互動性很少或沒有互動性的體驗，伺服器渲染可以代表這些問題的更具可擴充套件性的解決方案。

對於構建單頁應用程式的人來說，識別大多數頁面共享的使用者介面的核心部分意味著您可以應用應用程式外殼快取技術。 與服務工作者相結合，這可以顯著提高重複訪問時的感知效能。

# Combining server rendering and CSR via rehydration

通常被稱為 Universal 渲染或簡稱為“SSR”，這種方法試圖透過同時進行客戶端渲染和伺服器渲染之間的權衡來平衡。諸如整頁載入或重新載入之類的導航請求由將應用程式呈現為 HTML 的伺服器處理，然後用於呈現的 JavaScript 和資料被嵌入到生成的文件中。如果仔細實施，這將實現快速的第一次內容繪製，就像伺服器渲染一樣，然後透過使用稱為（重新）Hydration 的技術在客戶端再次渲染來“拾取 Pick up”。這是一個新穎的解決方案，但它可能有一些相當大的效能缺陷。

帶有再 hydration 的 SSR 的主要缺點是它會對互動時間產生顯著的負面影響，即使它改進了 First Paint。 SSR 的頁面通常看起來像是在載入和互動，但在執行客戶端 JS 並附加事件處理程式之前，它們實際上無法響應輸入。在移動裝置上這可能需要幾秒鐘甚至幾分鐘的時間。

也許您自己也經歷過這種情況 - 在看起來頁面已載入後的一段時間內，單擊或點選什麼也沒做。這很快變得令人沮喪......“為什麼什麼都沒有發生？為什麼我不能滾動？”

# A Rehydration Problem: One App for the Price of Two

Rehydration 問題通常比 JS 導致的延遲互動更糟糕。 為了讓客戶端 JavaScript 能夠準確地“接收”伺服器中斷的位置，而不必重新請求伺服器用於呈現其 HTML 的所有資料，當前的 SSR 解決方案通常將來自 UI 的響應序列化 資料依賴項作為指令碼標籤寫入文件。 生成的 HTML 文件包含高度重複：

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

如您所見，伺服器響應導航請求返回應用程式 UI 的描述，但它也返回用於組成該 UI 的源資料，以及 UI 實現的完整副本，然後在客戶端啟動 . 只有在 bundle.js 完成載入和執行後，這個 UI 才會變成互動式。

從使用 SSR 再水化的真實網站收集的效能指標表明，應強烈建議不要使用它。 歸根結底，原因歸結為使用者體驗：最終很容易讓使用者陷入“恐怖谷”。

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

# Streaming server rendering and Progressive Rehydration

在過去的幾年中，伺服器渲染有了許多發展。

流式伺服器呈現允許您以塊的形式傳送 HTML，瀏覽器可以在接收到時逐步呈現這些 HTML。這可以提供快速的首次繪製和首次內容繪製，因為標記更快地到達使用者手中。在 React 中，流在 renderToNodeStream() 中是非同步的——與同步 renderToString 相比——意味著 backpressure 得到了很好的處理。

漸進式 rehydration 也值得關注，這是 React 一直在探索的東西。使用這種方法，伺服器渲染的應用程式的各個部分會隨著時間的推移而“啟動”，而不是當前一次初始化整個應用程式的常用方法。這有助於減少使頁面具有互動性所需的 JavaScript 量，因為可以推遲頁面低優先順序部分的客戶端升級以防止阻塞主執行緒。它還可以幫助避免最常見的 SSR Rehydration 陷阱之一，其中伺服器渲染的 DOM 樹被破壞然後立即重建——通常是因為初始同步客戶端渲染需要尚未準備好的資料，可能正在等待 Promise解析度。

# SEO Considerations

在選擇在 Web 上呈現的策略時，團隊通常會考慮 SEO 的影響。 通常選擇伺服器渲染來提供爬蟲可以輕鬆解釋的“完整外觀”體驗。 爬蟲可能理解 JavaScript，但在它們的呈現方式中通常有一些值得關注的侷限性。 客戶端渲染可以工作，但通常需要額外的測試和工作。 如果您的架構很大程度上由客戶端 JavaScript 驅動，那麼最近動態渲染也成為一個值得考慮的選項。

如有疑問，[Mobile Friendly](https://search.google.com/test/mobile-friendly) 測試工具對於測試您選擇的方法是否符合您的期望非常有用。 它顯示了任何頁面在 Google 抓取工具中的顯示方式、找到的序列化 HTML 內容（在執行 JavaScript 之後）以及呈現期間遇到的任何錯誤的視覺預覽。

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

# 總結

在決定渲染方法時，測量並瞭解您的瓶頸是什麼。 考慮靜態渲染或伺服器渲染是否可以讓您完成 90% 的工作。 使用最少的 JS 來主要釋出 HTML 以獲得互動體驗是完全可以的。 這是一個方便的資訊圖，顯示了伺服器 - 客戶端範圍：

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

Web 應用伺服器端渲染入門指南

相關文章