chrome做web性能分析

• 前言
• 1. 先明确要分析什么
• 2. 先认识核心指标
  • 2.1 Core Web Vitals
  • 2.2 其他常见指标
• 3. Chrome 中各工具怎么分工
• 4. 开始录制前的准备
• 5. 分析页面加载性能
• 6. 分析点击、输入与滚动卡顿
• 7. Performance 录制结果怎么看
  • 7.1 先看概览和 Insights
  • 7.2 再看 Network 轨道
  • 7.3 最后下钻 Main 主线程
• 8. 用 Network 面板拆解请求耗时
• 9. 常见问题与优化方向
• 10. 分析内存持续增长
• 11. 给业务代码添加自定义标记
• 12. 实验室数据与真实用户数据
• 13. 一套可复用的排查流程
• 14. 常见误区
• 15. 记录模板与检查清单
• 16. Fiddler Everywhere 适合什么场景
• 总结
• 参考

前言

优化网页性能时，最容易出现的误区是：打开 Lighthouse，看见分数不高，就开始压图片、删代码。这样有时有效，但也可能改了很多地方，却没有解决真正影响用户体验的问题。

更稳妥的思路应该是：

先定义慢在哪里
    ↓
固定测试条件并录制
    ↓
从指标定位到时间段
    ↓
从时间段定位到请求、任务和代码
    ↓
只改一个主要问题
    ↓
用相同条件重新测试

这篇笔记主要记录如何用 Chrome DevTools 分析三类问题：

1. 页面第一次打开很慢；
2. 点击、输入、切换页面时反应迟钝；
3. 滚动或动画掉帧，页面使用一段时间后越来越卡。

Chrome 不同版本的按钮位置和文字可能略有变化，但分析思路基本一致。本文重点不是记住界面，而是建立一套可以重复使用的排查方法。

1. 先明确要分析什么

“网站很慢”不是一个可以直接分析的问题。录制前最好先把现象改写成一个可重复的场景。

例如：

场景 A：首次打开文章详情页，首屏大图出现很晚。
场景 B：在商品列表里点击筛选项，界面约 1 秒后才更新。
场景 C：连续打开和关闭弹窗 20 次后，页面越来越卡。
场景 D：滚动长列表时明显掉帧。

每次只分析一个场景，并记录：

• 页面 URL 和代码版本；
• 使用的 Chrome 版本；
• 桌面或移动设备视口；
• 网络与 CPU 限速设置；
• 是否禁用缓存；
• 从哪里开始操作，到哪里结束；
• 重复几次可以稳定复现。

如果场景本身不能稳定复现，后面的火焰图再详细，也很难判断优化是否真的有效。

2. 先认识核心指标

2.1 Core Web Vitals

目前最重要的三个 Core Web Vitals 是 LCP、INP 和 CLS。判断站点整体是否达标时，应观察真实用户数据的第 75 百分位，并把移动端和桌面端分开看。

可以用一句话记住：

LCP 看加载，INP 看响应，CLS 看稳定。

需要注意：

• LCP 不是“所有资源加载完毕”，而是视口内最大内容元素完成绘制的时间；
• INP 需要真实交互，单纯刷新页面不会自动得到有代表性的 INP；
• CLS 没有单位，数值来自布局偏移的累计，不是毫秒；
• 一次本地测试只能说明当前机器和当前操作，不能代替真实用户数据。

2.2 其他常见指标

不要只盯着 DOMContentLoaded 或 load。页面可能很早触发 load，但主线程仍被大段 JavaScript 占用；也可能 load 很晚，用户却早已能正常阅读和操作。

3. Chrome 中各工具怎么分工

Chrome DevTools 里与性能相关的面板很多，不需要每次全部打开。

推荐分工：

Lighthouse：快速体检
Performance：定位时间和主线程原因
Network：拆解请求
Memory：追内存泄漏

旧版本 Chrome 中的 Audits 面板已经由 Lighthouse 面板取代。本文后面所说的性能录制，主要指 Performance 面板，不是 Lighthouse 报告。

