Rendering on the Web

作為開發(fā)人員，我們經(jīng)常面臨會(huì)影響應(yīng)用程序整個(gè)架構(gòu)的決策。 Web 開發(fā)人員必須做出的核心決策之一是在他們的應(yīng)用程序中實(shí)現(xiàn)邏輯和呈現(xiàn)的位置。 這可能很困難，因?yàn)橛性S多不同的方法來構(gòu)建網(wǎng)站。

我們對(duì)這一領(lǐng)域的理解源于我們過去幾年在 Chrome 中與大型網(wǎng)站的交流工作。 從廣義上講，我們鼓勵(lì)開發(fā)人員考慮服務(wù)器渲染或靜態(tài)渲染，而不是完全重新 hydration 的方法。

為了更好地理解我們?cè)谧龀鲞@個(gè)決定時(shí)選擇的架構(gòu)，我們需要對(duì)每種方法和在談?wù)撍鼈儠r(shí)使用的一致術(shù)語(yǔ)有深刻的理解。 這些方法之間的差異有助于從性能的角度說明在 Web 上渲染的權(quán)衡。

渲染

• SSR：服務(wù)器端渲染 - 在服務(wù)器上將客戶端或通用應(yīng)用程序渲染為 HTML。

• CSR：客戶端渲染 - 在瀏覽器中渲染應(yīng)用程序，通常使用 DOM。

• Rehydration：在客戶端“啟動(dòng)”JavaScript 視圖，以便它們重用服務(wù)器渲染的 HTML 的 DOM 樹和數(shù)據(jù)。

• Prerendering：在構(gòu)建時(shí)運(yùn)行客戶端應(yīng)用程序以將其初始狀態(tài)捕獲為靜態(tài) HTML。

• TTFB：Time to First Byte - 被視為單擊鏈接和第一個(gè)內(nèi)容進(jìn)入之間的時(shí)間。

• FP：First Paint - 任何像素第一次對(duì)用戶可見。

• FCP：First Contentful Paint - 請(qǐng)求的內(nèi)容（文章正文等）變得可見的時(shí)間。

• TTI: Time To Interactive - 頁(yè)面變?yōu)榭山换サ臅r(shí)間（事件連接等）。

Server Rendering

服務(wù)器渲染為服務(wù)器上的頁(yè)面生成完整的 HTML 以響應(yīng)導(dǎo)航。 這避免了在客戶端上進(jìn)行數(shù)據(jù)獲取和模板化的額外往返，因?yàn)樗窃跒g覽器獲得響應(yīng)之前處理的。

服務(wù)器渲染通常會(huì)產(chǎn)生快速的首次繪制 (FP) 和首次內(nèi)容繪制 (FCP)。 在服務(wù)器上運(yùn)行頁(yè)面邏輯和渲染可以避免向客戶端發(fā)送大量 JavaScript，這有助于實(shí)現(xiàn)快速交互時(shí)間 (TTI)。 這是有道理的，因?yàn)橥ㄟ^服務(wù)器渲染，您實(shí)際上只是向用戶的瀏覽器發(fā)送文本和鏈接。 這種方法可以很好地適用于各種設(shè)備和網(wǎng)絡(luò)條件，并開啟了有趣的瀏覽器優(yōu)化，例如流式文檔解析。

通過服務(wù)器渲染，用戶不太可能在使用您的網(wǎng)站之前等待 CPU 綁定的 JavaScript 處理。即使無法避免第三方 JS，使用服務(wù)器渲染來降低您自己的第一方 JS 成本也可以為您提供更多的“預(yù)算”。但是，這種方法有一個(gè)主要缺點(diǎn)：在服務(wù)器上生成頁(yè)面需要時(shí)間，這通常會(huì)導(dǎo)致首字節(jié)時(shí)間 (TTFB) 變慢。

服務(wù)器渲染是否足以滿足您的應(yīng)用程序在很大程度上取決于您正在構(gòu)建的體驗(yàn)類型。關(guān)于服務(wù)器渲染與客戶端渲染的正確應(yīng)用程序存在長(zhǎng)期爭(zhēng)論，但重要的是要記住，您可以選擇對(duì)某些頁(yè)面使用服務(wù)器渲染而不是其他頁(yè)面。一些網(wǎng)站已經(jīng)成功地采用了混合渲染技術(shù)。 Netflix 服務(wù)器呈現(xiàn)其相對(duì)靜態(tài)的登陸頁(yè)面，同時(shí)為交互密集型頁(yè)面預(yù)取 JS，為這些較重的客戶端呈現(xiàn)頁(yè)面提供更好的快速加載機(jī)會(huì)。

