浅谈技术探索与实践
上周五晚上 9 点半，我瘫在工位上刷 LeetCode，突然收到运维大哥的钉钉消息：“兄弟，你那个新上线的活动页，CDN 回源率爆了，后端服务快被干趴了。”
我一个激灵从椅子上弹起来——这可是我熬了三个通宵、喝了八杯瑞幸、还推掉了两次约会才搞出来的新版首页，怎么刚上线就翻车了？
我是谁？某二线互联网公司的三年前端老油条，日常靠 ChatGPT 写 CRUD，靠 Claude 梳理业务逻辑，一边维护祖传 Vue 2 项目，一边偷偷学 React + TS 准备跳槽。最近公司搞“体验优化月”，领导拍板说“前端要对首屏性能负全责”，于是我就被迫开启了这场和后端、网络、缓存斗智斗勇的性能优化之旅。
起因：一个看似简单的“体验优化”需求
事情得从一个月前说起。产品老大在周会上激情演讲：“我们要对标一线大厂！用户打开页面不能超过 1 秒！”
我内心 OS：您倒是给预算招个 CDN 专家啊，光靠前端能优化出花来？
但抱怨归抱怨，活儿还得干。我们这个活动页是典型的 SSR + CSR 混合渲染：首屏用 Node.js 渲染 HTML（其实是后端同学搭的 BFF 层），后续交互走前端 SPA。问题是——首屏数据依赖太多。一个接口拉商品信息，一个接口拉用户权益，还有一个接口查库存……五个接口串行请求，TTFB（Time To First Byte）直接飙到 1.8s。
测试同学跑来吐槽：“你们这页面在我手机上转圈 3 秒，我妈以为卡死了，直接关掉去拼多多了。”
我：……
更离谱的是，为了“快速上线”，当初直接把所有数据都塞进 SSR 的 window.__INITIAL_STATE__ 里，结果 HTML 体积干到 800KB+。CDN 缓存策略也没配好，每次用户刷新都回源拉新数据，后端服务 QPS 直接翻倍。
当时真的想砸电脑。
探索：从“前端视角”到“全链路思维”
以前我觉得性能优化就是“懒加载 + 图片压缩 + webpack 分包”，直到这次被现实狠狠教育了一顿。真正的性能优化，从来不是前端一个人的事——它是个综合工程，涉及网络、缓存、后端接口设计，甚至产品逻辑。
第一步：甩锅……啊不，是跨团队对齐
我拉上后端、运维、产品开了个紧急会。
我说：“现在首屏要等 5 个接口，能不能合并？”
后端小哥一脸无奈：“这些接口分属不同微服务，强行合并会拖慢整体响应。而且有些数据根本不需要首屏展示啊！”
产品一听急了：“不行！所有信息都要第一时间看到！”
我反手掏出 Google 的 Core Web Vitals 报告：“你看，LCP（最大内容绘制）超时，Google 会降权的，流量都没了你还展示啥？”
最后达成妥协：非核心数据延迟加载，比如用户权益、推荐商品这些，首屏只留商品主图、价格、库存状态。
第二步：SSR 缓存策略重构
原来的 SSR 是“每次请求都重新渲染”，等于把 Node 服务当 PHP 用。我和后端商量后，改成 分层缓存策略：
- 静态内容（如商品描述、图片 URL）：CDN 缓存 1 小时
- 半动态内容（如价格、库存）：Node 层缓存 10 秒，用 Redis 做分布式缓存
- 用户个性化内容（如优惠券）：客户端异步拉取，不走 SSR
具体实现上，我们在 Koa 中间件里加了缓存逻辑：
// 伪代码：SSR 缓存中间件
const getCacheKey = (ctx) => {
const { skuId, userId } = ctx.query;
// 非登录用户走公共缓存，登录用户走私有缓存
return userId ? `ssr:${skuId}:${userId}` : `ssr:${skuId}:public`;
};
app.use(async (ctx, next) => {
const cacheKey = getCacheKey(ctx);
const cachedHtml = await redis.get(cacheKey);
if (cachedHtml) {
ctx.body = cachedHtml;
return;
}
// 渲染并缓存
const html = await renderPage(ctx);
await redis.setex(cacheKey, 10, html); // 缓存 10 秒
ctx.body = html;
});
这一改，CDN 回源率直接从 70% 降到 15%，后端压力骤减。运维大哥终于不用半夜给我打电话了。
实战经验：那些踩过的坑和学到的教训
坑 1：缓存一致性问题
缓存是把双刃剑。有一次商品降价了，但 CDN 还在返回旧价格，用户下单发现价格不对，直接投诉到客服。
我们后来加了 缓存失效机制：每当商品信息变更，后端主动调用 CDN 刷新接口（虽然阿里云 CDN 刷新有配额限制，但我们用队列削峰填谷解决了）。
坑 2：过度优化导致可维护性下降
为了极致性能，我一度想把所有 CSS inline 到 HTML 里，JS 全部内联。但很快发现：代码变得像一坨意大利面。
后来回归理性：关键 CSS（Critical CSS）inline，非关键 CSS 异步加载；JS 按路由分 chunk，用 preload 提前加载首屏所需模块。
<!-- 关键 CSS 内联 -->
<style>
.product-title { font-size: 24px; color: #333; }
/* ... */
</style>
<!-- 非关键 CSS 异步加载 -->
<link rel="preload" href="/styles/extra.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
坑 3：忽略真实用户环境
本地 devServer 跑得飞快，但线上弱网环境下照样卡成 PPT。
我们接入了 Real User Monitoring (RUM)，用 Sentry 上报 LCP、FCP 等指标。结果发现：三四线城市用户很多还在用 4G，DNS 解析都慢得要死。
解决方案：
- 升级 DNS 服务商（从免费版换到付费版，TTL 调低）
- 启用 HTTP/2 + Brotli 压缩
- 静态资源上 OSS 并开启 Gzip
效果对比：数据不会说谎
折腾两周后，我们拉了一份前后对比数据（基于 1000+ 真实用户样本）：
| 指标 | 优化前 | 优化后 | 提升 |
|---|---|---|---|
| 首屏时间 (FCP) | 1850ms | 620ms | 66.5% ↓ |
| 最大内容绘制 (LCP) | 2100ms | 890ms | 57.6% ↓ |
| CDN 回源率 | 70% | 15% | 78.6% ↓ |
| 后端 QPS | 1200 | 450 | 62.5% ↓ |
最爽的是，产品老大在群里发了个红包：“体验提升明显，继续加油！”
我默默点开招聘 App，把简历更新了——“主导全链路性能优化，首屏性能提升 60%+”。
心得体会：技术探索的本质是解决问题
回头看看这段经历，其实没有用什么高深黑科技。核心就两点：
- 别把自己局限在“前端”角色。性能问题往往出在边界处——网络、缓存、后端接口。多和后端同学喝咖啡（或者一起骂产品经理），比自己闭门造车强一百倍。
- 平衡性能与可维护性。我见过太多团队为了 100ms 的提升，把代码搞得谁都看不懂。记住：可读、可维护的代码，才是长期性能的保障。
另外，真诚感谢我的 AI 搭子们。每次卡壳，我就把报错信息丢给 Claude：“帮我分析下这个 Redis 缓存穿透问题”，它总能给出清晰思路。虽然最后代码还是得自己写（AI 生成的代码经常缺边界处理），但至少节省了查文档的时间。
写在最后：关于“技术探索”的一点碎碎念
很多人觉得“技术探索”就是要学最新框架、玩最炫工具。但在我这个准备跳槽的三年前端看来，真正的技术探索，是在业务约束下找到最优解的能力。
你可能没有大厂的基建支持，没有无限的服务器预算，甚至还要兼容 IE11（别笑，我们内部系统还在用）。但正是这些限制，逼你去思考：
- 这个功能真的需要实时数据吗？
- 能否用缓存换性能？
- 用户感知最重的到底是哪一环？
上周团建，后端组长拍我肩膀：“下次搞大促，SSR 缓存方案你来牵头。”
我嘴上说“别别别，我还要刷题呢”，心里却有点小得意。
毕竟，能把技术落地到业务价值，才是工程师最硬的底气。至于跳槽？等我把这篇博客写完，再投简历也不迟 😎
评论 0