旧教程里还可能出现一个独立的 Performance Insights 面板；较新的 Chrome 已把这些诊断能力整合到 Performance 面板左侧的 Insights 中，所以不必再寻找单独面板。

4. 开始录制前的准备

性能数据很容易受到环境干扰。正式比较优化前后结果时，至少做好下面几件事。

使用尽量干净的环境

1. 使用无痕窗口，减少扩展程序和已有缓存的干扰；
2. 关闭与测试无关的标签页和占用 CPU 的程序；
3. DevTools 可以独立停靠到单独窗口，避免页面可视区域频繁变化；
4. 保持浏览器版本、视口大小和页面数据一致。

无痕模式并不等于“绝对没有干扰”，但通常比日常使用的浏览器环境更干净。

固定网络、CPU 与缓存条件

在 Performance 的 Capture settings 或 Network 面板中，可以设置网络和 CPU 限速。测试移动端体验时，不要只用高性能电脑的 No throttling。

例如可以固定为：

视口：移动端尺寸
网络：Slow 4G（或团队约定的自定义配置）
CPU：4x / 6x slowdown
缓存：首次访问禁用缓存，重复访问保留缓存

这里没有一个适合所有项目的万能配置。最重要的是把配置写进测试记录，并在优化前后保持一致。

较新的 DevTools 还提供 CPU calibration，可以根据当前电脑生成更贴近低端或中端移动设备的限速档位。如果界面中有该功能，团队可以先校准再固定测试档位；但它仍然只是实验室模拟，不能替代真机。

冷缓存和热缓存分开测

• 勾选 Disable cache：更接近首次访问或缓存未命中的情况；
• 允许缓存：更接近重复访问；
• Disable cache 通常只在 DevTools 打开时生效；
• 不要把两种结果混在一起比较。

不要只跑一次

同一场景建议运行 3～5 次，先看中位数和结果范围。后台进程、垃圾回收、网络波动都可能让某一次结果异常。

5. 分析页面加载性能

下面是一套最常用的首屏加载录制流程。

1. 打开目标页面和 DevTools；
2. 进入 Performance 面板；
3. 在 Capture settings 中确认 Network、CPU、Screenshots 等设置；
4. 使用“Record and reload”按钮开始录制并刷新页面；
5. DevTools 通常会在 load 后数秒自动停止；若要覆盖更长的 SPA 初始化或延迟加载过程，应改用普通 Record，完成场景后再手动 Stop；
6. 先看 Core Web Vitals 和 Insights，再逐层查看 Network 与 Main 轨道；
7. 记录 LCP 元素、关键请求、长任务和主要时间消耗。

分析加载性能时，可以按这几个问题往下追：

LCP 慢
├─ HTML 第一个字节来得晚吗？
├─ 浏览器是否很晚才发现 LCP 资源？
├─ LCP 图片或字体下载时间过长吗？
└─ 资源已经下载，但主线程太忙，导致很晚才绘制吗？

如果 LCP 元素是一张首屏大图，需要继续检查：

• 图片是否比实际显示尺寸大很多；
• 是否使用了合适的现代格式与压缩；
• 是否被懒加载到发现太晚；
• HTML 中是否能尽早发现它；
• 是否被 CSS、字体或 JavaScript 阻塞显示；
• preload 或 fetchpriority 是否真的用于明确的关键资源，而不是滥用。

如果主要时间花在 TTFB，压缩前端图片通常不是第一优先级，应先看服务器处理、CDN、缓存、重定向和网络位置。

6. 分析点击、输入与滚动卡顿

加载录制解决不了所有问题。按钮点击慢、输入框卡、切换标签页卡顿，需要录制运行时交互。

1. 先打开 Performance 面板的 Live metrics；
2. 按照真实用户路径执行点击、输入、展开菜单、切换路由等操作；
3. 观察 INP、Interactions 和 Layout shifts 是否出现异常；
4. 找到可以稳定复现的动作后，点击 Record；
5. 只录制问题动作前后几秒，完成后立即 Stop；
6. 在时间线中选择对应交互，再查看输入延迟、处理时间和呈现延迟；
7. 下钻到 Main 轨道，确认是哪个事件处理器、框架更新、布局或绘制占用了时间。

