SSR 不是所有页面的性能解药

问题背景

这类问题常见于业务增长后的前端项目。页面还能跑，但新增需求越来越慢，问题定位越来越依赖个人记忆，最后所有人都怕改公共代码。

要看首屏内容、接口耗时、缓存策略和部署复杂度。 这篇文章更关心落地细节：怎么拆问题、怎么写代码或流程、怎么验收，而不是停在概念介绍。

真正耐用的前端方案通常不复杂，但边界会很清楚：哪些数据来自接口，哪些状态属于页面，哪些逻辑可以独立测试，哪些体验需要降级。

推荐做法

• 要看首屏内容、接口耗时、缓存策略和部署复杂度。
• 先用 Lighthouse、Performance 面板或线上 RUM 数据确定瓶颈，别凭感觉删代码。
• 把资源体积、主线程长任务、接口瀑布和渲染阻塞分开看，每类问题对应的修法不同。
• 优化后记录前后指标，至少对比同一网络、同一设备、同一路径。

一个可直接借用的片段

const params = new URLSearchParams(location.search);
params.set('page', String(nextPage));
history.replaceState(null, '', '?' + params.toString());

容易踩坑

• 不要为了消除重复就过早抽象，三处相似不一定代表同一个业务概念。
• 不要把后端返回的所有字段原样传到页面深处，字段越散越难维护。
• 不要只在高速网络和新电脑上验收，真实用户环境往往更差。

检查清单

1. 是否有优化前后的指标对比。
2. 是否确认瓶颈来自资源、接口、渲染还是主线程。
3. 是否在低端设备或慢网络下验证。
4. 是否保留回滚方案。

好的技术文章不只是告诉你“可以这么做”，还要说清楚什么时候不该这么做。前端工程 的很多经验，真正值钱的部分都在这些边界里。