在本文中，我們將探討 React 的起源、它解決了什麼問題以及
為什麼要建立 Next.js。雖然眾所周知Next.js 提供SSR（伺服器端渲染），但我們將深入探討SSR 真正是什麼 以及為什麼它可能比CSR（客戶端）側面渲染）在某些情況下。
在React.js普及CSR（客戶端渲染）概念之前，大多數應用程式都遵循傳統的MPA（多頁應用程式）模型。在 MPA 中，伺服器處理 HTML 的渲染，我們將看到這個過程既有優點也有缺點。
正如我們所看到的，渲染頁面很簡單。您向伺服器發送請求，需要一些時間來設定必要的 HTML，將其發送回來，然後頁面已加載。
那麼，問題出在哪裡呢？在這個階段，還沒有一個。事實上，這種方法看起來比 React.js 處理頁面載入的方式更有效——至少在最初是這樣。然而，當使用者開始與頁面互動時就會出現問題。讓我們來看看假設的場景：
這就是 React 試圖解決的問題
React 是如何解決這個問題的？
React 引入了客戶端渲染（CSR）的革命性概念。 CSR 不是在伺服器上呈現 HTML，而是在客戶端瀏覽器上呈現 HTML。
但是這是如何運作的？ ，考慮到當您第一次載入頁面時，伺服器仍然必須提供 HTML 服務？
發生的情況是這樣的：伺服器發送一個初始 HTML 框架，但它不包含實際內容。相反，它包含一個 <script>連結到捆綁的 JavaScript 程式碼的標籤。當 HTML 被載入時——<strong>發生得很快，因為它大部分是空的——React 接管，在客戶端上呈現實際內容。然而，內容並不能立即可用。 React 首先必須向伺服器發出<strong>單獨的請求以取得必要的資料。只有在此過程完成後，您才能看到完整的頁面。 </script>
如您所見，它比多頁面應用程式 (MPA) 中的傳統伺服器端渲染 (SSR) 稍微複雜一些。 事實上，一開始它可能看起來比較慢，因為它需要多次往返伺服器 - 首先是 HTML 框架，然後是 JavaScript 文件，最後是資料。這是 React 為接下來的魔法所接受的權衡之一。
現在，讓我們回到瀏覽器從 <script> 載入 JavaScript 的步驟。初始 HTML 中的標記。 React 實際上所做的是<strong>建立 DOM 的虛擬副本，稱為 <strong>虛擬 DOM (VDOM)。 React 使用此 VDOM 來<strong>有效地追蹤更改。 React 使用一個名為 <strong> 協調 .</script>
的過程，而不是每次發生變更時從伺服器重新渲染整個 HTML 頁面。React 將 DOM 的當前狀態 與其 虛擬副本 進行比較，以準確找出發生更改的位置。然後，它僅更新 DOM 中已更改的部分，而不是重新載入整個頁面。
現在，太棒了！ React 解決了這個問題，它允許您追蹤 DOM 中的更改，並且僅更新已更改的部分（所有都在客戶端），而無需多次訪問伺服器。
但是，這個解決方案需要一些權衡：
客戶端資源使用：客戶端電腦現在負責渲染 HTML、建立虛擬 DOM 並處理協調過程。這可能非常耗時，尤其是對於大型樹結構。
機器人和爬蟲的可見性有限：機器人和爬蟲（例如來自Facebook、X（以前稱為Twitter）或Instagram 的機器人和爬蟲）可能難以解析純客戶端渲染應用程式中的內容。發生這種情況是因為這些機器人通常不會執行 JavaScript，這意味著它們只能看到伺服器發送的初始 HTML，該 HTML 通常為空白或填充量最少。 如果內容嚴重依賴客戶端渲染，這可能會影響 SEO 或社群媒體分享。
這裡的關鍵挑戰是平衡客戶端互動性和伺服器端效率。假設我們可以傳回讓伺服器渲染初始 HTML（包含必要的資料），同時仍利用 React 的協調和虛擬 DOM 功能進行客戶端更新。那樣的話，我們就兩全其美了。
如果有一個框架就好了...
這就是 伺服器端渲染 (SSR) 和 Next.js 等框架發揮作用的地方。 Next.js 允許開發人員首先在伺服器上渲染頁面，確保初始 HTML 包含使用者需要的所有數據，從而提高效能和SEO。將這個初始伺服器渲染頁面傳送到客戶端後，您將獲得完整的 HTML 內容，但該頁面還不是互動的 - React 尚未載入。一旦 JavaScript 加載，React 就會經歷水合過程。
Hydration 是指React 接管客戶端預先渲染的HTML，透過React 的虛擬DOM 和協調 流程實現流暢的互動和更新.
以上是從 PreReact 到 React 和 Next.js Web 渲染和效能最佳化之旅的詳細內容。更多資訊請關注PHP中文網其他相關文章！