一次交互变慢，通常可以拆成三段：

输入延迟：事件已经发生，但主线程还在忙，处理器迟迟不能开始
处理时间：事件回调及其同步工作耗时太长
呈现延迟：回调结束后，样式、布局、绘制等工作拖延了下一帧

对应的优化方向并不相同：

• 输入延迟高：优先找交互前正在执行的长任务；
• 处理时间高：拆分事件处理逻辑，减少同步计算和不必要的状态更新；
• 呈现延迟高：检查大范围样式重算、布局、绘制和过大的 DOM。

如果问题是滚动或动画不流畅，可以同时关注：

• FPS 和 Frames 轨道；
• 主线程是否持续满载；
• 是否反复触发 Layout / Recalculate Style；
• Paint 区域是否过大；
• 动画是否在修改会触发布局或绘制的属性。

7. Performance 录制结果怎么看

面对一张很长的时间线，不要一开始就钻进最深的函数。推荐按“概览 → 时间段 → 任务 → 代码”逐层缩小范围。

7.1 先看概览和 Insights

先回答这些问题：

1. LCP、INP、CLS 哪一项有问题？
2. 问题发生在加载、交互还是滚动阶段？
3. CPU 是短时尖峰，还是长时间满载？
4. Network 是否有明显的长请求或串行请求链？
5. Screenshots 中，页面在哪个时间点才出现主要内容？
6. Insights 是否指出渲染阻塞请求、LCP 分解、布局偏移、第三方代码等线索？

Insights 很适合提供调查入口，但它是线索，不是最终结论。点击某条 Insight 后，应回到对应的网络请求、主线程事件和源代码确认因果关系。

7.2 再看 Network 轨道

Network 轨道可以把请求和主线程活动放在同一时间线上。重点看：

• HTML、CSS、字体、首屏图片什么时候开始请求；
• 是否存在很长的请求依赖链；
• 关键资源是否被低优先级或较晚发现；
• 第三方脚本是否在首屏阶段占用网络和主线程；
• 资源完成下载以后，为什么还没有及时绘制。

如果需要看请求的 DNS、连接、TLS、TTFB 和下载耗时，应切换到 Network 面板的 Timing 详情。

7.3 最后下钻 Main 主线程

Main 轨道是性能分析的核心。它是一张火焰图：

• 横向宽度代表耗时；
• 上下堆叠代表调用关系；
• 顶层任务包含它触发的脚本、样式、布局和绘制工作；
• 红色角标或长任务标记通常值得优先检查。

选择一个事件后，底部常见视图包括：

还要分清两个时间：

• Self time：函数自身执行的时间；
• Total time：函数自身加上所有子调用的总时间。

一个函数的 Total time 很大，但 Self time 很小，通常说明真正的耗时在它调用的子函数里。

8. 用 Network 面板拆解请求耗时

Network 面板适合回答“资源为什么来得晚”。建议先打开面板，再刷新页面，必要时勾选 Disable cache 和 Preserve log。

优先检查这些列：

• Name：资源名称；
• Status：状态码或失败原因；
• Type：document、script、stylesheet、font、image、fetch 等；
• Initiator：是谁发起了请求；
• Size：传输大小及缓存情况；
• Time：总耗时；
• Priority：浏览器分配的优先级；
• Waterfall：请求之间的先后和重叠关系。

选中请求后，在 Timing 中常见的阶段可以这样理解：

常见判断方式：

Waiting (TTFB) 很长
→ 优先查服务端处理、缓存、CDN、重定向和网络距离

Content Download 很长
→ 优先查资源体积、压缩、图片尺寸和带宽

请求很晚才开始
→ 查看 Initiator，确认资源是否被 JS/CSS 很晚才发现

大量请求串行
→ 查依赖链、重定向、同步加载和是否可以提前发现关键资源

按住 Shift 并悬停某个请求，可以查看它的发起者和依赖关系。对于“为什么这张图到很晚才请求”这类问题，Initiator 往往比单看耗时更有价值。

