JS 浏览器网络请求分析 - 使用 Performance Timeline 测量请求时序-js教程-PHP中文网

答案：Performance Timeline API 提供浏览器网络请求及页面性能的详细时序数据，通过 PerformanceResourceTiming 可分析 DNS、TCP、TLS、TTFB 等阶段耗时，定位瓶颈；结合 navigation、paint、longtask 等类型，可全面监控页面加载、渲染、交互等性能指标；使用 PerformanceObserver 实时收集数据，按关键指标聚合分析，实现从感知到量化的性能优化。

js 浏览器网络请求分析 - 使用 performance timeline 测量请求时序

在前端性能优化的战场上，要真正把控用户体验，精准测量浏览器网络请求的时序是核心。

Performance Timeline API

登录后复制

，特别是其中的

PerformanceResourceTiming

登录后复制

接口，提供了一个原生的、深入的视角，让我们能够像外科医生一样，剖析每个网络请求从发起、DNS解析、TCP连接、TLS握手，直到数据传输完成的每一个微小环节。它不是一个抽象的概念，而是浏览器真实运行状态的镜子，通过它，我们能直接看到哪些环节拖慢了加载速度，哪些资源成了瓶颈。

解决方案

要深入分析 JavaScript 浏览器网络请求时序，我们主要依赖

window.performance

登录后复制

对象提供的

Performance Timeline API

登录后复制

。最直接的方式是使用

performance.getEntriesByType('resource')

登录后复制

来获取所有已完成的资源请求（包括图片、CSS、JS、XHR等）。

// 获取所有资源请求的性能数据
const resourceEntries = performance.getEntriesByType('resource');

resourceEntries.forEach(entry => {
  // 过滤掉非HTTP/HTTPS请求，或者根据需要只关注特定类型的请求
  if (!entry.name.startsWith('http')) {
    return;
  }

  console.log(`--- 请求: ${entry.name} ---`);
  console.log(`开始时间 (fetchStart): ${entry.fetchStart.toFixed(2)}ms`);
  console.log(`DNS 查询耗时: ${(entry.domainLookupEnd - entry.domainLookupStart).toFixed(2)}ms`);
  console.log(`TCP 连接耗时: ${(entry.connectEnd - entry.connectStart).toFixed(2)}ms`);

  if (entry.secureConnectionStart > 0) {
    console.log(`TLS/SSL 握手耗时: ${(entry.connectEnd - entry.secureConnectionStart).toFixed(2)}ms`);
  }

  console.log(`请求发起至首字节时间 (TTFB): ${(entry.responseStart - entry.requestStart).toFixed(2)}ms`);
  console.log(`内容下载耗时: ${(entry.responseEnd - entry.responseStart).toFixed(2)}ms`);
  console.log(`总耗时: ${(entry.duration).toFixed(2)}ms`);
  console.log(`----------------------------------`);
});

// 如果需要实时监控，可以使用 PerformanceObserver
const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    if (entry.entryType === 'resource' && entry.name.startsWith('http')) {
      // 在这里处理新的资源请求数据
      console.log('新资源请求完成:', entry.name, entry.duration);
    }
  });
});
observer.observe({ type: 'resource', buffered: true });

登录后复制

通过这段代码，我们能拿到每个资源的详细时间戳，然后通过简单的减法运算，就能算出各个阶段的耗时。这比在 DevTools 里手动查看要高效得多，尤其是在需要自动化收集和分析大量数据时。

如何解读 PerformanceEntry 中的各项时间戳，识别网络瓶颈？

当我们拿到

PerformanceResourceTiming

登录后复制

对象时，会看到一系列时间戳属性，这些是理解网络请求生命周期的关键。在我看来，这些时间点就像是请求在不同关卡打卡，记录了它何时到达，何时离开。