許多現(xiàn)代框架、庫(kù)和架構(gòu)使得在客戶端和服務(wù)器上呈現(xiàn)相同的應(yīng)用程序成為可能。這些技術(shù)可用于服務(wù)器渲染，但重要的是要注意渲染發(fā)生在服務(wù)器和客戶端的架構(gòu)是它們自己的解決方案類，具有非常不同的性能特征和權(quán)衡。 React 用戶可以使用 renderToString() 或基于它構(gòu)建的解決方案，例如 Next.js 進(jìn)行服務(wù)器渲染。 Vue 用戶可以查看 Vue 的服務(wù)器渲染指南或 Nuxt。 Angular 有 Universal framework.大多數(shù)流行的解決方案都采用某種形式的 hydration 作用，因此在選擇工具之前請(qǐng)注意使用的方法。

Static Rendering

靜態(tài)渲染發(fā)生在構(gòu)建時(shí)，并提供快速的首次繪制、首次內(nèi)容繪制和交互時(shí)間 - 假設(shè)客戶端 JS 的數(shù)量有限。 與服務(wù)器渲染不同，它還設(shè)法實(shí)現(xiàn)始終如一的快速首字節(jié)時(shí)間，因?yàn)轫?yè)面的 HTML 不必即時(shí)生成。 通常，靜態(tài)呈現(xiàn)意味著提前為每個(gè) URL 生成單獨(dú)的 HTML 文件。 通過提前生成 HTML 響應(yīng)，可以將靜態(tài)呈現(xiàn)器部署到多個(gè) CDN 以利用邊緣緩存。

靜態(tài)渲染的解決方案有各種形狀和大小。 Gatsby 之類的工具旨在讓開發(fā)人員感覺他們的應(yīng)用程序是動(dòng)態(tài)呈現(xiàn)的，而不是作為構(gòu)建步驟生成的。其他像 Jekyll 和 Metalsmith 這樣的公司擁抱它們的靜態(tài)特性，提供了一種更加模板驅(qū)動(dòng)的方法。

靜態(tài)呈現(xiàn)的缺點(diǎn)之一是必須為每個(gè)可能的 URL 生成單獨(dú)的 HTML 文件。如果您無法提前預(yù)測(cè)這些 URL 的內(nèi)容，或者對(duì)于具有大量獨(dú)特頁(yè)面的網(wǎng)站，這可能具有挑戰(zhàn)性甚至不可行。

React 用戶可能熟悉 Gatsby、Next.js 靜態(tài)導(dǎo)出或 Navi - 所有這些都可以方便地使用組件進(jìn)行創(chuàng)作。但是，了解靜態(tài)渲染和預(yù)渲染之間的區(qū)別很重要：靜態(tài)渲染頁(yè)面是交互式的，無需執(zhí)行大量客戶端 JS，而預(yù)渲染改進(jìn)了必須啟動(dòng)的單頁(yè)應(yīng)用程序的首次繪制或首次內(nèi)容繪制客戶端以使頁(yè)面真正具有交互性。

如果您不確定給定的解決方案是靜態(tài)渲染還是預(yù)渲染，請(qǐng)嘗試以下測(cè)試：禁用 JavaScript 并加載創(chuàng)建的網(wǎng)頁(yè)。對(duì)于靜態(tài)呈現(xiàn)的頁(yè)面，大多數(shù)功能在沒有啟用 JavaScript 的情況下仍然存在。對(duì)于預(yù)渲染頁(yè)面，可能仍然有一些基本功能，如鏈接，但大部分頁(yè)面將是惰性的。

另一個(gè)有用的測(cè)試是使用 Chrome DevTools 降低網(wǎng)絡(luò)速度，并觀察在頁(yè)面變?yōu)榭山换ブ耙严螺d了多少 JavaScript。預(yù)渲染通常需要更多的 JavaScript 才能獲得交互性，而且 JavaScript 往往比靜態(tài)渲染使用的漸進(jìn)增強(qiáng)方法更復(fù)雜。

Server Rendering vs Static Rendering

服務(wù)器渲染不是靈丹妙藥——它的動(dòng)態(tài)特性會(huì)帶來大量的計(jì)算開銷成本。許多服務(wù)器渲染解決方案不會(huì)提前刷新，可能會(huì)延遲 TTFB 或?qū)l(fā)送的數(shù)據(jù)加倍（例如，客戶端上的 JS 使用的內(nèi)聯(lián)狀態(tài)）。在 React 中，renderToString() 可能很慢，因?yàn)樗峭降暮蛦尉€程的。使服務(wù)器渲染“正確”可能涉及為組件緩存找到或構(gòu)建解決方案、管理內(nèi)存消耗、應(yīng)用記憶技術(shù)以及許多其他問題。您通常會(huì)多次處理/重建同一個(gè)應(yīng)用程序 - 一次在客戶端上，一次在服務(wù)器中。僅僅因?yàn)榉?wù)器渲染可以使某些東西更快地顯示出來并不突然意味著您要做的工作更少。