9. 常见问题与优化方向

优化时不要一次改十项。先选影响最大的瓶颈，保留录制文件和基线数据，只改一个主要变量，再用相同条件复测。

10. 分析内存持续增长

如果页面第一次打开正常，但使用一段时间后越来越慢，可以先打开 Performance monitor：

1. 按 Ctrl + Shift + P（macOS 为 Command + Shift + P）；
2. 输入并选择 Show Performance monitor；
3. 重复执行怀疑泄漏的操作；
4. 观察 JS heap size、DOM Nodes、Event listeners 是否只升不降。

这只能帮助确认“可能在增长”，不能直接找到谁在持有对象。继续进入 Memory 面板：

1. 操作前获取一次 Heap snapshot；
2. 重复打开/关闭组件、切换路由等动作；
3. 在合适时机触发垃圾回收，再获取第二次快照；
4. 使用 Comparison 对比对象数量和 retained size；
5. 搜索 Detached，检查已经离开 DOM、却仍被 JavaScript 引用的节点；
6. 沿 Retainers 路径找到仍然持有对象的监听器、闭包、缓存或全局变量。

常见泄漏来源包括：

• 组件销毁后没有移除事件监听器；
• setInterval、订阅或观察器没有清理；
• 全局数组和缓存只增不减；
• DOM 已移除，但闭包仍保存其引用；
• 单页应用路由切换后，旧页面对象仍可达。

内存值有锯齿并不一定是泄漏，JavaScript 垃圾回收本来就会让堆大小上升后再下降。真正需要关注的是：多轮相同操作并完成回收后，基线仍持续抬高。

11. 给业务代码添加自定义标记

页面复杂时，只看浏览器内部事件很难知道某段业务逻辑从哪里开始。可以使用 User Timing API 添加标记：

performance.mark('filter:start');

await updateProductList();

performance.mark('filter:end');
performance.measure(
  'filter interaction',
  'filter:start',
  'filter:end'
);

重新录制后，filter interaction 会出现在 Performance 的 Timings 轨道中。这样可以把业务阶段和网络、JavaScript、布局、绘制放在同一条时间线上分析。

标记名称最好使用稳定的业务语义，例如：

route-change
search-request
search-render
editor-bootstrap
chart-update

不要在高频循环里无节制地打标记；标记本身也属于观测代码，应保持简单和可控。

12. 实验室数据与真实用户数据

Performance 的本地录制和本地 Lighthouse 运行得到的是实验室数据，优点是环境可控、容易复现、可以看到调用栈；缺点是只代表一次设备、一次网络和一条操作路径。Performance 首页在条件允许时也可以显示 CrUX field data，不能把这部分与本地录制混为一谈。

真实用户监控（RUM）或 Chrome User Experience Report 一类的 field data，反映真实设备和网络上的长期分布，但通常不直接告诉你具体哪一行代码造成问题。

两者应该配合使用：

真实用户数据：告诉我问题影响谁、影响多大、发生在哪些页面
实验室录制：帮助我稳定复现，并定位请求、任务和代码原因

特别要注意：

• 实验室只刷新页面时，测不到完整的真实 INP；
• 没有继续交互时，本地 CLS 可能低估页面整个生命周期的布局偏移；
• 某个高端开发机上的“流畅”，不代表低端移动设备也流畅；
• Performance 面板能显示 field data 时，应把它与本地结果对照，但并非所有 URL 都有足够数据。

13. 一套可复用的排查流程

我更推荐下面这个顺序。

第一步：把问题写成可重复场景

首次访问 /article/xxx
移动端视口，Slow 4G，CPU 4x slowdown
从刷新开始，到首屏标题和封面稳定出现为止

第二步：记录基线

运行 3～5 次，记录中位数、范围和异常值，不只保存一个 Lighthouse 分数。

第三步：从宏观指标缩小时间范围

先确认是 LCP、INP、CLS、网络、内存还是帧率问题，再选择对应的几秒钟。

第四步：找到直接证据

