原文鏈接

The Web Page Rendering Dilemma

關于網頁渲染的討論是最近幾年才出現的。早些時候，網站和網絡應用程序有一個共同的策略要遵循。他們準備了要發送到服務器端瀏覽器的 HTML 內容；然后在瀏覽器中將該內容呈現為帶有 CSS 樣式的 HTML。

JavaScript 框架采用了一種完全不同的 Web 開發方法。 JavaScript 框架帶來了減輕服務器負擔的可能性。

借助 JavaScript 框架的強大功能，可以通過僅請求所需的內容來直接從瀏覽器呈現動態內容。在這種情況下，服務器只提供必要的基本 HTML 包裝器。這種轉換為訪問者提供了無縫的用戶體驗，因為加載網頁所需的時間很少。此外，一旦加載，網頁就不會再次重新加載。

在本文中，我們將討論這些技術上不同的網頁渲染方法。 我將解釋每種方法之間的主要區別，并為您建議一種方法。

服務器端渲染

服務器端渲染或 SSR 是在瀏覽器上渲染網頁的傳統方式。 如上所述，呈現動態網頁內容的傳統方式遵循以下步驟：

• 用戶向網站發送請求（通常通過瀏覽器）
• 服務器在遍歷頁面內的服務器端腳本后檢查資源、編譯和準備 HTML 內容。
• 這個編譯后的 HTML 被發送到客戶端的瀏覽器以進行進一步的渲染和顯示。
• 瀏覽器下載 HTML 并使網站對最終用戶可見
• 瀏覽器然后下載 Javascript (JS) 并在執行 JS 時使頁面具有交互性

注意，在服務器端渲染的第二個步驟，客戶可以瀏覽從服務器發送過來的靜態頁面，但是無法互動，因為 JavaScript 尚未下載到客戶端。

在這個過程中，獲取動態內容、將其轉換為 HTML 并將其發送到瀏覽器的所有負擔都在服務器上。 因此，此過程稱為服務器端渲染 (SSR)。提前渲染完整 HTML 的責任伴隨著服務器的內存和處理能力的負擔。 與沒有動態內容要呈現的靜態站點的頁面加載時間相比，這會增加頁面加載時間。

客戶端渲染

客戶端呈現或 CSR 是處理網頁以在瀏覽器中顯示的不同方法。在 CSR 中，編譯動態內容并為它們生成 HTML 的負擔轉移到客戶端的瀏覽器。

這種方法由 JavaScript 框架和 ReactJS、VueJS 和 Angular 等庫提供支持。 客戶端渲染場景的正常網頁渲染流程遵循以下步驟：

• 用戶向網站發送請求（通常通過瀏覽器）。

• 可以使用 CDN（內容交付網絡）代替服務器來為用戶提供靜態 HTML、CSS 和支持文件。

• 瀏覽器先下載 HTML，然后再下載 JS。 同時，用戶會看到一個加載符號。

• 瀏覽器獲取 JS 后，通過 AJAX 發出 API 請求以獲取動態內容并對其進行處理以呈現最終內容。

• 服務器響應后，在客戶端瀏覽器中使用 DOM 處理呈現最終內容。

在 CSR 渲染的第三步，用戶只能看到一個空白的屏幕。

由于此過程涉及在客戶端獲取和處理數據，因此該過程稱為客戶端渲染。

兩種渲染模式的對比

由于這兩種方法處理內容的方式不同，因此每種方法都有其優點。讓我們從用戶和 Web 的角度比較 CSR 與 SSR。

web page 加載時間

網頁加載時間是從請求被發送到服務器到它在瀏覽器上呈現之間所花費的時間。 當涉及到您的網站或 Web 應用程序的用戶體驗 (UX) 時，這是一個重要方面。 CSR 和 SSR 的網頁加載時間在兩種情況下是不同的：

首頁加載時間

