原文連結

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的原創文章，盡在："汪子熙":