PerformanceObserver使用教程：性能监控与瓶颈分析

小伙伴们对文章编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《Performance Observer怎么用？性能监控与瓶颈分析全解析》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

Performance Observer通过创建实例并监听entryTypes，能非侵入式捕获longtask、paint、layout-shift等关键性能指标，解决传统方法无法全面监控运行时瓶颈的问题。

Performance Observer 提供了一种非侵入式、事件驱动的方式来收集浏览器运行时性能数据，它让我们能以极高的粒度监控各种性能指标，从而精准定位并解决Web应用中的瓶颈。它就像一个高效的“性能侦察兵”，默默地在后台记录着页面上发生的一切，将那些传统方法难以捕捉的性能事件清晰地呈现出来。

解决方案

要通过Performance Observer监控性能指标，核心在于创建一个PerformanceObserver实例，并告诉它你对哪些类型的性能条目感兴趣。一旦有符合条件的性能事件发生，你的回调函数就会被触发，你就能拿到这些宝贵的数据。

我们首先实例化PerformanceObserver，并传入一个回调函数。这个函数会在新的性能条目被记录时执行。接着，调用observer.observe()方法，指定你想要观察的entryTypes。

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    // 这里处理每个性能条目
    console.log(`${entry.entryType}: ${entry.name}, duration: ${entry.duration}ms`);

    // 举例：如果是长任务，可以进一步分析
    if (entry.entryType === 'longtask') {
      console.warn('发现一个长任务:', entry);
    }
    // 举例：如果是布局偏移，可以记录
    if (entry.entryType === 'layout-shift') {
        console.log('布局偏移:', entry);
    }
  });
});

// 观察多种性能条目类型
observer.observe({
  entryTypes: ['mark', 'measure', 'navigation', 'resource', 'longtask', 'element', 'event', 'layout-shift', 'paint'],
  buffered: true // 即使在观察器注册之前发生的条目也会被报告
});

// 你也可以随时取消观察
// observer.disconnect();

通过entryTypes数组，我们可以指定想要监控的性能事件类型，比如页面加载（navigation）、资源加载（resource）、自定义标记（mark）、耗时长的JavaScript任务（longtask）、页面渲染（paint）、布局偏移（layout-shift）等等。buffered: true这个选项挺重要的，它能确保即使在PerformanceObserver实例化之前已经发生的性能事件，也能被捕捉到。我个人觉得，这种异步、非阻塞的数据收集方式，是它比performance.now()等传统方法强大得多的地方。它不会影响页面的正常运行，却能提供极其丰富的数据细节。

为什么传统的性能测量方法不足以应对现代Web应用的挑战？

说实话，以前我们经常用console.time()、performance.now()或者简单地监听DOMContentLoaded和window.onload来测量性能。这些方法在某些场景下确实有用，比如测量一段特定代码的执行时间，或者判断页面首次内容渲染的大致时间。但现代Web应用越来越复杂，单页应用（SPA）盛行，用户交互也变得更加频繁和动态。

这些传统方法最大的局限性在于它们的“点状”和“侵入性”。performance.now()只能告诉你某个时刻到现在的时间差，你得手动在代码里埋点；console.time()也差不多。它们无法自动捕获浏览器自身产生的各种性能事件，比如哪些资源加载慢了、哪些长任务阻塞了主线程、页面发生了多少次布局偏移，甚至用户输入延迟了多少。更别提像首次内容绘制（FCP）、最大内容绘制（LCP）、累积布局偏移（CLS）这些核心Web生命周期指标了，它们是浏览器内部计算出来的，不是简单地计时就能得到的。

而且，如果要在整个应用中到处埋点来收集这些数据，代码会变得非常臃肿和难以维护。这就像你试图用手电筒去照亮一个巨大的黑屋子，只能看到局部，却无法获得全局的、连贯的视野。Performance Observer则提供了一个统一的、自动化的接口，让我们可以“订阅”这些事件，大大简化了性能数据的收集工作，并且能捕捉到更深层次的用户体验指标。

Performance Observer能捕获哪些关键性能指标，它们分别代表什么？

Performance Observer能捕获的性能指标种类非常丰富，每一种都指向了Web应用性能的不同维度，对于识别和解决运行时瓶颈至关重要。我个人觉得，理解这些entryTypes背后的含义，是利用好Performance Observer的关键。

