資訊專欄INFORMATION COLUMN
摘要：在服務器端運行頁面邏輯和渲染，使之避免了因此而發送大量的給客戶端。許多現代瀏覽器，類庫和架構使得在客戶端和服務器端渲染同一個應用程序成為可能。通常來說，靜態渲染意味著會提前對每一個生成一個多帶帶的文件。
作為開發者，我們經常會面臨一些影響我們整個網站結構的決定，其中web開發者一定要做的核心決定之一就是在應用程序中實現邏輯和渲染的位置。這可能比較難，因為有很多不同的方式來構建一個網站。
我們在這一領域的了解主要來源于在過去的幾年在Chrome工作期間，一直與一些大的網站的交流得來的。從廣義上來講，我們鼓勵開發人員去通過完全rehydration方法進行服務端渲染或者是靜態渲染。
為了更好的理解我們所選擇的技術架構，我們需要對每種方法有一種扎實的理解，并且在談論時要使用一致的術語。這些方式的不同點有助于我們說明通過性能和渲染之間尋求一個平衡。
術語 渲染SSR: Server-Side Rendering - 在服務器端渲染內容的方式。
CSR: Client-Side Rendering - 通常在瀏覽器中使用DOM來渲染應用程序的過程。
Rehydration: 在客戶端“啟動”Javascript視圖，使得他們能夠重用服務器端渲染的html的dom樹和數據。
Prerendering: 在構建時運行客戶端應用程序來使用其初始狀態作為靜態的html頁面。
性能TTFB: Time to First Byte - 點擊一個鏈接到返回的第一個字節數據所用的時間。
FP: First Paint - 首次任何像素對用戶可見的時間（也就是首先將像素繪制到屏幕的時刻）。
FCP: First Contentful Paint - 首次內容對用戶可見的時間（也就是瀏覽器將第一個 DOM 渲染到屏幕的時間）。
TTI: Time To Interactive - 頁面變為可交互的時間。
服務器端渲染服務器端渲染會在服務器上生成整個的HTML頁面，然后整體返回給瀏覽器。由于它在返回給瀏覽器之前就已經處理好了，所以會避免客戶端在數據獲取和模板化的額外開銷。
服務器渲染很快就會產生First Paint（FP）和First Contentful Paint（FCP）。在服務器端運行頁面邏輯和渲染，使之避免了因此而發送大量的Javascript給客戶端。也會有助于我們實現一個快速的Time To Interactive（TTI）。這是可能的，因為在服務器端渲染的話，你僅僅需要發送文本和鏈接給瀏覽器。這種方式在大范圍的設備和網絡環境下都會很好的運行，與此同時也會提起你對瀏覽器優化的興趣，比如說流文檔解析。
通過服務器端渲染，用戶不太可能等待CPU綁定的javascript處理完畢之后才能去使用您的站點。即使是第三方js不可避免。使用服務器端渲染也會減少你的js開銷，會給您處理其他事情留有更多的“預算”。然而，這種方式有一個主要的缺點：在服務器端生成頁面會減慢你的Time To First Byte（TTFB）。
服務器端渲染對于你的應用程序是否夠用，很大一部分依賴于你個人的構建經驗。在服務器端渲染和客戶端渲染哪一個更好這個爭論曾經持續了很長時間。但是要記住很重要的一點，你可以在一些頁面中使用服務器端渲染，而不是全部都用。一些網站已經成功使用了混合渲染技術，Netflix在服務器端渲染，呈現其相對于靜態的頁面，同時為交互繁重的頁面預取js，給這些較重的客戶端頁面提供一個更快的加載機會。
許多現代瀏覽器，類庫和架構使得在客戶端和服務器端渲染同一個應用程序成為可能。這些技術可以被用于服務器端渲染，然而，重要的是注意在客戶端和服務器端渲染的架構都有他們不同的解決方案，具有非常不同的性能特征和權衡。React用戶可以使用renderToString()或者是在其之上的解決方案來實現服務器端渲染，比如說Next.js。Vue用戶可以查閱Vue的server rendering guide或者是Nuxt。Angular有Universal。最流行的解決方案會采用某些形式的hydration。在選擇一個工具之前要注意使用的方法。
靜態渲染靜態渲染在構建時發生，會提供一個很快的First Paint，First Contentful Paint， Time To Interactive - 假設客戶端js是有限的。跟服務器端渲染區別之一是它會設法實現一個始終如一的快速的Time To First Byte，因為HTML頁面不必動態生成。通常來說，靜態渲染意味著會提前對每一個URL生成一個多帶帶的HTML文件。由于預先生成了HTML的響應，所以靜態渲染可以部署在多個CDN來用于邊緣緩存。
靜態渲染的解決方案多種多樣，像Gatsby這樣的工具，開發者會感覺他們的應用程序是動態渲染的，而不是作為構建時生成的。而像Jekly和Metalsmith則會擁抱他們的靜態生態系統，提供更多模板驅動的方法。
靜態渲染的缺點之一就是要為每一個可能的URL多帶帶生成一個HTML文件，當你不能提前預知這些URL都有什么，或者網站有非常多的唯一頁面的時候，這或許是一個挑戰，又或者是不可能實現的。
React用戶可能很熟悉Gatsby，Next.js，static export或者是Navi - 他們都使得作者使用組件變得很方便。然而，重要的是理解靜態渲染和預渲染的不同點：靜態渲染頁面是可交互的，不需要執行太多的客戶端的js，而預渲染則會提升單頁應用的First Paint或者是First Contentful Paint，為了讓頁面變為真正的可交互其一定要在客戶端啟動。
如果你不確定給定的解決方案是靜態渲染，還是預渲染，嘗試下如下測試：禁用Javascript，加載已經創建好的頁面。對于靜態渲染頁面，如果不啟用Javascript，大部分功能依然存在。而對于預渲染頁面，可能依然有一些基本的功能可以使用，比如說超鏈接，但是大部分頁面將會是惰性的。
另一個有用的測試是使用Chrome DevTool降低你的網絡帶寬，觀察頁面變為可交互之前Javascript已經下載的數量。預渲染通常需要更多的Javascript來使頁面變的可交互，并且Javascript要比靜態渲染使用的漸進增強方法要更復雜。
服務器端渲染 vs 靜態渲染服務器端渲染并不是靈丹妙藥 - 它的動態特性會帶來明顯的計算性能開銷。許多服務器端渲染解決方案都不會提早刷新，可能會導致延遲TTFB或者是發送的數據量加倍。在React中，renderToString()可能是很慢的，因為它是同步并且是單線程的。要使得服務器渲染“正確”可能會涉及查找或者構建一個組件緩存的解決方案，管理內存消耗，等等。你通常會多次處理/重新構建相同的應用程序 - 一次在客戶端，一次在服務器端。僅僅是因為服務器端渲染可以使某些東西更快顯示，但并不是突然意味著會減少你的工作量。
服務器端渲染可以按需要為每個URL生成對應的HTML，但是它卻慢于靜態渲染的內容。如果你可以進行一些額外的工作，那么服務器端渲染 + HTML緩存可以極大的減少服務器渲染的時間。服務器端渲染的優點是有能力獲取更多“實時”的數據并且返回比靜態渲染更加完整的結果集，個性化的頁面是服務器渲染的一個具體的事例，不過這種對于靜態渲染來說，就不太適合了。
在構建PWA的時候，服務器端渲染也可以提出一些有有趣的決策。所以是全頁server worker更好，還是用服務器渲染僅僅渲染多帶帶的內容片段更好呢？
本文翻譯自：
https://developers.google.com...
本文轉載自http://www.lht.ren/article/13/
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/101573.html
摘要：于是后來業界開始探索依舊利用技術棧開發出媲美原生體驗的方案，于是以為代表云原生開發框架開始出現。依舊采取傳統的開發技術棧進行開發，同時在終端的運行體驗不輸。其同時解決了開發效率發版速度以及用戶體驗三個核心問題。 摘要： WEEX依舊采取傳統的web開發技術棧進行開發，同時app在終端的運行體驗不輸native app。其同時解決了開發效率、發版速度以及用戶體驗三個核心問題。那么WEEX...
摘要：然而這些代碼也會競爭系統的處理能力，因此在頁面內容被渲染完成之前，必須要經常處理一些東西。注意事項當在網站上選擇渲染策略時，團隊通常會考慮的影響。它顯示了抓取工具顯示任何頁面的方式預覽，找到的序列化內容執行后以及渲染過程中遇到的任何錯誤。 客戶端渲染（CSR） 客戶端渲染意味著在瀏覽器中使用Javascript直接渲染頁面。所有的邏輯，數據獲取，模板和路由都在客戶端處理。 對于移動設備...
閱讀 1972·2021-11-25 09:43
閱讀 653·2021-10-11 10:58
閱讀 1730·2019-08-30 15:55
閱讀 1725·2019-08-30 13:13
閱讀 736·2019-08-29 17:01
閱讀 1840·2019-08-29 15:30
閱讀 789·2019-08-29 13:49
閱讀 2172·2019-08-29 12:13
