首屏提速3倍、存储省70%：建站资源极致优化实践

　　去年六月，选题会上那支蓝黑中性笔横在会议桌左上角，笔帽没拧紧，但没人动它。总编第三次把“首屏提速3倍、存储省70%”这行字从投影里拖出来放大，鼠标悬停三秒，没点删除，也没点保存。我就知道这选题活不过三小时——不是它不硬，是它太硬，硬得硌牙。

　　我原以为只要塞进WebP+懒加载+CDN预热三件套，再调两行Vite构建配置，差不多就能交差。结果上线前压测，首屏LCP卡在2.8s，不是因为资源大，是因为JS执行队列里堆着七个微前端的runtime，其中三个还在fetch自己家的manifest.json，而那个manifest……是base64嵌在HTML里的。我说“删掉”，小编点头，转身去改，二十分钟后回来说：“哦，这个manifest是作者本地dev-server自动生成的，没走CI，每次打包都重写。”我盯着她后颈那颗痣，忽然记起她上个月还用Webpack 4跑React 18项目，用的是eval-source-map。这个我敢打包票。

　　隔壁桌咖啡洒了。泼在键盘上那摊褐色液体缓慢漫过空格键边缘时，我正把所有srcset里webp兜底逻辑全干掉，换成了image-set()加CSS容器查询。不是为了炫技，是发现iOS 16.4之后，的fallback机制在Safari里会触发两次解码——第一次是解析HTML时预加载，第二次是样式计算后渲染。而我们用了127个标签，每个都有两个，其中63个写了type="image/webp"，剩下全是type="image/jpeg"……等等，其实jpeg也不对，有31张是PNG，但扩展名被手动改成.jpg——这个我说不准，只记得部署脚本里有一行sed -i 's/.png/.jpg/g'，写在copy static assets之后，minify之前。谁写的？作者？还是那个永远不看commit message的运维？

　　外卖凉了，铝箔盒边沿凝着一圈白霜，没人打开。总编说“能不能别只盯着客户端”，我掏出手机翻Chrome DevTools Performance面板截图，他扫了一眼说：“你看，TTFB才147ms，你优化的是哪儿？”我没答。TTFB当然低，因为我们早把SSR服务迁到Cloudflare Workers，Node.js runtime删了，连v8 snapshot都扔了，就留一个Deno Deploy脚本吐静态HTML片段。可关键不在那儿——首屏卡在Style Layout，不是JS，不是网络，是浏览器反复重排那个main容器：它的width设的是max-content，而里面嵌着个用flex-wrap: wrap的卡片流，每张卡片又有background-image + clip-path + transform，且每张图都带3层伪元素遮罩……我说这是设计稿问题，设计师在钉钉群里发了个微笑表情包，附带一句“用户需要呼吸感”。呼吸感。呵。

　　后来真把首屏提了三倍。怎么做的？砍掉所有“为未来留接口”的CSS class；禁掉所有非必要IntersectionObserver回调；把font-display: swap改成block但只保WOFF2；把整个icon系统从SVG Sprite换成单文件inline 并内联进——就这一步，省下17个HTTP请求，其中9个是跨域CDN，带Prefetch Link头，结果被iOS Safari silently ignore。至于存储省70%，靠的是一次误操作：我在清理CI缓存时手抖删错了s3://bucket/assets/raw/，顺手重建了个/raw_v2，结果发现旧raw目录里躺着587张未压缩PNG，最大那张是设计师传的“高清效果图”，尺寸4320×2880，体积18MB，格式却是RGB无alpha——但人家说“苹果Retina屏要这个精度”。我当场把那张图用convert -resize 25% -strip -quality 65转成JXL，丢进image-set()第一档。没人问，也没人测兼容性，反正上线那天凌晨三点，CDN缓存全部刷新完毕。这个我敢打包票。

　　说到底，这不是技术方案，是淘汰赛。留下的，是那些能扛住三次紧急回滚、两次CDN配错、一次DNS劫持还能跑通的代码；被淘汰的，是所有人点头说“理论上可行”的方案，比如用WebAssembly跑图片滤镜——上周作者还在群里秀他用Rust编译出的blur.wasm，2.3MB，加载完首屏早结束了。可你知道最讽刺的是什么？我们压测环境用的Lighthouse评分模板，是三年前从Google官方案例里抄的，那个案例早就下线了，但我们没更新，评分阈值也一直按老标准卡——所以现在报告里“性能得分92”，其实是基于一套已经失效的评估体系。没人提。就像没人问为什么测试服务器内存是开发机的四倍，而生产数据库连接池配置，至今还写着max=20，注释里写着“防止雪崩”，可线上QPS峰值从来不到17。

　　总编最后拍板让这选题上，不是因为信服数据，是因为另一篇讲“AI生成建站SaaS”的稿子被甲方毙了，他们临时缺个能吹“降本增效”的封面故事。选题会上空调坏了，风速档位卡在三档，嗡嗡响。小编低头刷手机，锁屏壁纸是她家猫叼着路由器线的照片。我盯着投影右下角的时间戳跳到19:43:11，忽然想起去年这时候，我还在给一个金融客户做静态资源隔离——他们要求所有第三方脚本必须走沙箱iframe，连Google Analytics都要用postMessage relay，结果监控发现，relay层本身引入的TBT比GA多出四倍。我那时就说，优化不是加东西，是不断确认“这个到底有没有在真正运行”。

文章配图，仅供参考

　　这篇稿子我写到这儿就停了。明天上午十点又要开选题会。我打算带一支新笔去，笔帽拧紧。别的，再说吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!