```
fetchStart
```
登录后复制
: 这是请求开始获取资源的时间点。你可以把它看作是浏览器决定“我要去拿这个东西了！”的那个瞬间。
```
domainLookupStart
```
登录后复制
和
```
domainLookupEnd
```
登录后复制
: 这两者之间的差值就是 DNS 解析的耗时。如果这个值特别大，那很可能你的用户在等待域名解析上花了很多时间，这通常发生在首次访问或 DNS 服务器响应慢的情况下。
```
connectStart
```
登录后复制
和
```
connectEnd
```
登录后复制
: 这段是 TCP 连接建立的耗时。如果你的服务器离用户很远，或者网络不稳定，这里就会体现出来。
```
secureConnectionStart
```
登录后复制
: 如果是 HTTPS 请求，这个时间点表示 TLS/SSL 握手开始。
```
connectEnd - secureConnectionStart
```
登录后复制
就是 TLS 握手的耗时。这块儿要是慢了，通常意味着服务器的 SSL 证书配置或者网络环境有问题。
```
requestStart
```
登录后复制
: 浏览器发出 HTTP 请求的第一个字节的时间。
```
responseStart
```
登录后复制
: 浏览器接收到响应的第一个字节的时间。
```
responseStart - requestStart
```
登录后复制
就是我们常说的 TTFB (Time To First Byte)，它包含了服务器处理请求和网络传输首字节的时间。TTFB 高通常意味着服务器响应慢或者网络延迟大。
```
responseEnd
```
登录后复制
: 浏览器接收到最后一个字节的时间。
```
responseEnd - responseStart
```
登录后复制
就是内容下载的耗时。这个值主要受资源大小和用户带宽影响。
```
duration
```
登录后复制
: 整个请求从
```
fetchStart
```
登录后复制
到
```
responseEnd
```
登录后复制
的总耗时。

识别网络瓶颈，其实就是看这些时间段中哪个特别长。比如，我曾经遇到一个项目，发现很多图片加载的

domainLookupEnd - domainLookupStart

登录后复制

异常高，一查才知道是 CDN 配置有问题，导致 DNS 解析频繁回源或者解析效率低下。又或者，如果

responseStart - requestStart

登录后复制

很高，那就得去后端看看接口是不是有慢查询，或者是不是服务器负载过高。这些数据提供了一个非常具体、可量化的诊断依据，远比“页面有点慢”这样的描述有价值得多。

除了网络请求时序，Performance Timeline 还能提供哪些有价值的性能数据？

Performance Timeline 的强大之处远不止于网络请求。它是一个统一的接口，能让你从多个维度去衡量和优化前端性能。除了

resource

登录后复制

类型，我们还能获取到：

```
navigation
```
登录后复制
类型：这提供了整个页面加载的详细时序数据，比如
```
domContentLoadedEventStart
```
登录后复制
(DOM 内容加载完成的时间)、
```
loadEventStart
```
登录后复制
(页面所有资源加载完成的时间)。通过分析这些，我们能知道页面何时可交互、何时完全加载，这对于衡量用户体验至关重要。
```
paint
```
登录后复制
类型：这个就更直观了，它能告诉我们
```
first-contentful-paint
```
登录后复制
(首次内容绘制) 和
```
largest-contentful-paint
```
登录后复制
(最大内容绘制) 的时间。这两个指标是衡量用户感知加载速度的核心，LCP 更是 Core Web Vitals 的重要组成部分。我个人觉得，LCP 的数据能直接反映用户“看到”页面主要内容的速度，这比纯粹的技术指标更能打动人。
```
longtask
```
登录后复制
类型：这个类型非常有用，它会记录所有耗时超过 50 毫秒的任务。JS 主线程长时间阻塞是导致页面卡顿、响应慢的主要原因。通过
```
longtask
```
登录后复制
，我们能定位到那些“罪魁祸首”的脚本执行，从而进行优化，比如拆分任务、使用 Web Workers 等。
```
event
```
登录后复制
类型：可以追踪用户交互事件（如点击、输入）的耗时，这有助于发现事件处理函数中的性能问题。
```
layout-shift
```
登录后复制
类型：这个是衡量页面布局稳定性的，如果用户在阅读或点击时，页面元素突然移动，那用户体验会很差。
```
layout-shift
```
登录后复制
能帮助我们找出导致这种不稳定性发生的时间点和原因。

