web前端性能优化 - 用一份清单建立页面优化起点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f143bfa55e97.html
📄
web前端性能优化 - 用一份清单建立页面优化起点
建立页面优化清单的关键，是把“感觉慢”拆成可逐项检查的指标：先测加载与渲染，再查资源体积与请求数，最后核对交互响应。清单不是一次性任务，而是每次改版后都能复用的检查顺序。下面按“查什么、怎么查、结果说明什么”给出可执行步骤。
第一项：先测核心加载指标，确定优化对象
要查的是页面从请求到可用的时间分布，而不是只看总加载时间。打开浏览器开发者工具的 Network 面板，勾选 Disable cache 后刷新页面，记录三个节点：首次字节时间（TTFB）、DOMContentLoaded、Load。结果说明什么：TTFB 偏高通常指向服务端响应或网络链路；DOMContentLoaded 与 Load 之间差距大，说明图片、字体等非阻塞资源拖慢了整体完成。
适用条件：本地开发环境网络稳定时先测一遍，再用工具的网络限速模拟 4G。判断结果时不要用单次数据下结论，至少刷新三次取中间值。
第二项：查资源体积与请求数量
要查的是哪些文件占用了最多字节、哪些请求可以合并或延后。在 Network 面板按 Size 排序，查看 JS、CSS、图片、字体四类资源的占比。结果说明什么：如果 JS 体积明显大于首屏所需，说明存在未拆分或未按需加载的代码；如果图片请求数多但单张不大，可能是图标或小图未合并。
- 检查项：首屏关键 CSS 是否内联或优先加载。
- 检查项：非首屏图片是否设置了懒加载。
- 检查项：第三方脚本是否放在页面底部或延迟执行。
可执行步骤：先处理体积最大的单个文件，再处理请求数最多的资源类型。不要同时改动多项，否则无法判断哪项生效。
第三项：核对渲染阻塞与布局稳定
要查的是 CSS 和同步 JS 是否阻塞了首次渲染，以及页面加载中是否出现明显位移。用 Lighthouse 的 Performance 报告查看“Eliminate render-blocking resources”和“Cumulative Layout Shift”两项。结果说明什么：前者提示样式或脚本在首屏渲染前必须下载执行；后者提示图片、广告位或字体替换导致内容跳动。
假设一个例子：某页面首屏文字在图片加载后下移约 40 像素，这属于布局位移，通常需要给图片容器预设宽高比。这个例子只用于说明判断方式，不代表任何真实站点数据。
第四项：检查交互响应与长任务
要查的是用户点击、输入后页面多久给出反馈。在 Performance 面板录制一段操作，观察 Main 线程是否出现超过 50 毫秒的长任务。结果说明什么：长任务会推迟事件处理，表现为按钮点击后延迟响应。适用条件是页面已有交互逻辑；纯静态展示页可先跳过此项。
判断结果时区分“可能原因”和“已经定位的原因”：长任务只是现象，具体是哪个函数耗时，需要展开调用树查看。不要仅凭长任务存在就断定是某个框架或库的问题。
把清单变成固定流程
每次上线前按顺序执行：测核心指标、查资源体积、核对渲染阻塞、检查交互响应。每项记录修改前后的数值，形成自己的基线。下一步是选当前最差的一项，只改一处并复测，确认有效后再进入下一项。
