我跟他说别用 React，改用 SSR。他以为我在开玩笑-优快云博客

我在前端这条路上绕过不少弯。经历过“万物 React 化”：一页应用（SPA），水合地狱（hydration hell），为渲染六行文字却要下发超大体积的 bundle。我亲眼看着所谓“现代网站”为静态内容都要起一层骨架屏。

冲刺规划会上，这事儿发生了。

我们在估算一个小型营销站：三页内容，几段文案，一个表单，也许再加个带切换逻辑的价格表。典型的“快建站”。

一个初级同事抬头问我：

“所以我们这次用 React 起个脚手架，对吧？”

我说：“不。服务器端渲染。”

他眨了眨眼，然后笑了。

“等下，你说……SSR？你是认真的？”

我当然是认真的。

对最近五年入行的一些前端来说，SSR 听起来像是降级，仿佛我建议我们用 COBOL 写完再丢到一块树莓派上跑。

我在前端这条路上绕过不少弯。经历过“万物 React 化”：一页应用（SPA），水合地狱（hydration hell），为渲染六行文字却要下发超大体积的 bundle。我亲眼看着所谓“现代网站”为静态内容都要起一层骨架屏。

所以，不，我不是开玩笑。我是终于认真了。

React 变成了“默认”，而不是“选择”

先说清楚：我喜欢 React，也尊重它开启的可能性。但某个时刻起，它从决策变成了默认。我们伸手去拿它，却没先问：我到底要解决什么问题？就像用电锯开一封信。

以至于连营销站（极其简单、几乎静态、除了表单没什么交互）都要携带兆级 JavaScript，只为给你看一个标题和一枚按钮。

与此同时，真实的加载体验呢？空白屏。转圈圈。然后，也许——如果你运气不错——才出现内容。

服务器从没“失灵”

于是我回到基本面：SSR，HTML 优先渲染，最小化 JS。我开始按“老办法”做站——那种就是能用的办法。

然后，猜猜发生了什么？

页面更快出现；
SEO 立刻生效；
没有客户端路由的诡异 bug；
不再出现水合不匹配；
不需要 300KB 的表单库来校验“姓名 + 邮箱”。

今年我们交付的一个项目（带少量图表的小仪表盘），从 3MB+ 的 React 及依赖，降到总资源不足 400KB；加载小于 1 秒；能离线；Lighthouse 98 分。没有 React、没有 Vite、没有水合；只是 SSR，再用 AlpineJS 点缀必要的交互。

客户的评价很简单：“就是更快。”

而事实也是如此。