在我看来，Performance Timeline 就像一个多功能的诊断仪，它不只看发动机（网络），也看车身（渲染）、看驾驶员操作（交互）。结合这些数据，我们能构建一个更全面的性能视图，而不是只盯着某个单一指标。

Text Mark

处理文本内容的AI助手

查看详情

在实际项目中，如何高效地收集和分析这些性能数据？

在实际项目中，高效地收集和分析 Performance Timeline 数据，这可不是简单地在控制台里跑几行代码就能搞定的。这涉及到数据量、实时性、以及如何从海量数据中提炼出有价值的信息。

首先，对于数据收集，我通常会倾向于使用

PerformanceObserver

登录后复制

。

getEntriesByType

登录后复制

固然方便，但它拿到的是一个快照，对于持续运行的页面，或者需要实时监控新加载的资源，

PerformanceObserver

登录后复制

才是王道。它可以监听特定类型的性能事件，并在事件发生时异步回调，这样我们就能持续地收集数据，而不是等到页面加载完才去抓取。

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    // 根据 entry.entryType 和 entry.name 进行分类处理
    if (entry.entryType === 'resource') {
      // 收集资源加载数据
      sendToAnalytics({
        type: 'resource_timing',
        url: entry.name,
        duration: entry.duration,
        // ... 其他关键时间戳
      });
    } else if (entry.entryType === 'paint' && entry.name === 'first-contentful-paint') {
      // 收集 FCP 数据
      sendToAnalytics({
        type: 'fcp',
        time: entry.startTime,
      });
    }
    // ... 其他类型的数据
  });
});
observer.observe({ entryTypes: ['resource', 'paint', 'longtask', 'navigation'], buffered: true });

function sendToAnalytics(data) {
  // 实际项目中，这里会将数据发送到后端或第三方 RUM 服务
  console.log('发送到分析系统:', data);
  // fetch('/api/performance-data', { method: 'POST', body: JSON.stringify(data) });
}

登录后复制

数据收集上来后，关键在于分析。我的经验是，不要试图把所有数据都存下来，那会是天文数字。我们应该关注关键指标，并对数据进行聚合。例如，对于资源请求，我们可以只记录加载时间最长的 N 个资源，或者对同域名下的资源进行平均耗时统计。对于 FCP、LCP 这些核心指标，可以直接上报其值。

在数据分析阶段，我会考虑以下几点：

数据过滤与清洗： 有时候会有些异常数据，比如网络请求失败但仍有记录，或者一些不重要的第三方脚本。需要设定规则进行过滤。
用户分群： 性能表现往往因用户网络环境、设备性能而异。将用户按地区、网络类型（4G/Wi-Fi）、设备型号等进行分群，能让我们更精准地定位问题。比如，发现某个地区的用户普遍 LCP 很高，那可能就是 CDN 节点的问题。
趋势分析： 单点数据意义不大，我们需要观察性能指标随时间的变化趋势。如果某天某个指标突然恶化，那很可能是有新的部署或者外部服务出了问题。
可视化： 原始的 JSON 数据是枯燥的，通过图表（如直方图、箱线图、热力图）将数据可视化，能帮助我们快速发现异常和趋势。自己搭建一个简单的仪表盘，或者集成到现有的监控系统，都是不错的选择。

这个过程，其实就是从“我知道页面慢”到“我知道具体哪个请求在哪个环节慢了，以及影响了多少用户”的转变。它要求我们不仅会写代码，还要懂一点数据分析和统计学。这才是真正把性能优化从玄学变成科学的路径。

以上就是JS 浏览器网络请求分析 - 使用 Performance Timeline 测量请求时序的详细内容，更多请关注php中文网其它相关文章！