window.addEventListener => {
  const timing = performance.timing;
  // 计算DNS查询耗时
  const dnsTime = timing.domainLookupEnd - timing.domainLookupStart;
  // 计算TCP连接耗时
  const tcpTime = timing.connectEnd - timing.connectStart;
  // 计算白屏时间
  const whiteScreenTime = timing.responseStart - timing.navigationStart;
  // 计算DOM解析耗时
  const domParseTime = timing.domComplete - timing.domInteractive;
  console.log;
  console.log;
  console.log;
});

对于 LCP、FID 和 CLS 这些新指标，`performance.timing` Yi经无Neng为力了。我们需要使用geng现代的 `PerformanceObserver`。它允许我们被动地监听特定类型的事件，一旦浏览器记录了这些数据，回调函数就会被触发。

比如我们要监听 LCP：

let lcpValue = 0;
const lcpObserver = new PerformanceObserver => {
  const entries = list.getEntries;
  // LCP 可Neng会随着页面加载不断geng新，取Zui后一个值
  const lastEntry = entries;
  lcpValue = lastEntry.renderTime || lastEntry.loadTime;
  console.log;
  // 上报逻辑...
});
lcpObserver.observe;
// 用户发生交互后停止监听，避免数据不准
window.addEventListener => {
  lcpObserver.disconnect;
}, { once: true });

对于 CLS 的计算稍微复杂一点，因为它需要排除用户输入引起的布局偏移，并且需要将短时间内发生的偏移累加起来作为一个会话窗口。

性Neng监控关注的是“快不快”，而错误监控关注的是“稳不稳”。一个崩溃的页面性Neng再好也没有意义。

Zui基础的是使用 `window.onerror`。它Neng捕获大部分的运行时错误和语法错误。

window.onerror = function {
  // 将错误信息组装成对象
  const errorInfo = {
    type: 'js_error',
    msg: message,
    file: source,
    line: lineno,
    col: colno,
    stack: error ? error.stack : 'No stack trace'
  };
  // 发送至后端日志系统
  // sendToBackend;
};

现在的代码中 Promise 使用非常频繁，`window.onerror` 捕获不到 Promise 内部未处理的 rejection。我们需要监听 `unhandledrejection` 事件。

window.addEventListener => {
  console.warn;
  // 上报 Promise 错误
});

有时候图片挂了或者 CDN 的脚本 404 了这些也需要监控。我们Ke以利用 `window.addEventListener` 的捕获阶段，或者针对特定元素绑定 `onerror` 事件。

这就hen讽刺了：我们为了监控性Neng，结果监控代码本身影响了性Neng。为了避免这种情况，数据上报策略必须精心设计。

不要在页面加载的关键路径上同步发送数据。Zui推荐的方式是使用 `navigator.sendBeacon`。这个 API 专为统计数据设计，它支持异步发送，并且即使页面关闭了浏览器也会尽力保证数据发送成功。

function sendData {
  if  {
    navigator.sendBeacon);
  } else {
    // 降级方案：使用 fetch 或 XMLHttpRequest
    fetch, method: 'POST', keepalive: true });
  }
}

Ru果每一个微小的操作dou发一个请求，服务器压力会hen大，网络带宽也会被浪费。通常的Zuo法是：在内存中维护一个缓存队列，当数据积累到一定数量，或者每隔一定时间，再统一打包发送一次。

对于流量巨大的应用，全量上报可Neng会撑爆数据库。我们Ke以根据用户 ID 的哈希值进行采样，比如只监控 10% 的用户流量。对于错误类数据，通常建议全量上报；而对于性Neng指标，采样则是一个经济实惠的选择。

采集到了数据，只是完成了万里长征的第一步。数据Ru果不被分析，就只是存储服务器里的电子垃圾。

我们需要将数据可视化。通过折线图展示 LCP、FID 等指标随时间的变化。比如你Ke以清晰地kan到，在周三下午发布新版本后LCP 突然飙升了 500ms。这就是性Neng退化时段，也是你找开发同事“喝茶”的Zui佳时机。

平均数往往会掩盖问题。我们需要支持按地区、浏览器、设备类型、网络类型进行分组统计。也许你会发现，整体性Nenghen好，但在 4G 网络下的 Android 设备上，加载时间慢得令人发指。这时候，针对性的优化就变得有据可依。

基于监控发现的问题，我们Ke以采取以下措施：

代码优化压缩 JS/CSS，移除死代码，减少包体积。

资源加载使用 `defer` 或 `async` 异步加载非关键脚本；对图片进行懒加载和 WebP 格式转换；利用 HTTP/2 的多路复用特性。

缓存策略合理设置强缓存和协商缓存，利用 Service Worker 离线缓存资源。

服务端渲染对于首屏要求极高的页面SSR Ke以显著缩短 FCP 和 LCP。

前端性Neng监控是一个持续迭代的过程，而不是一劳永逸的项目。从底层的 API 采集，到中间的数据传输，再到后端的存储分析，每一个环节dou充满了细节和挑战。

不要迷信工具，要相信数据。当你kan到监控平台上的曲线一天天变平，P99 的耗时一点点下降，那种成就感是无与伦比的。毕竟在这个快节奏的互联网世界里快人一步，往往就意味着胜人一筹。希望这篇文章Neng为你搭建自己的前端性Neng监控体系提供一些有价值的参考。