网络问题 → Waterfall、Initiator、Timing
主线程问题 → Long task、Bottom-up、Call tree
渲染问题 → Layout、Paint、Frames、Layout shifts
内存问题 → Performance monitor、Heap snapshot、Retainers

第五步：提出可以验证的假设

不要写“可能是前端太慢”，要写成：

首屏图片直到主脚本执行后才开始请求，导致 LCP 资源发现延迟约 800 ms。

第六步：只改一个主要变量并复测

使用相同 URL、构建、设备、网络、CPU、缓存状态和操作步骤。比较的不只是总分，还要看原问题对应的指标与时间线是否真的改变。

第七步：回到真实用户数据验证

上线后继续看真实用户分布和回归情况。一次本地录制变快，只能证明实验场景改善，不能自动证明所有用户都改善。

14. 常见误区

误区 1：Lighthouse 100 分就是性能分析完成

Lighthouse 是很好的自动体检工具，但分数会受环境和版本影响，也不能替代真实交互录制。重点是具体指标、审计证据和用户场景，不是追求一个漂亮的整数。

误区 2：一次录制就能下结论

单次结果可能被网络抖动、垃圾回收或后台程序影响。至少重复几次，并保留完全相同的测试条件。

误区 3：所有黄色 JavaScript 块都要优化

JavaScript 执行并不天然有问题。需要优先处理的是阻塞关键内容、用户交互或下一帧的长任务和热点代码。

误区 4：DOMContentLoaded 和 load 越早，体验一定越好

这两个事件是页面生命周期标记，不等于主要内容可见，也不等于交互及时。应结合 LCP、INP、CLS 和真实场景判断。

误区 5：模拟移动端就等于真机

DevTools 的网络和 CPU 限速适合可重复比较，但不能完整模拟移动设备的 GPU、温控、内存、无线网络和系统调度。重要页面仍应在真实设备上复查。

误区 6：看到建议就直接加 preload 或 will-change

preload、fetchpriority、will-change 都有成本。只对经过测量确认的关键资源或动画使用，滥用可能增加竞争、内存和合成层数量。

15. 记录模板与检查清单

可以用下面的模板记录一次性能分析：

页面 / 场景：
代码版本：
Chrome 版本：
设备 / 视口：
网络限速：
CPU 限速：
缓存状态：冷缓存 / 热缓存
重复次数：

基线：
- LCP：
- INP / TBT：
- CLS：
- 关键请求：
- 最长主线程任务：

证据：
- Performance 时间段：
- Network 请求与 Timing：
- 对应源文件 / 函数：

假设：
修改：
复测结果：
是否改善真实用户数据：

最后用这份清单自查：

• [ ] 问题场景可以稳定复现；
• [ ] 优化前后使用相同的测试配置；
• [ ] 冷缓存和热缓存没有混在一起；
• [ ] 至少重复测试 3 次；
• [ ] 已从指标定位到具体时间段；
• [ ] 已找到请求、任务或代码层面的证据；
• [ ] 没有只凭 Lighthouse 总分判断；
• [ ] 修改后重新录制并对比；
• [ ] 重要改动在真实设备或真实用户数据中继续验证。

16. Fiddler Everywhere 适合什么场景

Fiddler Everywhere 是一款运行在 Windows、macOS 和 Linux 上的跨平台 Web 调试代理。它位于客户端与服务器之间，可以捕获、检查、修改和重放 HTTP(S) 流量，也支持 WebSocket、Server-Sent Events 和 gRPC 等协议。它的重点是“请求和响应经过网络时发生了什么”，而不是浏览器内部如何执行 JavaScript、计算布局和绘制页面。

可以这样区分它和 Chrome DevTools：

页面为什么掉帧、哪个函数占满主线程
→ Chrome DevTools Performance

某个 API 实际发了什么、服务端返回了什么、能否修改后重放
→ Fiddler Everywhere

它适合解决什么问题