SSR 為每個(gè) URL 按需生成 HTML，但可能比僅提供靜態(tài)呈現(xiàn)的內(nèi)容慢。如果您可以進(jìn)行額外的工作，服務(wù)器渲染 + HTML 緩存可以大大減少服務(wù)器渲染時(shí)間。與靜態(tài)渲染相比，服務(wù)器渲染的優(yōu)勢(shì)在于能夠提取更多“實(shí)時(shí)”數(shù)據(jù)并響應(yīng)更完整的請(qǐng)求集。需要個(gè)性化的頁(yè)面是不能很好地與靜態(tài)呈現(xiàn)一起工作的請(qǐng)求類型的具體示例。

在構(gòu)建 PWA 時(shí)，服務(wù)器渲染也可以提供有趣的決策。使用全頁(yè)面 Service Worker 緩存還是僅服務(wù)器渲染單個(gè)內(nèi)容更好？

Client-Side Rendering (CSR)

客戶端渲染 (CSR) 是指使用 JavaScript 直接在瀏覽器中渲染頁(yè)面。 所有邏輯、數(shù)據(jù)獲取、模板和路由都在客戶端而不是服務(wù)器上處理。

對(duì)于移動(dòng)設(shè)備，客戶端渲染可能難以獲得并保持快速。 如果做最少的工作，保持緊張的 JavaScript 預(yù)算并以盡可能少的 RTT 交付價(jià)值，它可以接近純服務(wù)器渲染的性能。 使用 HTTP/2 服務(wù)器推送或 <link rel=preload> 可以更快地交付關(guān)鍵腳本和數(shù)據(jù)，這可以讓解析器更快地為您工作。 像 PRPL 這樣的模式值得評(píng)估，以確保初始和后續(xù)導(dǎo)航感覺即時(shí)。

客戶端渲染的主要缺點(diǎn)是所需的 JavaScript 量會(huì)隨著應(yīng)用程序的增長(zhǎng)而增長(zhǎng)。 添加新的 JavaScript 庫(kù)、polyfill 和第三方代碼后，這變得尤其困難，它們會(huì)爭(zhēng)奪處理能力，并且通常必須在呈現(xiàn)頁(yè)面內(nèi)容之前進(jìn)行處理。 使用依賴于大型 JavaScript 包的 CSR 構(gòu)建的體驗(yàn)應(yīng)該考慮積極的代碼拆分，并確保延遲加載 JavaScript——“只在需要時(shí)提供您需要的服務(wù)”。 對(duì)于交互性很少或沒有交互性的體驗(yàn)，服務(wù)器渲染可以代表這些問題的更具可擴(kuò)展性的解決方案。

對(duì)于構(gòu)建單頁(yè)應(yīng)用程序的人來說，識(shí)別大多數(shù)頁(yè)面共享的用戶界面的核心部分意味著您可以應(yīng)用應(yīng)用程序外殼緩存技術(shù)。 與服務(wù)工作者相結(jié)合，這可以顯著提高重復(fù)訪問時(shí)的感知性能。

Combining server rendering and CSR via rehydration

通常被稱為 Universal 渲染或簡(jiǎn)稱為“SSR”，這種方法試圖通過同時(shí)進(jìn)行客戶端渲染和服務(wù)器渲染之間的權(quán)衡來平衡。諸如整頁(yè)加載或重新加載之類的導(dǎo)航請(qǐng)求由將應(yīng)用程序呈現(xiàn)為 HTML 的服務(wù)器處理，然后用于呈現(xiàn)的 JavaScript 和數(shù)據(jù)被嵌入到生成的文檔中。如果仔細(xì)實(shí)施，這將實(shí)現(xiàn)快速的第一次內(nèi)容繪制，就像服務(wù)器渲染一樣，然后通過使用稱為（重新）Hydration 的技術(shù)在客戶端再次渲染來“拾取 Pick up”。這是一個(gè)新穎的解決方案，但它可能有一些相當(dāng)大的性能缺陷。

帶有再 hydration 的 SSR 的主要缺點(diǎn)是它會(huì)對(duì)交互時(shí)間產(chǎn)生顯著的負(fù)面影響，即使它改進(jìn)了 First Paint。 SSR 的頁(yè)面通常看起來像是在加載和交互，但在執(zhí)行客戶端 JS 并附加事件處理程序之前，它們實(shí)際上無法響應(yīng)輸入。在移動(dòng)設(shè)備上這可能需要幾秒鐘甚至幾分鐘的時(shí)間。

