SSR（服務(wù)器端渲染）曾經(jīng)被譽(yù)為解決單頁應(yīng)用（SPA）在性能和 SEO 問題上的靈丹妙藥，而這正是一個(gè)快速發(fā)展的領(lǐng)域。

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

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

什么是 SSR 以及我們?yōu)槭裁葱枰?/span>

服務(wù)器端渲染（SSR）指的是在服務(wù)器上渲染 Web 應(yīng)用程序，而不是在客戶端進(jìn)行渲染。

這意味著與當(dāng)前的客戶端渲染不同，用戶請(qǐng)求頁面時(shí)，服務(wù)器不僅僅發(fā)送 HTML 信息并讓瀏覽器完成其余的頁面布局，而是服務(wù)器生成從 HTML 代碼到頁面布局的所有內(nèi)容。

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

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

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

聽起來很棒，對(duì)吧？然而，和所有技術(shù)一樣：SSR 也有其優(yōu)點(diǎn)和缺點(diǎn)。

SSR 的缺點(diǎn)

盡管 SSR 提供了顯著的優(yōu)勢(shì)，但它并非沒有挑戰(zhàn)：

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

考慮到這些缺點(diǎn)，SSR 在 2024 年是否仍然必要？我認(rèn)為不是。

為什么 SSR 不再必要

CSR 已經(jīng)進(jìn)化

客戶端渲染（CSR）已經(jīng)取得了長(zhǎng)足的進(jìn)步。現(xiàn)代 JavaScript 框架如 React、Vue 和 Angular 在性能方面已經(jīng)得到了極大的優(yōu)化。

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

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

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

SEO 已經(jīng)迎頭趕上

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

然而，搜索引擎現(xiàn)在已經(jīng)大大提高了抓取和索引 JavaScript 渲染內(nèi)容的能力。

例如，Googlebot 目前就像任何現(xiàn)代瀏覽器一樣運(yùn)行，因此能夠抓取和索引 CSR 內(nèi)容。

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

Jamstack 和 SSG 的崛起

另一種流行的方案是靜態(tài)站點(diǎn)生成器（SSG），它們通常屬于 Jamstack 架構(gòu)（JavaScript、API 和標(biāo)記語言）。例如，Next.js、Gatsby 和 Hugo 最近變得非常流行。

這些方法在構(gòu)建時(shí)預(yù)渲染頁面，而不是在請(qǐng)求周期內(nèi)渲染，但它們也具有類似于 SSR 的優(yōu)勢(shì)，同時(shí)減少了復(fù)雜性。

例如，Next.js 允許你創(chuàng)建可以預(yù)構(gòu)建的網(wǎng)頁，但也可以根據(jù)使用情況動(dòng)態(tài)生成內(nèi)容。

這是一種“混合”解決方案，既能享受預(yù)渲染頁面的速度優(yōu)勢(shì)，又能動(dòng)態(tài)生成內(nèi)容。

如何在考慮 SEO 的情況下，將我的應(yīng)用從 SSR 轉(zhuǎn)為 CSR

在使用 SSR 一段時(shí)間后，我開始注意到它給項(xiàng)目帶來的日益復(fù)雜性和額外開銷。

于是，我決定探索替代方案，并偶然發(fā)現(xiàn)了 Prerender.io。以下是我如何進(jìn)行切換的過程。

安裝 Prerender 中間件：

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

設(shè)置 Prerender.io 帳戶：

我注冊(cè)了一個(gè) Prerender.io 帳戶，并獲得了 API 令牌。這個(gè)令牌被添加到我的中間件配置中，用于驗(yàn)證 Prerender 服務(wù)的請(qǐng)求。

部署更新后的應(yīng)用：

移除 SSR 并集成 Prerender.io 后，我將更新后的應(yīng)用部署到服務(wù)器。現(xiàn)在該應(yīng)用完全基于 CSR，Prerender 處理 SEO 預(yù)渲染。

SEO 測(cè)試：

我使用 Google Search Console 和其他 SEO 工具驗(yàn)證搜索引擎是否正確索引了內(nèi)容。這包括檢查動(dòng)態(tài)內(nèi)容、meta 標(biāo)簽和其他關(guān)鍵 SEO 元素是否存在于預(yù)渲染的 HTML 中。

最終結(jié)論

從這個(gè)角度看，雖然 SSR 仍然有其意義，但它的重要性已經(jīng)不如以前那么大。隨著先進(jìn)的 CSR 方法、搜索引擎的改進(jìn)和靜態(tài)站點(diǎn)生成的興起，SSR 在現(xiàn)代 Web 開發(fā)中的必要性已經(jīng)大大降低。

因此，在 2024 年，我們應(yīng)該開始質(zhì)疑 SSR 是否值得為此承擔(dān)額外的開銷。

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

結(jié)論

隨著 Web 開發(fā)的不斷演進(jìn)，工具和技術(shù)也在不斷變化。SSR 雖然強(qiáng)大，但已經(jīng)不再是解決性能和 SEO 問題的默認(rèn)方案。

通過利用現(xiàn)代 JavaScript 的能力、靜態(tài)站點(diǎn)生成以及第三方服務(wù)，你可以構(gòu)建快速、SEO 友好的應(yīng)用程序，而無需服務(wù)器端渲染。

如果你正在構(gòu)建一個(gè)新項(xiàng)目，不妨退一步思考一下 SSR 是否真的有必要。在很多情況下，你會(huì)發(fā)現(xiàn)其實(shí)并不需要它。