过去一年，我手头经了大概四十多个页面和组件的交付，有从零搭的，也有给老项目擦屁股的。真正让我觉得值得拿出来拆一拆的，不是那些顺顺当当上线的，而是三个差点让我周末泡汤、最后硬是靠加班和撕逼掰回来的坑。一个一个说。
第一个坑：图片太大，首页白屏，运营说“我们以前就这么干的”
公司主站首页要改版，运营给了一套高清大图，单张PNG将近2M，说是品牌方要求不能压缩。我提了一句“这体积有点大”，运营回我“以前也是这么传的，没事”。结果上线当天下午，监控报警了——移动端首屏白屏率从0.3%飙到12%，5秒后还能正常展示的比例不到一半。
我当时在工位上，先关了报警声音，然后干了三件事：第一，把版本回滚到上一个稳定版，这个动作用了三分钟，CI上直接点rollback。第二，抓了个低端安卓机（红米Note8）连着Charles看瀑布流，发现那几张图不光体积大，还阻塞了后面两个关键API的请求。第三，跟运营说“图必须处理，不然我今晚不恢复上线”。
处理过程没那么优雅。我先是把图用sharp批量转成WebP，平均压到400K左右。然后改了懒加载的逻辑——之前用的是loading="lazy"，但首屏第一张轮播图还是会被当作关键资源。我换成Intersection Observer，给首屏可视区内的图加了fetchpriority="high"，其余的全部延迟到滚动前200px再加载。再顺手把三个第三方统计脚本从里挪到末尾，加上defer。
重新上线后，移动端首屏可交互时间（TTI）稳定在1.8到2.2秒之间，白屏率掉到0.1%以下。但这里有个教训我没写在报告里：回滚那三分钟里，已经有大概两百个用户看到了白屏。事后我加了一条验收红线——任何图片资源超过300K且未经过压缩和懒加载方案评审，不允许合并到主干。运营后来再给图，都会主动问一句“这图行不行”。
第二个坑：一个第三方组件，把整个后台的按钮都点不动了
那是一个周五下午，四点多，客户在群里发语音，语气很急：“新增客户的按钮按了没反应，你们是不是把系统搞崩了？”我远程连上去，打开DevTools，点了那个按钮，Console没报错，但鼠标移到按钮上光标不变。看了一下Computed样式，pointer-events: none。
谁改的？全局搜了一下.overlay，发现两处定义。一处是我们自己的公用样式，pointer-events: auto；另一处是上周刚引入的一个日期选择器组件，它的CSS里有一句.overlay { pointer-events: none; }。而且这个组件是在页面底部加载的，它的样式覆盖了我们的。 hn373.CoM
我当时没敢直接改线上，先在自己分支上试了两种方案。第一种是加!important，试了一下确实能解决问题，但这玩意儿就跟用胶带缠水管一样，以后谁再引入别的组件，还得继续缠。第二种是提高选择器特异性：.page-container .overlay，这样只作用于我们自己的遮罩层。改完后测试了一下，日期选择器本身没崩，其他依赖.overlay的弹窗也没报错。
但问题来了——测试同事说，有一个用了日期选择器的老页面，样式又乱了。我一看，那个页面的容器类名不是.page-container，是.legacy-form。最后我把修复改成了更稳妥的：给第三方组件单独包一层命名空间，.third-party-wrapper .overlay里的样式只影响它内部；我们自己的.overlay再加一条pointer-events: auto，并且确保它加载顺序在第三方之后。
那天我搞到晚上九点才发上线通知。说实话，最让我难受的不是修代码，而是第二天要写故障报告，里面要填“根本原因”和“预防措施”。我填了两条：第一，新引入的任何第三方样式必须跑一遍自动化检查，检测是否使用了无前缀的通用类名（如.overlay、.modal、.container）；第二，代码Review时，如果发现全局选择器或者通配符，直接打回。组长看了说行，后来又加了一条——紧急修复时允许临时用!important，但必须在下个版本里重构掉。
第三个坑：一个下拉框，点一下等两秒
这个坑最隐蔽。有一个列表页，筛选条件的下拉框，点开要等两秒才出选项。用户反馈了快两周，产品经理也找过我两次，我一开始觉得是后端慢，抓了个包一看，结果让我自己脸红。
流程是这样的：点下拉框 -> 触发请求A（拿当前用户信息）-> 拿到用户ID后再发请求B（拿用户所在的区域ID）-> 拿到区域ID后再发请求C（拿下拉框的选项）。典型的请求瀑布，一步卡死，步步卡死。最慢的时候，请求A如果因为网络抖动延迟到1秒，后面就全跟着等。
我当时的第一反应不是改代码，是找后端老张。我直接去他工位，把Chrome的Timeline截图给他看，说“你瞧，这三个接口串起来了，能不能把B和C合并成一个？给我一个接口，传用户ID，返回区域信息和选项列表”。老张看了一眼说“逻辑有点绕，得排到下个迭代”。我说“下个迭代要两周，用户等不了”。后来我提了个折中方案：后端先给我一个临时接口，只做数据聚合，业务逻辑先不管，我自己在前端兜底。老张答应了，两天后给了新接口。
新接口上了之后，点击下拉框到展示选项的时间从两秒降到了四百毫秒左右。但我还不满意——因为用户如果刚进页面就点下拉框，还是要等这四百毫秒。我加了一个预加载：在页面主数据加载完成后，趁着用户在看上面表格的时间，静默把那个新接口的请求发出去。等用户真正点下拉框时，数据要么已经在内存里，要么正在路上。最终平均响应时间压到了240毫秒。
这件事给我自己的教训是：前端性能优化不能只在自己地盘上转，该找后端改接口就得去找，拿数据说话，大部分后端同事是愿意配合的。另外，预加载不是万能的——如果用户点得比预加载还快，我做了个骨架选项，显示“加载中”，至少不会让用户以为页面卡死了。
这一年下来，我有个很深的体会：网页设计开发这活儿，说到底就是跟不确定性打交道。你不知道运营下次会给你塞多大的图，不知道第三方组件的CSS里藏了什么雷，不知道后端接口哪天就慢了。能做的就是把每一次故障都变成一条可执行的规则——写在代码里也好，写在Review清单里也好，写在CI检查脚本里也好。别相信“下次注意”，下次一定会再犯。
明年我打算把这三条经验沉淀成一个内部的性能基线工具，自动检测新页面的图片体积、请求瀑布和样式污染。到时候跑通了，再单独写一篇。
-
想了解更多工作总结的资讯，请访问：工作总结