也許您自己也經(jīng)歷過這種情況 - 在看起來頁(yè)面已加載后的一段時(shí)間內(nèi)，單擊或點(diǎn)擊什么也沒做。這很快變得令人沮喪…“為什么什么都沒有發(fā)生？為什么我不能滾動(dòng)？”

A Rehydration Problem: One App for the Price of Two

Rehydration 問題通常比 JS 導(dǎo)致的延遲交互更糟糕。 為了讓客戶端 JavaScript 能夠準(zhǔn)確地“接收”服務(wù)器中斷的位置，而不必重新請(qǐng)求服務(wù)器用于呈現(xiàn)其 HTML 的所有數(shù)據(jù)，當(dāng)前的 SSR 解決方案通常將來自 UI 的響應(yīng)序列化 數(shù)據(jù)依賴項(xiàng)作為腳本標(biāo)簽寫入文檔。 生成的 HTML 文檔包含高度重復(fù)：

如您所見，服務(wù)器響應(yīng)導(dǎo)航請(qǐng)求返回應(yīng)用程序 UI 的描述，但它也返回用于組成該 UI 的源數(shù)據(jù)，以及 UI 實(shí)現(xiàn)的完整副本，然后在客戶端啟動(dòng) . 只有在 bundle.js 完成加載和執(zhí)行后，這個(gè) UI 才會(huì)變成交互式。

從使用 SSR 再水化的真實(shí)網(wǎng)站收集的性能指標(biāo)表明，應(yīng)強(qiáng)烈建議不要使用它。 歸根結(jié)底，原因歸結(jié)為用戶體驗(yàn)：最終很容易讓用戶陷入“恐怖谷”。

Streaming server rendering and Progressive Rehydration

在過去的幾年中，服務(wù)器渲染有了許多發(fā)展。

流式服務(wù)器呈現(xiàn)允許您以塊的形式發(fā)送 HTML，瀏覽器可以在接收到時(shí)逐步呈現(xiàn)這些 HTML。這可以提供快速的首次繪制和首次內(nèi)容繪制，因?yàn)闃?biāo)記更快地到達(dá)用戶手中。在 React 中，流在 renderToNodeStream() 中是異步的——與同步 renderToString 相比——意味著 backpressure 得到了很好的處理。

漸進(jìn)式 rehydration 也值得關(guān)注，這是 React 一直在探索的東西。使用這種方法，服務(wù)器渲染的應(yīng)用程序的各個(gè)部分會(huì)隨著時(shí)間的推移而“啟動(dòng)”，而不是當(dāng)前一次初始化整個(gè)應(yīng)用程序的常用方法。這有助于減少使頁(yè)面具有交互性所需的 JavaScript 量，因?yàn)榭梢酝七t頁(yè)面低優(yōu)先級(jí)部分的客戶端升級(jí)以防止阻塞主線程。它還可以幫助避免最常見的 SSR Rehydration 陷阱之一，其中服務(wù)器渲染的 DOM 樹被破壞然后立即重建——通常是因?yàn)槌跏纪娇蛻舳虽秩拘枰形礈?zhǔn)備好的數(shù)據(jù)，可能正在等待 Promise解析度。

SEO Considerations

在選擇在 Web 上呈現(xiàn)的策略時(shí)，團(tuán)隊(duì)通常會(huì)考慮 SEO 的影響。 通常選擇服務(wù)器渲染來提供爬蟲可以輕松解釋的“完整外觀”體驗(yàn)。 爬蟲可能理解 JavaScript，但在它們的呈現(xiàn)方式中通常有一些值得關(guān)注的局限性。 客戶端渲染可以工作，但通常需要額外的測(cè)試和工作。 如果您的架構(gòu)很大程度上由客戶端 JavaScript 驅(qū)動(dòng)，那么最近動(dòng)態(tài)渲染也成為一個(gè)值得考慮的選項(xiàng)。

如有疑問，Mobile Friendly 測(cè)試工具對(duì)于測(cè)試您選擇的方法是否符合您的期望非常有用。 它顯示了任何頁(yè)面在 Google 抓取工具中的顯示方式、找到的序列化 HTML 內(nèi)容（在執(zhí)行 JavaScript 之后）以及呈現(xiàn)期間遇到的任何錯(cuò)誤的視覺預(yù)覽。

總結(jié)

在決定渲染方法時(shí)，測(cè)量并了解您的瓶頸是什么。 考慮靜態(tài)渲染或服務(wù)器渲染是否可以讓您完成 90% 的工作。 使用最少的 JS 來主要發(fā)布 HTML 以獲得交互體驗(yàn)是完全可以的。 這是一個(gè)方便的信息圖，顯示了服務(wù)器 - 客戶端范圍：

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

以上是生活随笔為你收集整理的Web 应用服务器端渲染入门指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。