Web 应用客户端渲染和服务器端渲染的比较
原文鏈接
The Web Page Rendering Dilemma
關(guān)于網(wǎng)頁渲染的討論是最近幾年才出現(xiàn)的。早些時候，網(wǎng)站和網(wǎng)絡應用程序有一個共同的策略要遵循。他們準備了要發(fā)送到服務器端瀏覽器的 HTML 內(nèi)容；然后在瀏覽器中將該內(nèi)容呈現(xiàn)為帶有 CSS 樣式的 HTML。
JavaScript 框架采用了一種完全不同的 Web 開發(fā)方法。 JavaScript 框架帶來了減輕服務器負擔的可能性。
借助 JavaScript 框架的強大功能，可以通過僅請求所需的內(nèi)容來直接從瀏覽器呈現(xiàn)動態(tài)內(nèi)容。在這種情況下，服務器只提供必要的基本 HTML 包裝器。這種轉(zhuǎn)換為訪問者提供了無縫的用戶體驗，因為加載網(wǎng)頁所需的時間很少。此外，一旦加載，網(wǎng)頁就不會再次重新加載。
在本文中，我們將討論這些技術(shù)上不同的網(wǎng)頁渲染方法。 我將解釋每種方法之間的主要區(qū)別，并為您建議一種方法。
服務器端渲染
服務器端渲染或 SSR 是在瀏覽器上渲染網(wǎng)頁的傳統(tǒng)方式。 如上所述，呈現(xiàn)動態(tài)網(wǎng)頁內(nèi)容的傳統(tǒng)方式遵循以下步驟：
- 用戶向網(wǎng)站發(fā)送請求（通常通過瀏覽器）
- 服務器在遍歷頁面內(nèi)的服務器端腳本后檢查資源、編譯和準備 HTML 內(nèi)容。
- 這個編譯后的 HTML 被發(fā)送到客戶端的瀏覽器以進行進一步的渲染和顯示。
- 瀏覽器下載 HTML 并使網(wǎng)站對最終用戶可見
- 瀏覽器然后下載 Javascript (JS) 并在執(zhí)行 JS 時使頁面具有交互性
注意，在服務器端渲染的第二個步驟，客戶可以瀏覽從服務器發(fā)送過來的靜態(tài)頁面，但是無法互動，因為 JavaScript 尚未下載到客戶端。
在這個過程中，獲取動態(tài)內(nèi)容、將其轉(zhuǎn)換為 HTML 并將其發(fā)送到瀏覽器的所有負擔都在服務器上。 因此，此過程稱為服務器端渲染 (SSR)。提前渲染完整 HTML 的責任伴隨著服務器的內(nèi)存和處理能力的負擔。 與沒有動態(tài)內(nèi)容要呈現(xiàn)的靜態(tài)站點的頁面加載時間相比，這會增加頁面加載時間。
客戶端渲染
客戶端呈現(xiàn)或 CSR 是處理網(wǎng)頁以在瀏覽器中顯示的不同方法。在 CSR 中，編譯動態(tài)內(nèi)容并為它們生成 HTML 的負擔轉(zhuǎn)移到客戶端的瀏覽器。
這種方法由 JavaScript 框架和 ReactJS、VueJS 和 Angular 等庫提供支持。 客戶端渲染場景的正常網(wǎng)頁渲染流程遵循以下步驟：
-
用戶向網(wǎng)站發(fā)送請求（通常通過瀏覽器）。
-
可以使用 CDN（內(nèi)容交付網(wǎng)絡）代替服務器來為用戶提供靜態(tài) HTML、CSS 和支持文件。
-
瀏覽器先下載 HTML，然后再下載 JS。 同時，用戶會看到一個加載符號。
-
瀏覽器獲取 JS 后，通過 AJAX 發(fā)出 API 請求以獲取動態(tài)內(nèi)容并對其進行處理以呈現(xiàn)最終內(nèi)容。
-
服務器響應后，在客戶端瀏覽器中使用 DOM 處理呈現(xiàn)最終內(nèi)容。
在 CSR 渲染的第三步，用戶只能看到一個空白的屏幕。
由于此過程涉及在客戶端獲取和處理數(shù)據(jù)，因此該過程稱為客戶端渲染。
兩種渲染模式的對比
由于這兩種方法處理內(nèi)容的方式不同，因此每種方法都有其優(yōu)點。讓我們從用戶和 Web 的角度比較 CSR 與 SSR。
web page 加載時間
網(wǎng)頁加載時間是從請求被發(fā)送到服務器到它在瀏覽器上呈現(xiàn)之間所花費的時間。 當涉及到您的網(wǎng)站或 Web 應用程序的用戶體驗 (UX) 時，這是一個重要方面。 CSR 和 SSR 的網(wǎng)頁加載時間在兩種情況下是不同的：
首頁加載時間
第一頁加載時間是用戶第一次加載您的網(wǎng)站所用的平均時間。 在首次加載時，在 CSR 中，瀏覽器一次加載基本 HTML、CSS 和所有所需的腳本，然后將 HTML 編譯為瀏覽器上可用的內(nèi)容。
這一次通常不僅僅是從服務器獲取預編譯的 HTML 和相應的腳本。因此，當涉及到第一頁加載時間時，SSR 通常需要更少的時間。
接下來頁面的加載時間
第二個頁面加載時間是從一個頁面導航到另一個頁面所花費的平均時間。 在這種情況下，由于 CSR 的所有支持腳本都是提前加載的，因此 CSR 的加載時間更快。 除非需要加載惰性 JavaScript 模塊，否則它不會向服務器發(fā)送請求。
但是，對于 SSR，在第一頁加載中遵循的完整請求周期是重復的。 這意味著 SSR 對網(wǎng)頁加載時間幾乎沒有任何影響。 因此，在這種情況下，CSR 響應更快。
這里需要注意的是，上述推論并未深入考慮網(wǎng)絡方面。 我們相信客戶端和服務器在網(wǎng)絡上具有相當?shù)膸挕?/p>
對緩存的影響
為了加速繁重的 web 應用程序，每個瀏覽器和 web 服務器都采用緩存機制來緩存客戶端機器上的可重用腳本。 這改善了 CSR 和 SSR 的加載時間。 然而，CSR 有一個主要的好處。
在 CSR 中，只要不需要延遲加載模塊，基于 CSR 的 Web 應用程序也可以在沒有互聯(lián)網(wǎng)的情況下運行（除非您調(diào)用數(shù)據(jù) API）。 加載后，應用程序不再需要向服務器發(fā)送請求。這允許瀏覽 Web 應用程序，就像一個簡單的桌面應用程序。
然而，在 SSR 中，總是向服務器發(fā)送請求。 因此，與 CSR 相比，SSR 的頁面加載時間無疑更長。緩存確實提高了 SSR 的內(nèi)容渲染速度，因為瀏覽器需要從緩存中檢索必要的腳本。下圖描述了瀏覽器如何處理對緩存腳本的重復請求：
請注意，大多數(shù)腳本是從內(nèi)存或磁盤加載的。 這大大縮短了加載時間并防止了服務器上的過度負載。
如何選擇合適的渲染方案
Dynamic Content Loading
服務器通常駐留在具有更高計算能力和顯著更高網(wǎng)絡速度的機器上。 憑借這種速度和能力，它在處理預期數(shù)量的處理請求時永遠不會耗盡資源。 結(jié)果，在服務器上獲取內(nèi)容變得相對更快。
另一方面，客戶端計算機的計算能力有限，在客戶端獲取和呈現(xiàn)動態(tài)內(nèi)容可能需要更長的時間。 這意味著獲取呈現(xiàn)的內(nèi)容所消耗的總時間會更長。 因此，如果您的網(wǎng)站涉及重復的動態(tài)內(nèi)容呈現(xiàn)，SSR 是比 CSR 更好的選擇。
Web Application UX vs Website UX
盡管它們看起來幾乎相同，但 Web 應用程序和網(wǎng)站是兩種不同的 Web 內(nèi)容格式。 Web 應用程序是一個完整的應用程序，可用于會計、CRM、人力資源管理、項目管理等目的。另一方面，網(wǎng)站提供信息內(nèi)容。
與網(wǎng)站相比，Web 應用程序涉及更多的用戶交互。 在用戶交互較高的場景中，確保用戶交互不會花費很長時間是至關(guān)重要的。 因此，與 SSR 相比，CSR 更適用于 Web 應用程序。
另一方面，對于網(wǎng)站，如果每次點擊都加載新網(wǎng)頁，對于客戶來說也能接受，因為緩存通常會負責加速渲染。 此外，SSR 還確保為爬蟲提供正確的元數(shù)據(jù)——與 CSR 相比，這使得 SSR 更適合網(wǎng)站。
結(jié)論
CSR 和 SSR 對于您計劃提供給用戶的 UX 至關(guān)重要。 我希望本文能幫助您從功能和實用的角度理解這些概念。 最終的選擇最終是你的。 考慮到上述因素，明智地選擇。 錯誤的選擇可能會讓您重新開發(fā)整個網(wǎng)站或 Web 應用程序。 正確的選擇可能會減少您將來的代碼管理工作。
更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:
總結(jié)
以上是生活随笔為你收集整理的Web 应用客户端渲染和服务器端渲染的比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 工商银行立减金怎么使用 怎么用工商银行的
- 下一篇： PCB常用单位转换 mil 英尺