沖刺規(guī)劃會上，這事兒發(fā)生了。

我們在估算一個(gè)小型營銷站：三頁內(nèi)容，幾段文案，一個(gè)表單，也許再加個(gè)帶切換邏輯的價(jià)格表。典型的“快建站”。

一個(gè)初級同事抬頭問我：

“所以我們這次用 React 起個(gè)腳手架，對吧？”

我說：“不。服務(wù)器端渲染?！?/span>

他眨了眨眼，然后笑了。

“等下，你說……SSR？你是認(rèn)真的？”

我當(dāng)然是認(rèn)真的。

對最近五年入行的一些前端來說，SSR 聽起來像是降級，仿佛我建議我們用 COBOL 寫完再丟到一塊樹莓派上跑。

我在前端這條路上繞過不少彎。經(jīng)歷過“萬物 React 化”：一頁應(yīng)用（SPA），水合地獄（hydration hell），為渲染六行文字卻要下發(fā)超大體積的 bundle。我親眼看著所謂“現(xiàn)代網(wǎng)站”為靜態(tài)內(nèi)容都要起一層骨架屏。

所以，不，我不是開玩笑。我是終于認(rèn)真了。

React 變成了“默認(rèn)”，而不是“選擇”

先說清楚：我喜歡 React，也尊重它開啟的可能性。但某個(gè)時(shí)刻起，它從決策變成了默認(rèn)。我們伸手去拿它，卻沒先問：我到底要解決什么問題？就像用電鋸開一封信。

以至于連營銷站（極其簡單、幾乎靜態(tài)、除了表單沒什么交互）都要攜帶兆級 JavaScript，只為給你看一個(gè)標(biāo)題和一枚按鈕。

與此同時(shí)，真實(shí)的加載體驗(yàn)?zāi)?？空白屏。轉(zhuǎn)圈圈。然后，也許——如果你運(yùn)氣不錯(cuò)——才出現(xiàn)內(nèi)容。

服務(wù)器從沒“失靈”

于是我回到基本面：SSR，HTML 優(yōu)先渲染，最小化 JS。我開始按“老辦法”做站——那種就是能用的辦法。

然后，猜猜發(fā)生了什么？

• 頁面更快出現(xiàn)；
• SEO 立刻生效；
• 沒有客戶端路由的詭異 bug；
• 不再出現(xiàn)水合不匹配；
• 不需要 300KB 的表單庫來校驗(yàn)“姓名 + 郵箱”。

今年我們交付的一個(gè)項(xiàng)目（帶少量圖表的小儀表盤），從 3MB+ 的 React 及依賴，降到總資源不足 400KB；加載小于 1 秒；能離線；Lighthouse 98 分。沒有 React、沒有 Vite、沒有水合；只是 SSR，再用 AlpineJS 點(diǎn)綴必要的交互。

客戶的評價(jià)很簡單：“就是更快?！?/span>

而事實(shí)也是如此。

這不是“倒車”，而是重新思考

初級同事會笑，并不奇怪。行業(yè)這些年一直在對他們說：SSR 是遺物；客戶端優(yōu)先才是正解；水合不可避免；SPA 是默認(rèn)。

但大多數(shù)網(wǎng)站不是應(yīng)用；而大多數(shù)應(yīng)用，也不需要把大腦打包到瀏覽器。

SSR 是拒絕被復(fù)雜度綁架。

它提醒我們：服務(wù)器擅長渲染，瀏覽器擅長展示。展示一串列表，不需要 JS 框架；渲染幾段文本，不需要“整頁再水合”；當(dāng)用戶只是想讀點(diǎn)東西時(shí)，更不需要造一整套 SPA。

讓服務(wù)器，干服務(wù)器該干的活

我當(dāng)時(shí)就這么對他說：

“能在服務(wù)器渲染，就在服務(wù)器渲染。能發(fā) HTML，就發(fā) HTML。能避開水合，就避開。

然后——只在確實(shí)需要交互的時(shí)候，再小心地撒點(diǎn) JS。別為了一個(gè)下拉開關(guān)，把整棟樓倒著蓋。”

這回，他沒笑。

最后的想法

SSR 是按 Web 的本意在做事：快速、韌性強(qiáng)。那種能立刻出現(xiàn)、迅速著色、就算 JS 失效也不至于崩掉的網(wǎng)站。

下次你出于習(xí)慣伸手去拿 React 的時(shí)候，先問一句：

“如果我不用它，會怎樣？”

也許，你會驚訝于自己并不懷念那些負(fù)擔(dān)。