• longtask (长任务)：这是我最关注的类型之一。它代表了在主线程上执行时间超过50毫秒的任务。长时间的JavaScript执行、复杂的渲染或布局计算都可能导致长任务。当用户感觉页面“卡顿”或“无响应”时，longtask往往是罪魁祸首。监控它能帮助我们找出是哪段代码或哪个第三方脚本阻塞了主线程，从而优化JavaScript执行。
• paint (绘制)：这个类型能捕捉到浏览器绘制事件，其中最常用的是first-contentful-paint (FCP) 和 largest-contentful-paint (LCP)。FCP表示页面上第一个内容（文本、图片等）渲染出来的时间，LCP则代表了视口内最大的内容元素完成渲染的时间。它们直接关联着用户的感知加载速度，是衡量页面加载体验的重要指标。
• layout-shift (布局偏移)：这个类型与累积布局偏移（CLS）密切相关。它记录了页面元素在视觉上发生位置或大小变化的事件，通常是由于异步加载的资源、动态插入的内容或CSS样式变化引起的。无序的布局偏移会严重损害用户体验，导致用户误触或视觉混乱。监控它能帮助我们优化页面的稳定性。
• resource (资源)：它提供了页面加载的所有资源的详细计时信息，包括图片、CSS、JavaScript文件、字体等。你可以看到每个资源的加载时间、大小、请求和响应时间等。通过分析resource条目，我们可以发现加载缓慢的资源、未优化的图片、过大的JavaScript包，或者网络请求中的瓶颈。
• navigation (导航)：这个类型提供了页面导航（即整个页面加载过程）的详细计时数据，包括重定向时间、DNS查询时间、TCP连接时间、请求响应时间等。它能帮助我们全面了解页面从用户发起请求到完全加载的整个生命周期。
• event (事件)：它记录了用户交互事件（如点击、按键）的处理时间。结合longtask，可以帮助我们分析输入延迟（FID）问题，即从用户与页面交互到浏览器实际响应所需的时间。
• mark 和 measure (标记和测量)：这两个是自定义的性能条目。mark用于在代码中的特定点打上时间戳，measure则用于测量两个mark之间或一个mark到当前时间的时间间隔。它们对于测量特定业务逻辑、组件渲染或用户流程的性能非常有用，能帮助我们深入了解应用内部的性能表现。

如何利用Performance Observer的数据进行性能分析和优化决策？

拿到这些丰富的数据之后，最关键的是怎么“读”懂它们，并将其转化为实际的优化行动。这不仅仅是收集数据，更是一个分析、假设、验证的循环过程。

首先，数据收集与上报是基础。在实际应用中，我们会将Performance Observer捕获到的数据进行聚合和匿名化处理，然后发送到后端服务或第三方性能监控平台（如Google Analytics、Sentry、Datadog等）。这样可以对大量用户的数据进行统计分析，发现普遍存在的性能问题，而不仅仅是开发者自己机器上的表现。

接着是识别瓶颈。

• 长任务（longtask）分析：如果发现大量的longtask，特别是那些持续时间很长的，我们需要深入检查相关的JavaScript代码。这可能意味着有复杂的计算、DOM操作、或者第三方脚本在主线程上执行了过长时间。优化方向通常是代码拆分（code splitting）、Web Workers、Debounce/Throttle事件处理、或者对耗时操作进行异步化。我记得有一次，我们发现longtask报告里总有一些意想不到的第三方广告脚本，这才意识到它们才是拖慢页面响应的元凶。
• 资源加载（resource）分析：通过分析resource条目，我们可以看到哪些图片、字体或脚本文件加载时间过长。这可能提示我们需要优化图片大小、使用下一代图片格式、启用CDN、配置更激进的缓存策略，或者对JavaScript和CSS进行代码压缩和Tree Shaking。
• 布局偏移（layout-shift）分析：如果layout-shift分数很高，说明页面稳定性有问题。这通常是由于图片没有设置width和height属性导致加载后跳动、动态插入内容、或者CSS动画/转换触发了布局。解决办法包括为图片预留空间、使用aspect-ratio、避免在动画中使用transform以外的属性、以及确保内容在加载时有占位符。
• 自定义指标（mark/measure）分析：这些数据能帮助我们深入了解特定业务流程的性能。比如，测量用户从点击按钮到数据加载完成的时间，或者某个复杂组件的渲染耗时。通过这些自定义指标，我们可以针对性地优化业务逻辑，比如改进API响应速度、优化数据处理流程或组件渲染效率。

最后，制定优化策略并验证效果。基于数据分析，我们会提出具体的优化方案，实施后，再通过Performance Observer持续监控，对比优化前后的数据，验证改进是否有效。这种基于数据驱动的迭代优化，是提升Web应用性能最可靠的途径。它让我们从“凭感觉”优化，转变为“用数据说话”，让每一次性能改进都有理有据。

以上就是《PerformanceObserver使用教程：性能监控与瓶颈分析》的详细内容，更多关于的资料请关注golang学习网公众号！