开发者工具|Performance API 对性能的影响
前些天在群里看到一个问题，打开Devtools和使用Performance API 究竟会对性能有多大影响。
浏览器默认输出的指标不会影响性能，而使用Performance.mark增加埋点则会增加性能开销。
以下是 两位大佬的回答
justjavac
写个 bench 是告诉他，performance api 的影响可以忽略
实现原理不就是 mark 埋点，然后定向统计吗
https://w3c.github.io/user-timing/ https://w3c.github.io/user-timing/ 这个规范只定义了时间度量的2中方式，mark 和 measure，一个是打点，一个是打线。这两个都需要主动调用 api 才能起作用：performance.mark 和 performance.measure比如你度量按钮点击事件的性能，那么需要 performance.mark("button click") 这种加了这断代码 vs 不加这段代码；确实对性能有影响
但是。。。这是规范定义的，然而浏览器的实现中，资源的加载是默认会收集性能数据的，不需要自己加代码来收集。你开不开 devtools，都会收集，所以，这个是没有性能影响的
你直接调用 performance.getEntries() 和同类的 api，可以直接拿到资源加载的性能数据，这些是浏览器主动打点的
如果你手动调用了 performance.mark，那么引擎会额外再为你打点，采集你需要的性能指标
再加一条，performance.memory 这个 api 不是规范定义的，而是 chrome 自己加的
你告诉领导，1. 网络请求的性能数据是浏览器自动收集的，performance api 不会影响性能；2. 如果手动加 mark 采集额外的数据，会有影响，但是可以忽略不计。然后你再写一个 bench 数据，证明 mark 对性能的影响可以忽略不计
心态崩了
这个厉害了……主要是 blink 里打点的，不止一处，请求加载会由 blink/renderer/platform/loader/fetch/url_loader
/web_resource_request_sender.cc 去做，实际是 mojom 到 net 进程了，但是收集打点信息会有一部分在这里。然后 navigation 时候 也有一些打定义 会在 third_party/blink/renderer/core/loader/document_load_timing.h document load 里做，具体会在事件触发后设置 base::TimeTicks.Now() 进行记录。非要说性能……应该没啥影响，这玩意都没去 net 进程打点，实际上 ipc 通信时间都给加里了，应该比实际 net 处理的时间还要多那么一点点……