摘要：在服務(wù)器端運行頁面邏輯和渲染，使之避免了因此而發(fā)送大量的給客戶端。許多現(xiàn)代瀏覽器，類庫和架構(gòu)使得在客戶端和服務(wù)器端渲染同一個應(yīng)用程序成為可能。通常來說，靜態(tài)渲染意味著會提前對每一個生成一個多帶帶的文件。

作為開發(fā)者，我們經(jīng)常會面臨一些影響我們整個網(wǎng)站結(jié)構(gòu)的決定，其中web開發(fā)者一定要做的核心決定之一就是在應(yīng)用程序中實現(xiàn)邏輯和渲染的位置。這可能比較難，因為有很多不同的方式來構(gòu)建一個網(wǎng)站。

我們在這一領(lǐng)域的了解主要來源于在過去的幾年在Chrome工作期間，一直與一些大的網(wǎng)站的交流得來的。從廣義上來講，我們鼓勵開發(fā)人員去通過完全rehydration方法進(jìn)行服務(wù)端渲染或者是靜態(tài)渲染。

為了更好的理解我們所選擇的技術(shù)架構(gòu)，我們需要對每種方法有一種扎實的理解，并且在談?wù)摃r要使用一致的術(shù)語。這些方式的不同點有助于我們說明通過性能和渲染之間尋求一個平衡。

SSR: Server-Side Rendering - 在服務(wù)器端渲染內(nèi)容的方式。

CSR: Client-Side Rendering - 通常在瀏覽器中使用DOM來渲染應(yīng)用程序的過程。

Rehydration: 在客戶端“啟動”Javascript視圖，使得他們能夠重用服務(wù)器端渲染的html的dom樹和數(shù)據(jù)。

Prerendering: 在構(gòu)建時運行客戶端應(yīng)用程序來使用其初始狀態(tài)作為靜態(tài)的html頁面。

TTFB: Time to First Byte - 點擊一個鏈接到返回的第一個字節(jié)數(shù)據(jù)所用的時間。

FP: First Paint - 首次任何像素對用戶可見的時間（也就是首先將像素繪制到屏幕的時刻）。

FCP: First Contentful Paint - 首次內(nèi)容對用戶可見的時間（也就是瀏覽器將第一個 DOM 渲染到屏幕的時間）。

TTI: Time To Interactive - 頁面變?yōu)榭山换サ臅r間。

服務(wù)器端渲染會在服務(wù)器上生成整個的HTML頁面，然后整體返回給瀏覽器。由于它在返回給瀏覽器之前就已經(jīng)處理好了，所以會避免客戶端在數(shù)據(jù)獲取和模板化的額外開銷。

服務(wù)器渲染很快就會產(chǎn)生First Paint（FP）和First Contentful Paint（FCP）。在服務(wù)器端運行頁面邏輯和渲染，使之避免了因此而發(fā)送大量的Javascript給客戶端。也會有助于我們實現(xiàn)一個快速的Time To Interactive（TTI）。這是可能的，因為在服務(wù)器端渲染的話，你僅僅需要發(fā)送文本和鏈接給瀏覽器。這種方式在大范圍的設(shè)備和網(wǎng)絡(luò)環(huán)境下都會很好的運行，與此同時也會提起你對瀏覽器優(yōu)化的興趣，比如說流文檔解析。

通過服務(wù)器端渲染，用戶不太可能等待CPU綁定的javascript處理完畢之后才能去使用您的站點。即使是第三方j(luò)s不可避免。使用服務(wù)器端渲染也會減少你的js開銷，會給您處理其他事情留有更多的“預(yù)算”。然而，這種方式有一個主要的缺點：在服務(wù)器端生成頁面會減慢你的Time To First Byte（TTFB）。

服務(wù)器端渲染對于你的應(yīng)用程序是否夠用，很大一部分依賴于你個人的構(gòu)建經(jīng)驗。在服務(wù)器端渲染和客戶端渲染哪一個更好這個爭論曾經(jīng)持續(xù)了很長時間。但是要記住很重要的一點，你可以在一些頁面中使用服務(wù)器端渲染，而不是全部都用。一些網(wǎng)站已經(jīng)成功使用了混合渲染技術(shù)，Netflix在服務(wù)器端渲染，呈現(xiàn)其相對于靜態(tài)的頁面，同時為交互繁重的頁面預(yù)取js，給這些較重的客戶端頁面提供一個更快的加載機(jī)會。

許多現(xiàn)代瀏覽器，類庫和架構(gòu)使得在客戶端和服務(wù)器端渲染同一個應(yīng)用程序成為可能。這些技術(shù)可以被用于服務(wù)器端渲染，然而，重要的是注意在客戶端和服務(wù)器端渲染的架構(gòu)都有他們不同的解決方案，具有非常不同的性能特征和權(quán)衡。React用戶可以使用renderToString()或者是在其之上的解決方案來實現(xiàn)服務(wù)器端渲染，比如說Next.js。Vue用戶可以查閱Vue的server rendering guide或者是Nuxt。Angular有Universal。最流行的解決方案會采用某些形式的hydration。在選擇一個工具之前要注意使用的方法。

