SSR（服務器端渲染）曾經被譽為解決單頁應用（SPA）在性能和 SEO 問題上的靈丹妙藥，而這正是一個快速發展的領域。

然而，在 2024 年，SSR 真的仍然是它通常被認為的那種萬全之策嗎？

在這篇文章中，我將討論為什么 SSR 可能被高估了，以及當代的工具和技術如何讓我們僅使用 CSR（客戶端渲染）就能實現同樣的目標。

什么是 SSR 以及我們為什么需要它？

服務器端渲染（SSR）指的是在服務器上渲染 Web 應用程序，而不是在客戶端進行渲染。

這意味著與當前的客戶端渲染不同，用戶請求頁面時，服務器不僅僅發送 HTML 信息并讓瀏覽器完成其余的頁面布局，而是服務器生成從 HTML 代碼到頁面布局的所有內容。

瀏覽器隨后完全渲染頁面，這種方式的優勢在于更快的初始加載時間和更好的搜索引擎優化（SEO）。

SSR 特別受歡迎的原因包括：

• 更快的初始加載：服務器向客戶端發送已完全渲染的頁面，因此用戶可以更快地查看內容。
• 改進的 SEO：由于內容在 HTML 負載的第一個字節中存在，搜索引擎能夠更輕松地抓取和索引內容。
• 更好的低性能設備表現：由于大部分工作在服務器上完成，幾乎任何低性能的設備都能在短時間內繪制頁面。

聽起來很棒，對吧？然而，和所有技術一樣：SSR 也有其優點和缺點。

SSR 的缺點

盡管 SSR 提供了顯著的優勢，但它并非沒有挑戰：

• 復雜性：正如我們之前提到的，SSR 的引入會使應用程序變得更加復雜。你需要處理服務器技術、緩存問題，以及可能的安全威脅，因為服務器端代碼可能會暴露。
• 性能瓶頸：服務器端渲染可能會導致性能問題。每個請求都需要服務器來構建頁面，當服務器負載過高時，這可能會成為問題。
• 開發開銷：使用 SSR 進行開發時，開發者需要在服務器端代碼和客戶端代碼之間來回切換，這可能會導致更長的開發周期和更高的維護成本。
• 用戶體驗：SSR 可能會導致用戶在瀏覽器通過客戶端 JavaScript 再次渲染頁面之前短暫地看到渲染的頁面。這有時會產生一種不連貫的感覺，尤其是在客戶端渲染的內容與服務器端渲染的內容差異較大時。

考慮到這些缺點，SSR 在 2024 年是否仍然必要？我認為不是。

為什么 SSR 不再必要

CSR 已經進化

客戶端渲染（CSR）已經取得了長足的進步。現代 JavaScript 框架如 React、Vue 和 Angular 在性能方面已經得到了極大的優化。

技術如代碼分割、懶加載和數據再水合（hydration）使得 CSR 比以前更加高效。

例如，通過 React 的 Suspense 和 React.lazy，你可以推遲應用程序的部分渲染，直到它們真正需要時，大大提高了感知性能。

用戶獲得了快速的初始加載，剩余內容則異步加載，不會阻塞主線程。

SEO 已經迎頭趕上

SSR 被廣泛采用的主要原因之一是 SEO。在過去，傳統搜索引擎，尤其是 Google，在索引基于 JavaScript 和 AJAX 的 SPA 時存在問題。

然而，搜索引擎現在已經大大提高了抓取和索引 JavaScript 渲染內容的能力。

例如，Googlebot 目前就像任何現代瀏覽器一樣運行，因此能夠抓取和索引 CSR 內容。

此外，還有 Prerender.io 和 Rendertron 這樣的工具可以為搜索引擎預渲染你的 SPA，給你帶來最佳的效果：CSR 的相對易用性和實用性以及 SSR 的 SEO 優勢。

Jamstack 和 SSG 的崛起

另一種流行的方案是靜態站點生成器（SSG），它們通常屬于 Jamstack 架構（JavaScript、API 和標記語言）。例如，Next.js、Gatsby 和 Hugo 最近變得非常流行。

這些方法在構建時預渲染頁面，而不是在請求周期內渲染，但它們也具有類似于 SSR 的優勢，同時減少了復雜性。

例如，Next.js 允許你創建可以預構建的網頁，但也可以根據使用情況動態生成內容。

這是一種“混合”解決方案，既能享受預渲染頁面的速度優勢，又能動態生成內容。

如何在考慮 SEO 的情況下，將我的應用從 SSR 轉為 CSR

在使用 SSR 一段時間后，我開始注意到它給項目帶來的日益復雜性和額外開銷。

于是，我決定探索替代方案，并偶然發現了 Prerender.io。以下是我如何進行切換的過程。

安裝 Prerender 中間件：

接著，我在服務器設置中集成了 Prerender.io 作為中間件。由于我使用的是 Express.js，這只需要安裝中間件并進行配置即可。

設置 Prerender.io 帳戶：

我注冊了一個 Prerender.io 帳戶，并獲得了 API 令牌。這個令牌被添加到我的中間件配置中，用于驗證 Prerender 服務的請求。

部署更新后的應用：

移除 SSR 并集成 Prerender.io 后，我將更新后的應用部署到服務器。現在該應用完全基于 CSR，Prerender 處理 SEO 預渲染。

SEO 測試：

我使用 Google Search Console 和其他 SEO 工具驗證搜索引擎是否正確索引了內容。這包括檢查動態內容、meta 標簽和其他關鍵 SEO 元素是否存在于預渲染的 HTML 中。

最終結論

從這個角度看，雖然 SSR 仍然有其意義，但它的重要性已經不如以前那么大。隨著先進的 CSR 方法、搜索引擎的改進和靜態站點生成的興起，SSR 在現代 Web 開發中的必要性已經大大降低。

因此，在 2024 年，我們應該開始質疑 SSR 是否值得為此承擔額外的開銷。

通常情況下，純粹的 CSR 配合正確的優化，或者 CSR 與 SSG 結合，可以更有效地解決這些問題。

結論

隨著 Web 開發的不斷演進，工具和技術也在不斷變化。SSR 雖然強大，但已經不再是解決性能和 SEO 問題的默認方案。

通過利用現代 JavaScript 的能力、靜態站點生成以及第三方服務，你可以構建快速、SEO 友好的應用程序，而無需服務器端渲染。

如果你正在構建一個新項目，不妨退一步思考一下 SSR 是否真的有必要。在很多情況下，你會發現其實并不需要它。