Web網頁渲染的幾種模式

譯文：Rendering on the Web
本文主要內容來源於對上文的翻譯，圖也來源於此，加上了一點平時工做的理解，英語渣、翻譯不是很準確，有條件的能夠直接閱讀上文連接。本文主要是本身在閱讀時作的筆記，供本身之後查看。

預備知識

幾種常見的模式：

• SSR: Server-Side Rendering - rendering a client-side or universal app to HTML on the server.
• CSR: Client-Side Rendering - rendering an app in a browser, generally using the DOM.
• Rehydration: 「booting up」 JavaScript views on the client such that they reuse the server-rendered HTML’s DOM tree and data.
• Prerendering: running a client-side application at build time to capture its initial state as static HTML.

在開啓渲染模式對比以前，瞭解幾個有意義的性能對比參數：

• TTFB: Time to First Byte - seen as the time between clicking a link and the first bit of content coming in.
• FP: First Paint - the first time any pixel gets becomes visible to the user.
• FCP: First Contentful Paint - the time when requested content (article body, etc) becomes visible.
• TTI: Time To Interactive - the time at which a page becomes interactive (events wired up, etc).

渲染模式

SSR 服務端渲染

Server-Side Rendering - 就是服務端渲染出HTML頁面，好比之前的JSP，PHP

除了TTFB會延長（服務端須要去準備相應的頁面數據），其餘三個性能參數都比較客觀；

優勢是更好的性能數據，客戶端壓力更小，利於SEO；缺點是對服務端性能要求更高，壓力較大；頁面切換沒法漸進式加載，每一個頁面都須要從新渲染，頁面切換時不能定義過渡動畫(間隔有白屏，Chrome 在同域名頁面跳轉時，有一個PLS優化，即延遲到下一個頁面FCP節點時開始下一個頁面的渲染)；

在2014年之前，更多網站是以SSR的形式，隨着前端職業化和JS技術的不斷髮展，純SSR正在逐漸淡出歷史舞臺。

Static Rendering 靜態頁面渲染(古老的客戶端渲染方式)

靜態渲染就是直接用已經成型的html文件進行渲染，會有一些輔助的JS來加強頁面交互；好比Hexo模板引擎生成的文章Html，固然不少公司也還存在頁面內容純手工的作法，這種渲染適合交互少的一些官方展現性網站;

靜態渲染的優勢：

• 性能參數都比較優異，TTFB 和 FP 和 FCP幾乎相同；
• 適合CDN部署；
• 客戶端與服務端壓力都比較小；

靜態渲染的缺點之一是必須爲每一個可能的URL生成單獨的HTML文件。 當您沒法提早預測這些URL的URL或具備大量惟一頁面的網站時，這可能具備挑戰性甚至不可行, 若是是純手工開發，那開發效率相對也比較低。

但從工做幾年的經驗來看，這種純靜態渲染的網站除了一些文檔，博客類網站，更可能是藉助JS技術來提升頁面的可交互能力。

靜態渲染與SSR渲染（或則服務端預渲染）很像，能夠經過禁用js 和 下降網速來甄別網站是採用的靜態渲染技術仍是預渲染技術；

CSR 客戶端渲染

Client-side rendering (CSR) ，一種純在客戶端(瀏覽器)利用JS操做Dom渲染頁面的方式. 全部的生成邏輯, 數據獲取, 模板 and 路由 都由瀏覽器而不是服務端來控制。

除了TTFB短，其餘都會被延長，能夠經過Http2的服務端推送與<link rel=preload>來提高FCP；

客戶端渲染是當前最流行的渲染模式，常以SPA單頁面應用的方式存在；由於有React，Vue, Angular這種熱門UI框架支持，加上Webpack的構建打包，開發效率相比前兩種方式高出不少,頁面可作不少複雜的交互操做與圖形渲染；

因爲JS和CSS的大小會影響首屏的渲染，因此最好作好代碼分割，只提供頁面渲染必要的資源代碼，應用懶加載的形式來提供其他的資源時很是有必要的；

骨架屏渲染(CSR with Prerendering)在當代也是一種比較時髦的技術
，GatsBy引擎就是這種技術的突出使用者。就是會先經過服務端渲染出一個大體的骨架，告訴用戶網站已經對你的請求有響應了，但其實這個時候只能看到一個很模糊的佈局且不能交互，得等到頁面數據請求回來後，頁面纔開始正式的渲染。

Rehydration 同構渲染

同構其實就是SSR+CSR的合體。首屏的html頁面由服務端提供，而後加載js，js利用現有的dom樹來接管渲染後頁面的交互操做，跳轉到新頁面時就變成純CSR渲染，是一種比較有技術含量的渲染方式，當下比較流行的NextJs(React), NuxtJs(Vue)就是這種渲染技術的成熟框架；

從上圖可看，TTFB，FP和SSR幾乎同樣，FCP會因爲js的下載解析變長。頁面看起來很快被渲染出來(直出)，且看起可交互，但實際上這時候還不能立刻響應時間，由於要等到客戶端JS執行，事件監聽啓動後，輸入這些交互操做纔可用，因此TTI相比SSR也會變長。

優勢：利於SEO，同時結合了SSR與CSR的特色，首屏以後的頁面交互可實現漸進式加載，可控性高；
缺點：

• 技術要求更高（包含代碼處理），同時對服務器和客戶端都有性能要求；
• React過去提供的服務端html生成方法renderToString是同步的，這回阻塞Node服務主線程；但後面推出了異步的renderToNodeStream，服務端壓力相對而言就沒那麼大了

我本身在公司的兩個項目作過同構嘗試，都是基於Dva的React 同構渲染項目，感興趣的話，可做爲參考入門。

• 文章：初探SSR，React + Koa + Dva-Core
• 項目：SSrTemplate

對於同構渲染能夠優化的點，本身的總結是：

• JS，CSS等頁面靜態資源文件，最好仍是單獨部署走CDN；
• 交互JS 在頁面交互要求不高的狀況下，能夠設置async或則deffer標誌

其餘

沒咋理解，想了解最好看原文

• Partial Rehydration 部分同構渲染：顧名思義就是頁面的部分組件或試圖採用漸進式同構的方式加載，主要目的是減小頁面對客戶端JS的依賴；
• Trisomorphic Rendering，三態渲染：這種渲染技術僅適用於service workers可用的時候，大體意思是，首先由服務端提供一個初始文件流，而後service workers接管將文件流渲染出一個html文件，並開始在頁面渲染，同時服務端也在生成可用的頁面；下圖是其提供的思路：

貼出原文：
If service workers are an option for you, 「trisomorphic」 rendering may also be of interest. It's a technique where you can use streaming server rendering for initial/non-JS navigations, and then have your service worker take on rendering of HTML for navigations after it has been installed. This can keep cached components and templates up to date and enables SPA-style navigations for rendering new views in the same session. This approach works best when you can share the same templating and routing code between the server, client page, and service worker

總結

在決定渲染方法時，請思考並瞭解您應用的瓶頸在哪；考慮靜態渲染仍是服務器渲染是否能夠幫助您達到90％的效果；徹底能夠以最少的JS來配合HTML來得到交互體驗也是徹底能夠的，下面是一個全文總結性的圖表：

首發於個人博客：Web網頁渲染的幾種模式，轉載請註明