1. 跨应用抓包：不仅能观察 Chrome，还能分析桌面客户端、命令行程序以及经过代理配置的移动设备流量；
2. 检查协议细节：查看请求方法、URL、Headers、Cookie、请求体、响应体、状态码、大小和 Timing；
3. 重放和修改请求：把已捕获的请求发送到 Composer，修改参数、Headers 或 Body 后重新执行；
4. 模拟异常场景：使用 Rules 和断点修改请求或响应、重定向地址、替换返回内容，验证客户端面对错误响应时的行为；
5. 保存排障证据：把相关会话整理成 Snapshot，便于之后复现，或在清理敏感信息后交给团队分析；
6. 分析远程设备：在同一网络内配置代理后，可以观察手机、平板或其他设备发出的 HTTP(S) 请求。

它对 Web 性能分析的价值主要集中在网络层。例如：

如果问题是 JavaScript 长任务、INP、强制同步布局、Paint 或掉帧，Fiddler 看不到浏览器主线程调用栈，这时仍然应该回到 Chrome DevTools Performance。

一个最小使用流程

1. 根据目标选择捕获方式：只看网页可以使用独立浏览器捕获；分析其他应用可选择系统代理、专用终端或显式代理；
2. 开始捕获后立即按域名、进程、状态码或资源类型过滤，避免无关流量淹没问题请求；
3. 选中目标会话，通过 Inspectors 检查请求、响应和 Timing；
4. 需要复现时使用 Replay；需要修改参数时发送到 Composer；
5. 需要模拟错误或替换内容时再创建 Rules，不要一开始就修改全部流量；
6. 完成后关闭捕获，保存必要证据，并清理不再需要的敏感会话。

HTTPS 抓包的安全注意事项

使用系统代理模式时，Fiddler Everywhere 默认只捕获非加密 HTTP；若要在系统层捕获并解密 HTTPS，需要安装并信任它生成的根 CA。独立浏览器或专用终端捕获使用预配置环境，通常不需要把该 CA 安装到系统证书库。解密 HTTPS 时，Fiddler 会作为本地中间代理解密并重新签发站点证书，所以要清楚自己扩大了对应调试环境的信任边界。

使用时建议：

• 只从官方安装包生成和安装 Fiddler CA；
• 个人开发环境优先信任到当前用户证书存储，不要无必要地安装到整台机器；
• 不要为了省事全局忽略服务器证书错误；
• 公司设备、受管设备或涉及证书固定的应用，应先遵守组织安全策略；
• 不再需要 HTTPS 捕获时，可以关闭该功能并移除 Fiddler CA；
• Snapshot、导出文件和截图可能包含账号、Cookie、Token、内网地址及业务数据，分享前必须脱敏。

Fiddler Everywhere 不同版本和许可等级提供的捕获方式、协作功能可能不同，实际使用时应以当前官方文档和产品界面为准。

总结

Chrome 做 Web 性能分析的核心不是“会点录制”，而是把模糊的“慢”变成一条证据链：

用户场景
→ 可量化指标
→ 异常时间段
→ 网络请求 / 主线程任务 / 渲染事件
→ 具体资源或代码
→ 修改后同条件复测

如果是第一次排查，可以记住最短路径：

加载慢：Performance + Network
点击慢：Interactions + Main + Bottom-up
布局跳：Layout shifts + 受影响元素
动画卡：Frames + Main + Rendering
越用越卡：Performance monitor + Memory

性能优化最怕凭感觉。先测量，再定位，再优化，最后复测，才能知道时间是不是花在了真正影响用户的地方。

参考

1. Chrome DevTools：Analyze runtime performance
2. Chrome DevTools：Performance features reference
3. Chrome DevTools：Network features reference
4. Chrome DevTools：Performance monitor
5. Chrome DevTools：Fix memory problems
6. Chrome for Developers：Introduction to Lighthouse
7. web.dev：Web Vitals
8. web.dev：Getting started with measuring Web Vitals
9. Fiddler Everywhere：Introduction
10. Fiddler Everywhere：Capturing modes
11. Fiddler Everywhere：HTTPS settings
12. Fiddler Everywhere：Composer
13. Fiddler Everywhere：Modify traffic with Rules