Performance API通过高精度计时帮助识别性能瓶颈：使用performance.now()可精确测量代码执行时间，相比Date.now()不受系统时间调整影响，精度更高；利用performance.mark()和measure()能结构化标记任务阶段，便于在DevTools中可视化分析各阶段耗时；结合上下文、异常值、统计分析及调用频率，可定位慢函数或“热路径”；适用于复杂计算、DOM操作、用户交互响应、资源处理及第三方脚本影响等前端性能优化场景，为持续优化提供数据支撑。
JavaScript的Performance API，特别是
performance.now()
和
performance.mark()
/
performance.measure()
，提供了一种高精度、毫秒甚至微秒级别的计时能力，远超传统的
Date.now()
。通过这些工具，开发者可以精确地测量代码块或函数执行的耗时，从而识别出应用中的性能瓶颈，为后续的性能优化工作提供坚实的数据支撑，最终提升用户体验。
解决方案
要测量函数执行时间，我们可以利用
performance.now()
来获取当前时间戳，计算两个时间点之间的差值。对于更复杂的场景，
performance.mark()
和
performance.measure()
则能提供更结构化的计时和更丰富的性能数据。
使用
performance.now()
进行简单计时：
这适用于测量单个代码块或函数的总执行时间。它的精度非常高，可以达到亚毫秒级别。
立即学习“Java免费学习笔记（深入）”；
function heavyComputation() { let sum = 0; for (let i = 0; i < 1000000; i++) { sum += Math.sqrt(i); } return sum;}const t0 = performance.now();heavyComputation();const t1 = performance.now();console.log(`heavyComputation took ${t1 - t0} milliseconds.`);// 输出示例: heavyComputation took 3.5670000000000006 milliseconds.
使用
performance.mark()
和
performance.measure()
进行结构化计时：
当需要测量特定任务的多个阶段，或者想在性能时间线（如Chrome DevTools的Performance面板）中可视化这些测量结果时，
performance.mark()
和
performance.measure()
就显得非常有用了。
performance.mark(markName)
会在时间线上创建一个命名的时间点。
performance.measure(measureName, startMark, endMark)
则会计算两个标记点之间的时间，并以指定名称记录下来。
function processData(data) { performance.mark('start_data_processing'); // 模拟数据清洗阶段 let cleanedData = data.map(item => item * 2); performance.mark('data_cleaned'); // 模拟数据转换阶段 let transformedData = cleanedData.filter(item => item > 100); performance.mark('data_transformed'); // 模拟数据存储阶段 // await saveData(transformedData); // 假设这里有异步操作 performance.mark('data_stored'); performance.measure('清洗阶段耗时', 'start_data_processing', 'data_cleaned'); performance.measure('转换阶段耗时', 'data_cleaned', 'data_transformed'); performance.measure('存储阶段耗时', 'data_transformed', 'data_stored'); performance.measure('总处理耗时', 'start_data_processing', 'data_stored'); // 获取所有测量结果 const measures = performance.getEntriesByType('measure'); measures.forEach(m => { console.log(`${m.name}: ${m.duration} ms`); }); // 清除不再需要的标记和测量，避免内存泄漏 performance.clearMarks(); performance.clearMeasures(); return transformedData;}const largeArray = Array.from({ length: 50000 }, (_, i) => i + 1);processData(largeArray);// 输出示例：// 清洗阶段耗时: 0.8500000000000001 ms// 转换阶段耗时: 0.625 ms// 存储阶段耗时: 0.05 ms// 总处理耗时: 1.525 ms
这些数据不仅在控制台中可见，更重要的是，它们会被DevTools的Performance面板捕获，以可视化的方式展现出来，这对于深入分析和定位问题非常有帮助。
performance.now()
performance.now()
与
Date.now()
有何不同？为何推荐使用 Performance API？
说实话，很多人在需要计时的时候，下意识地会想到
Date.now()
。这很自然，因为它简单直观。但如果你真的想做一些严肃的性能分析，那
Date.now()
就显得力不从心了。
Date.now()
返回的是自1970年1月1日00:00:00 UTC（Unix纪元）以来的毫秒数。它的精度通常就是毫秒级，而且它不是单调递增的。什么意思呢？就是说，如果用户的系统时间被手动调整了，或者操作系统通过NTP（网络时间协议）同步了时间，那么
Date.now()
返回的值可能会出现“跳变”，甚至回退。这对于测量时间间隔来说，简直是灾难性的，你会得到负值或者不准确的持续时间。
而
performance.now()
则完全不同。它返回的是一个高精度的时间戳，表示自页面加载（
performance.timing.navigationStart
）以来经过的毫秒数，并且这个时间戳是浮点型的，精度可以达到微秒级别。更关键的是，它是一个单调递增的时间。这意味着它不会受到系统时间调整的影响，始终保持向前流动，非常适合测量时间间隔。想象一下，你正在测量一个动画帧的耗时，如果时间戳突然回退了，那你的测量结果就完全没有意义了。
所以，当我们需要对代码执行时间进行精确、可靠的测量时，
performance.now()
无疑是更优的选择。它提供了更细粒度的数据，并且保证了时间测量的稳定性，这对于识别那些毫秒级别的性能瓶颈至关重要。
如何解读 Performance API 测量到的时间数据，并识别潜在的性能瓶颈？
拿到一堆数字，比如“某个函数执行了15.32ms”，这仅仅是第一步。真正的挑战在于如何从这些数据中看出门道，找出那些拖慢应用整体速度的“罪魁祸首”。这需要一些思考和分析。
首先，上下文是王道。15毫秒对于一个简单的DOM操作可能很慢，但对于一个复杂的数据排序算法或者大规模的Canvas渲染，可能就是可以接受的。所以，你需要知道你测量的这段代码的预期复杂度。
其次，关注异常值和峰值。如果你多次运行同一个函数，发现大多数时候都是1-2ms，但偶尔会跳到10ms甚至更高，那这可能就预示着一些问题。可能是垃圾回收（GC）导致了暂停，或者是某个外部资源（比如网络请求）的延迟影响了后续处理。这时候，你需要更深入地结合DevTools的Performance面板，看看在这些峰值出现的时候，CPU、内存、网络等资源的使用情况。
再来，统计分析不可少。仅仅测量一次的数据可能带有偶然性。在一个真实的应用场景下，函数会被反复调用。所以，收集足够多的样本数据，然后计算平均值、中位数、标准差，会让你对函数的真实性能有一个更全面的认识。平均值能告诉你大致趋势，中位数能排除极端值的影响，而标准差则能揭示性能的波动性。如果标准差很大，说明这个函数的性能很不稳定，这本身就是一个值得优化的点。
还有一点，寻找“热路径”。有些函数本身可能执行得很快，但它们被调用得非常频繁，导致累积的总耗时非常可观。通过Performance API的测量，结合调用栈分析，你可以识别出这些被频繁调用的“热路径”函数。优化这些函数，往往能带来全局性的性能提升。
最后，别忘了迭代和对比。性能优化是一个持续的过程。当你通过测量数据识别出问题并进行优化后，一定要再次测量，对比优化前后的数据。看看你的改动是否真的带来了提升，提升了多少，有没有引入新的问题。有时候，一个优化可能会在某个地方带来提升，但在另一个地方造成回退，这种“副作用”也需要通过数据来发现。
结合实际场景，Performance API 在哪些前端性能优化点上能发挥关键作用？
Performance API 就像一个高精度的“听诊器”，能帮助我们听到前端应用内部那些细微的“心跳声”，从而在很多关键的性能优化点上发挥不可替代的作用。
1. 复杂数据处理与算法优化：当你的应用需要处理大量数据，比如进行复杂的筛选、排序、聚合计算时，这些操作往往是CPU密集型的。通过
performance.mark()
和
performance.measure()
，你可以精确地测量不同算法实现（例如，使用原生方法 vs. 手写循环，或者不同排序算法）的耗时。比如，一个大数据表格的渲染前处理，你可以测量数据转换、过滤、分页等各个阶段的时间，从而找出最慢的环节，并针对性地进行Web Worker分担计算、算法优化或者延迟处理等。
2. DOM操作与渲染性能：前端性能瓶颈的“老生常谈”就是DOM操作。频繁的DOM读写、大量的重排（layout）和重绘（repaint）是导致页面卡顿的主要原因。你可以用Performance API来测量：
批量更新DOM前后的时间，对比一次性更新与多次零散更新的效率。某个复杂组件初次渲染或更新时的耗时，分析虚拟DOM diff算法的效率。滚动事件处理函数中，计算或修改DOM样式所花费的时间，判断是否需要进行节流或防抖优化。例如，测量一个大型列表在滚动时，动态加载和卸载列表项（虚拟滚动）的性能，确保其流畅性。
3. 用户交互响应时间：用户对应用的感知速度，很大程度上取决于交互的响应性。从用户点击一个按钮到界面完成相应更新，这中间的延迟是用户体验的关键。你可以测量：
点击事件处理函数中，从事件触发到所有UI更新完成的总时间。表单提交后，数据验证、网络请求发起、等待响应、到页面反馈的整个流程耗时。动画或过渡效果的每一帧渲染时间，判断是否存在掉帧现象。这些数据能直接告诉你，用户的“等待感”究竟有多强。
4. 资源加载与处理：虽然Performance API主要用于测量JavaScript执行，但它也可以间接帮助分析资源加载后的处理时间。例如，图片加载完成后，如果需要进行Canvas绘制或像素级处理，你可以测量这些处理的耗时。或者，JSON数据从网络获取后，解析和构建数据模型所花费的时间，这对于分析大型API响应的效率非常有用。
5. 第三方脚本与库的影响：在现代前端应用中，引入大量的第三方库和SDK是常态。这些脚本可能会在后台执行一些我们不了解的任务。通过在关键路径上设置
performance.mark()
，你可以观察到在某个第三方库初始化或执行某个功能时，是否对你的核心业务逻辑造成了不必要的延迟。这有助于评估第三方库的性能开销，甚至考虑是否需要延迟加载或替换。
总之，Performance API为我们提供了一个量化的视角去审视代码的运行效率。它不是万能药，不会直接告诉你“哪里错了”，但它能精准地指出“哪里慢了”，这正是性能优化的第一步，也是最关键的一步。通过持续的测量、分析和迭代，我们才能不断打磨出高性能、流畅的用户体验。
以上就是如何通过JavaScript的Performance API测量函数执行时间，以及这些数据在性能调优中的具体分析方法？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521959.html
微信扫一扫 
支付宝扫一扫 