第一頁加載時間是用戶第一次加載您的網站所用的平均時間。 在首次加載時，在 CSR 中，瀏覽器一次加載基本 HTML、CSS 和所有所需的腳本，然后將 HTML 編譯為瀏覽器上可用的內容。

這一次通常不僅僅是從服務器獲取預編譯的 HTML 和相應的腳本。因此，當涉及到第一頁加載時間時，SSR 通常需要更少的時間。

接下來頁面的加載時間

第二個頁面加載時間是從一個頁面導航到另一個頁面所花費的平均時間。 在這種情況下，由于 CSR 的所有支持腳本都是提前加載的，因此 CSR 的加載時間更快。 除非需要加載惰性 JavaScript 模塊，否則它不會向服務器發送請求。

但是，對于 SSR，在第一頁加載中遵循的完整請求周期是重復的。 這意味著 SSR 對網頁加載時間幾乎沒有任何影響。 因此，在這種情況下，CSR 響應更快。

這里需要注意的是，上述推論并未深入考慮網絡方面。 我們相信客戶端和服務器在網絡上具有相當的帶寬。

對緩存的影響

為了加速繁重的 web 應用程序，每個瀏覽器和 web 服務器都采用緩存機制來緩存客戶端機器上的可重用腳本。 這改善了 CSR 和 SSR 的加載時間。 然而，CSR 有一個主要的好處。

在 CSR 中，只要不需要延遲加載模塊，基于 CSR 的 Web 應用程序也可以在沒有互聯網的情況下運行（除非您調用數據 API）。 加載后，應用程序不再需要向服務器發送請求。這允許瀏覽 Web 應用程序，就像一個簡單的桌面應用程序。

然而，在 SSR 中，總是向服務器發送請求。 因此，與 CSR 相比，SSR 的頁面加載時間無疑更長。緩存確實提高了 SSR 的內容渲染速度，因為瀏覽器需要從緩存中檢索必要的腳本。下圖描述了瀏覽器如何處理對緩存腳本的重復請求：

請注意，大多數腳本是從內存或磁盤加載的。 這大大縮短了加載時間并防止了服務器上的過度負載。

如何選擇合適的渲染方案

Dynamic Content Loading

服務器通常駐留在具有更高計算能力和顯著更高網絡速度的機器上。 憑借這種速度和能力，它在處理預期數量的處理請求時永遠不會耗盡資源。 結果，在服務器上獲取內容變得相對更快。

另一方面，客戶端計算機的計算能力有限，在客戶端獲取和呈現動態內容可能需要更長的時間。 這意味著獲取呈現的內容所消耗的總時間會更長。 因此，如果您的網站涉及重復的動態內容呈現，SSR 是比 CSR 更好的選擇。

Web Application UX vs Website UX

盡管它們看起來幾乎相同，但 Web 應用程序和網站是兩種不同的 Web 內容格式。 Web 應用程序是一個完整的應用程序，可用于會計、CRM、人力資源管理、項目管理等目的。另一方面，網站提供信息內容。

與網站相比，Web 應用程序涉及更多的用戶交互。 在用戶交互較高的場景中，確保用戶交互不會花費很長時間是至關重要的。 因此，與 SSR 相比，CSR 更適用于 Web 應用程序。

另一方面，對于網站，如果每次點擊都加載新網頁，對于客戶來說也能接受，因為緩存通常會負責加速渲染。 此外，SSR 還確保為爬蟲提供正確的元數據——與 CSR 相比，這使得 SSR 更適合網站。

結論

CSR 和 SSR 對于您計劃提供給用戶的 UX 至關重要。 我希望本文能幫助您從功能和實用的角度理解這些概念。 最終的選擇最終是你的。 考慮到上述因素，明智地選擇。 錯誤的選擇可能會讓您重新開發整個網站或 Web 應用程序。 正確的選擇可能會減少您將來的代碼管理工作。

更多Jerry的原創文章，盡在：“汪子熙”:

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Web 应用客户端渲染和服务器端渲染的比较的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。