靜態(tài)渲染在構(gòu)建時發(fā)生，會提供一個很快的First Paint，F(xiàn)irst Contentful Paint， Time To Interactive - 假設(shè)客戶端js是有限的。跟服務(wù)器端渲染區(qū)別之一是它會設(shè)法實現(xiàn)一個始終如一的快速的Time To First Byte，因為HTML頁面不必動態(tài)生成。通常來說，靜態(tài)渲染意味著會提前對每一個URL生成一個多帶帶的HTML文件。由于預(yù)先生成了HTML的響應(yīng)，所以靜態(tài)渲染可以部署在多個CDN來用于邊緣緩存。

靜態(tài)渲染的解決方案多種多樣，像Gatsby這樣的工具，開發(fā)者會感覺他們的應(yīng)用程序是動態(tài)渲染的，而不是作為構(gòu)建時生成的。而像Jekly和Metalsmith則會擁抱他們的靜態(tài)生態(tài)系統(tǒng)，提供更多模板驅(qū)動的方法。

靜態(tài)渲染的缺點之一就是要為每一個可能的URL多帶帶生成一個HTML文件，當(dāng)你不能提前預(yù)知這些URL都有什么，或者網(wǎng)站有非常多的唯一頁面的時候，這或許是一個挑戰(zhàn)，又或者是不可能實現(xiàn)的。

React用戶可能很熟悉Gatsby，Next.js，static export或者是Navi - 他們都使得作者使用組件變得很方便。然而，重要的是理解靜態(tài)渲染和預(yù)渲染的不同點：靜態(tài)渲染頁面是可交互的，不需要執(zhí)行太多的客戶端的js，而預(yù)渲染則會提升單頁應(yīng)用的First Paint或者是First Contentful Paint，為了讓頁面變?yōu)檎嬲目山换テ湟欢ㄒ诳蛻舳藛印?/p>

如果你不確定給定的解決方案是靜態(tài)渲染，還是預(yù)渲染，嘗試下如下測試：禁用Javascript，加載已經(jīng)創(chuàng)建好的頁面。對于靜態(tài)渲染頁面，如果不啟用Javascript，大部分功能依然存在。而對于預(yù)渲染頁面，可能依然有一些基本的功能可以使用，比如說超鏈接，但是大部分頁面將會是惰性的。

另一個有用的測試是使用Chrome DevTool降低你的網(wǎng)絡(luò)帶寬，觀察頁面變?yōu)榭山换ブ癑avascript已經(jīng)下載的數(shù)量。預(yù)渲染通常需要更多的Javascript來使頁面變的可交互，并且Javascript要比靜態(tài)渲染使用的漸進(jìn)增強方法要更復(fù)雜。

服務(wù)器端渲染并不是靈丹妙藥 - 它的動態(tài)特性會帶來明顯的計算性能開銷。許多服務(wù)器端渲染解決方案都不會提早刷新，可能會導(dǎo)致延遲TTFB或者是發(fā)送的數(shù)據(jù)量加倍。在React中，renderToString()可能是很慢的，因為它是同步并且是單線程的。要使得服務(wù)器渲染“正確”可能會涉及查找或者構(gòu)建一個組件緩存的解決方案，管理內(nèi)存消耗，等等。你通常會多次處理/重新構(gòu)建相同的應(yīng)用程序 - 一次在客戶端，一次在服務(wù)器端。僅僅是因為服務(wù)器端渲染可以使某些東西更快顯示，但并不是突然意味著會減少你的工作量。

服務(wù)器端渲染可以按需要為每個URL生成對應(yīng)的HTML，但是它卻慢于靜態(tài)渲染的內(nèi)容。如果你可以進(jìn)行一些額外的工作，那么服務(wù)器端渲染 + HTML緩存可以極大的減少服務(wù)器渲染的時間。服務(wù)器端渲染的優(yōu)點是有能力獲取更多“實時”的數(shù)據(jù)并且返回比靜態(tài)渲染更加完整的結(jié)果集，個性化的頁面是服務(wù)器渲染的一個具體的事例，不過這種對于靜態(tài)渲染來說，就不太適合了。

在構(gòu)建PWA的時候，服務(wù)器端渲染也可以提出一些有有趣的決策。所以是全頁server worker更好，還是用服務(wù)器渲染僅僅渲染多帶帶的內(nèi)容片段更好呢？

本文翻譯自：

https://developers.google.com...

本文轉(zhuǎn)載自http://www.lht.ren/article/13/