前端性能优化很容易变成一张技巧清单：压缩资源、延迟加载、减少重绘。开始排查时，第一件事是确认用户在哪一步感到慢。没有基线，任何“优化”都可能只是换了一组数字。
先建立可比较的基线
我会固定浏览器、设备、视口、网络条件和页面数据，记录最大内容绘制、交互延迟、布局偏移以及关键请求的响应时间。开发环境的热更新、本地磁盘和空缓存，不能直接代表线上。每次只改变一类因素，并把提交号和测试条件一起保存，前后结果才有可比性。
指标也要和页面任务对应。文章站的首屏重点可能是标题、摘要和正文的第一张图片，后台页面更在意表格能否及时交互。一个总分不能替代用户路径；如果分数变好，但正文晚了几秒才出现，用户仍然会觉得页面没有准备好。
按路径拆问题
网络阶段先看请求数量、响应体大小、缓存命中和连接复用；解析与执行阶段关注长任务、重复计算和不必要的 JavaScript；渲染阶段再看关键 CSS、图片尺寸和布局变化。一个页面可能同时有三类问题，不能用“上懒加载”解决所有事情。
图片是最常见也最容易被误解的地方。压缩和现代格式可以减少传输，但如果没有写出 width 和 height，图片加载后仍会推动页面移动；如果把首屏图片一律延迟，用户看到的反而是空白。应该按内容重要性决定加载时机，并在真实设备上检查清晰度和解码时间。
缓存也要和发布方式一起设计。带内容哈希的静态资源可以长期缓存，HTML 和 API 响应则需要明确失效规则。文章更新以后，页面、搜索和 RSS 可能拥有不同的缓存生命周期。只刷新浏览器一次，不能证明 CDN、服务端和客户端已经读到同一份内容。
优化结果要留在仓库里
一次测量可以保存成 JSON 或表格，连同浏览器版本、屏幕尺寸、网络条件和提交号一起提交。出现回归时，先判断是内容变了、环境变了，还是指标已经不适合当前体验。给关键路径设置一个宽松的回归阈值，比每次凭感觉判断快慢更可靠。
我也会把错误率、可访问性和低端设备表现放进验收。为了一个分数把动画删光、把交互延迟到用户点击以后，并不一定是好的优化。性能最终仍然要回到具体感受：需要的内容能否及时出现，点击后是否有反馈，失败时是否能看懂。
如果没有可比的基线，这篇文章只能作为排查顺序，不能当成任何页面的性能承诺。设备、网络、内容和依赖都会变化，测量条件应该和结论放在一起保存。这样下一次改版时，优化就能继续被验证，而非只停在一次性的手艺上。
我现在会把性能排查画成一个闭环，避免把一次分数变化误认为优化完成。每轮只改一类因素，才知道结果究竟来自哪里。
