企业官网建设流程全解析

1. 为什么我决定不用现成监控工具，而是自己手搓一套HTML性能监控

做前端时间长了，总会在某个深夜被一个问题击中：你的页面在开发环境跑得飞快，一上生产就有人反馈卡顿、白屏、图片半天出不来。你打开本机浏览器控制台看了一圈，Network面板绿油油的，Performance面板也看不出个所以然，因为你复现不了用户的环境，还原不了用户的操作路径。我自己的项目就遇到过这种情况：明明改了一版渲染逻辑，本地测试怎么点都流畅，结果上线后运营同事的反馈是"页面经常卡死，点了没反应"。最气人的是，等我去他工位看的时候，页面又表现正常了。

那阵子我试过引入第三方的性能监控SDK，但折腾一圈下来发现几个问题：一是上报数据全走对方服务器，敏感业务信息混在网络请求里，心里始终不踏实；二是想按业务维度自定义埋点特别费劲，对方给的SDK封装层级太深，想查一个自定义字段得翻半天文档；三是最关键的，这些工具能告诉我"页面慢了"，但很难告诉我"到底慢在哪一行渲染逻辑、哪一个资源请求"。

所以我最后决定：自己手搓一套轻量级的HTML性能监控方案，基于浏览器原生API，不依赖任何第三方库，把渲染性能和资源加载这两条主线实时检测、采集、上报、告警全部打通。这篇文章就把完整的实现思路和踩坑过程写出来，适合那些不想被臃肿SDK绑架、希望自己掌控监控数据的团队参考。我默认读者有基本的JavaScript功底，知道Performance API的一般用法，但不需要有很深的浏览器底层知识——我会把原理掰开揉碎了讲。

先放结论：这套方案我用了大半年，上线后成功定位过三个靠人工完全排查不出来的性能问题——包括一个隐藏得很深的第三方脚本导致的连续长任务卡顿，还有一个优先级配置错误导致的关键资源被延迟加载。整个监控包压缩后不到6KB，对页面自身的性能损耗可以忽略不计。

2. 监控指标选型：渲染性能和资源加载到底该盯哪几个数

做监控的第一步不是写代码，而是搞明白"要监控什么"。盲目地把Performance面板里的指标全采一遍，最后只会得到一堆无法决策的数字。我根据自己的项目场景，把监控目标收敛成两大类五个核心指标。

2.1 渲染性能：FPS不只是游戏才需要

很多前端同学觉得FPS是游戏领域的概念，网页无所谓。实际上浏览器渲染页面就是一个逐帧绘制的过程，每一帧从构建DOM、计算样式、布局、绘制到合成，任何一个环节被长任务阻塞，用户感知就是"卡了一下"。所以FPS是渲染性能最直观的度量。

但直接采样FPS有个问题：主线程空闲时页面并不会主动刷新帧，这就导致"空闲时FPS为0"和"卡死时FPS为0"会混在一起。所以实际操作时我会同时统计长任务（Long Tasks）——凡是主线程被同步任务连续占用超过50毫秒，就算一次长任务。50毫秒这个阈值不是拍脑袋定的，而是因为浏览器需要保证页面在100毫秒内对用户输入做出响应，超过50毫秒的任务说明渲染主线程被阻塞了。

这个长任务指标有一个非常典型的应用场景：如果页面在滚动时出现"一顿一顿"的感觉，观察一下长任务的时间戳，通常能定位到是某个事件回调或者布局抖动导致的。我后面会在监控面板里把FPS和长任务放在同一个时间轴里看，这里先卖个关子。

2.2 资源加载：每一个请求的耗时拆解才是优化的依据

资源加载监控的颗粒度很关键。只看"这个接口耗时800ms"远远不够，你要能拆出DNS解析时间、TCP连接时间、TLS握手时间、TTFB（首字节时间）、内容传输时间，才能判断瓶颈在服务端还是网络本身。举个实际例子：有个接口TTFB高达600ms，但下载内容只有12KB只花了几十毫秒，显然瓶颈在服务端处理或者网络延迟，而不是前端资源过大——这时候你去压缩图片是没用的。

另一个被很多人忽视的点是资源加载失败事件。Performance API能拿到所有成功资源的性能数据，但加载失败（比如404、超时、跨域被拦）的资源是拿不到完整性能条目的，只能通过监听window.addEventListener('error', ..., true)捕获阶段来获取。错误和性能分开两个通道采集，最后汇总上报，否则你会发现"资源加载成功率"这个指标永远都是100%，因为失败的压根没进统计。

2.3 核心Web指标：LCP、CLS、INP怎么融进来

如果要让业务方听懂监控数据，纯讲FPS他们没概念，讲LCP（最大内容绘制）、CLS（布局偏移）、INP（交互延迟）他们更容易理解"用户体感"。这三个指标是Core Web Vitals的核心，Chrome的体验评分用的就是这一套。

我在设计监控的时候就给这三个指标留了独立采集通道：

这三个原生PerformanceObserver监听类型除了layout-shift需要在页面生命周期内持续观察，其他两个在首次上报后就可以断开连接，减少对性能检测本身的干扰。

3. FPS、长任务与卡顿检测：手搓渲染监控的三板斧

先上核心实现思路，再说为什么这么设计。渲染性能检测我分了三个层次：FPS帧率采样、长任务监听、卡顿时段标记。层次的划分依据是数据可信度——单看任何一个指标都容易误判，三个指标交叉印证才靠谱。

3.1 FPS采样：requestAnimationFrame的正确用法

FPS的基本采样思路是：requestAnimationFrame（以下简称rAF）会在每次浏览器重绘前执行回调，记录两次回调之间的时间间隔，如果间隔大于某个阈值，说明这一帧的超时周期内存在渲染卡顿。

class FpsSampler { constructor(options = {}) { this.sampleInterval = options.sampleInterval || 1000; // 每秒统计一次 this.intervalThreshold = options.intervalThreshold || 100; // 帧间隔超过100ms记一次卡顿 this.onFrameData = options.onFrameData || (() => {}); this.paused = false; this.frames = 0; this.longFrameCount = 0; this.maxFrameInterval = 0; this.frameTimeSum = 0; this.lastTimestamp = null; this.timerId = null; } start() { this.lastTimestamp = performance.now(); this.timerId = setInterval(() => { const now = performance.now(); const fps = this.frames * 1000 / (now - this.frameStartTime); this.onFrameData({ fps: Math.round(fps * 10) / 10, longFrameCount: this.longFrameCount, maxFrameInterval: Math.round(this.maxFrameInterval), avgFrameInterval: Math.round(this.frameTimeSum / this.frames) }); this.frames = 0; this.longFrameCount = 0; this.maxFrameInterval = 0; this.frameTimeSum = 0; this.lastTimestamp = now; }, this.sampleInterval); this.tick = this.tick.bind(this); requestAnimationFrame(this.tick); } tick(timestamp) { if (this.paused) { return; } if (this.lastTimestamp) { const interval = timestamp - this.lastTimestamp; this.frames += 1; this.frameTimeSum += interval; if (interval > this.intervalThreshold) { this.longFrameCount += 1; } if (interval > this.maxFrameInterval) { this.maxFrameInterval = interval; } } this.lastTimestamp = timestamp; requestAnimationFrame(this.tick); } pause() { this.paused = true; } resume() { this.paused = false; this.lastTimestamp = performance.now(); requestAnimationFrame(this.tick); } }

几个代码细节说明一下：

为什么用setInterval做每秒结算而不是用rAF的递归：rAF的回调频率本身是由刷新率决定的，你没法保证正好每秒触发一次，所以让rAF只负责记录帧数据，setInterval负责定时汇总上报，两者的职责分离。

为什么把长帧阈值卡在100ms：前面提到过50ms是长任务的标准，但帧间隔100ms意味着这一帧的耗时接近两帧的预算，视觉上已经有明显掉帧了。阈值设置太敏感会产生大量噪音数据，设太宽又漏掉早期卡顿，100ms是我在自己项目里调出来的比较平衡的值。

页面前后台切换的坑：浏览器为了省电，页面切到后台时会自动降低rAF频率甚至停止触发。如果后台的rAF回调不触发，lastTimestamp一直停留在旧时间戳，等切回前台时第一帧的间隔会异常巨大。所以上面代码中start()方法里对lastTimestamp重置，同时真正常跑的时候还要监听visibilitychange事件来做暂停和恢复。

document.addEventListener('visibilitychange', () => { if (document.hidden) { fpsSampler.pause(); } else { fpsSampler.resume(); } });

这里有个容易漏掉的点：后台计时和前台计时要完全隔离，不然后台的时间会被算进maxFrameInterval，导致误报"页面卡死"。我就因为这个假数据排查了一下午，最后发现是切了会儿后台标签页没切回来。

3.2 长任务监听：PerformanceObserver的长期观察模式

FPS样本是概率采样，每一帧是否被记录到取决于rAF是否被调度。但渲染主线程如果被一个长任务阻塞，这段时间的rAF回调会被延后甚至丢弃，FPS采样会留下盲区。所以光靠FPS不够，必须叠加Long Tasks的精确事件。

class LongTaskMonitor { constructor() { this.taskList = []; this.observer = null; this.isWatching = false; } start() { if (!('PerformanceObserver' in window)) { console.warn('[PerfMonitor] 当前浏览器不支持PerformanceObserver'); return; } try { this.observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { // Long Task 的 entry 类型是 'longtask'，duration通常是50ms+ this.taskList.push({ startTime: entry.startTime, duration: entry.duration, attribution: entry.attribution || [] }); } }); this.observer.observe({ entryTypes: ['longtask'] }); this.isWatching = true; } catch (e) { console.error('[PerfMonitor] 长任务观察器初始化失败:', e); } } getReport() { // 返回最近一小时内所有长任务，并按耗时降序排列 const now = performance.now(); const recentTasks = this.taskList.filter(t => now - t.startTime < 3600000); return recentTasks.sort((a, b) => b.duration - a.duration); } clear() { this.taskList = []; } }

长任务的attribution字段值得专门解释：在Chrome里，entry.attribution[0]会告诉你这个长任务是由哪个容器或脚本触发的，包括containerName、containerSrc、containerType这些信息。这对定位"罪魁祸首"非常有用。不过Safari和Firefox对attribution的支持还很有限，跨浏览器时要做好降级——没有attribution就用entry.startTime和duration做时段对齐，配合FPS时间轴来人工判断。

说一个我用attribution揪出真凶的案例。某次监控面板显示每30秒就会稳定出现一次500ms+的长任务，但定位不到具体来源。我看attribution里的containerSrc，指向了一个第三方数据上报SDK的某个方法，顺藤摸瓜发现是它的心跳检测里写了个循环遍历全部DOM节点做标记计算。用户量大了之后这个遍历越来越慢。如果当时只有FPS数据，我大概率只会觉得"页面偶尔卡一下"，根本想不到是第三方SDK的锅。

3.3 卡顿时段标记：把FPS低谷和长任务在时间轴上对齐

这个设计是纯经验产物。最早我的监控面板是两套独立的曲线图，一个画FPS，一个画长任务柱状图。真正做问题定位时发现效率很低——你得一边看FPS掉到多少，一边去找对应的长任务，两个时间轴稍微对不齐就得来回折腾。

后来我改成把两种数据融合进同一条卡顿事件流：每当连续N帧的FPS低于阈值，或者出现一次长任务，就生成一个带开始时间、持续时间和严重等级的事件记录。事件流的好处是既保留了原始数据可以回放，又可以直接做告警搜索和问题聚合。

function buildStallEvents(fpsRecords, longTasks, options = {}) { // options.fpsThreshold: FPS低于此值视为卡顿，默认30 // options.continuousFrames: 连续几帧低于阈值才算一次卡顿，默认5 const events = []; // 处理FPS连续低谷 const fpsThreshold = options.fpsThreshold || 30; const continuousFrames = options.continuousFrames || 5; let lowFpsStreak = 0; let streakStartTime = null; for (const record of fpsRecords) { if (record.fps < fpsThreshold) { if (lowFpsStreak === 0) { streakStartTime = record.timestamp; } lowFpsStreak += 1; } else { if (lowFpsStreak >= continuousFrames) { events.push({ type: 'fps-drop', startTime: streakStartTime, endTime: record.timestamp, severity: lowFpsStreak >= 30 ? 'severe' : 'warning', fpsAvg: calculateAvgFps(fpsRecords, streakStartTime, record.timestamp) }); } lowFpsStreak = 0; } } // 处理长任务 for (const task of longTasks) { const startTime = task.startTime; const duration = task.duration; events.push({ type: 'long-task', startTime: startTime, duration: duration, severity: duration >= 200 ? 'severe' : 'warning', attribution: task.attribution }); } // 按时间升序排序 events.sort((a, b) => a.startTime - b.startTime); // 合并时间重叠的事件，这里会生成一个"卡顿时段" return mergeOverlappingEvents(events); }

mergeOverlappingEvents的核心逻辑我简单说一下：把同一时间段内的fps-drop和long-task合并成一个stall-session，取最早开始时间作为起点，最晚结束时间为终点，严重等级取其中的最高级。

这样做的直接好处是：一个卡顿时段封装了一个完整的故事，"从15点23分15秒到15点23分17秒，页面FPS掉到18，期间发生两次长任务，分别耗时220ms和180ms"——比散落的数十个数据点容易理解得多。

我习惯把这个卡顿时段数据连同用户所在页面路由、设备信息、浏览器UA一起打包，形成一个"性能事件单"。排查问题时只需要看事件单就行，不用每次都在一堆原始数据里翻。这件事越早做越好，因为等你监控跑久了，原始性能数据的体量会非常大，再回头做融合就要面临改版的阵痛。

4. 资源加载监控实战：Performance API的深度用法与上报策略

讲完渲染性能，接着说资源加载监控。渲染性能解决的是"页面画出来卡不卡"的问题，资源加载解决的是"页面内容来不来、来得多快"的问题。两个监控体系共用一套上报通道，但我建议在展示层分开——因为排查问题的思路完全不同。

4.1 资源性能明细采集：从PerformanceEntry里榨出每一个时间点

performance.getEntriesByType('resource')会返回当前页面所有已加载资源的性能条目。但我不建议直接全量采集，因为一个中型页面有上百个请求很正常，全量上报数据量太大，也没必要。我的做法是按需过滤 + 抽样上报：

class ResourceMonitor { constructor(options = {}) { // 只关注这些类型的资源 this.observedTypes = options.observedTypes || [ 'script', 'link', 'img', 'fetch', 'xmlhttprequest', 'css' ]; // 超过此阈值的资源才会上报详情，低于的只上报计数 this.reportThreshold = options.reportThreshold || 200; // ms // 上报回调 this.onReport = options.onReport || (() => {}); } collect() { const resources = performance.getEntriesByType('resource'); const details = []; const summary = {}; for (const res of resources) { const type = this.inferResourceType(res); if (!this.observedTypes.includes(type)) { continue; } // 计算关键耗时指标 const dnsTime = res.domainLookupEnd - res.domainLookupStart; const connectTime = res.connectEnd - res.connectStart; const ttfb = res.responseStart - res.requestStart; const downloadTime = res.responseEnd - res.responseStart; const totalTime = res.responseEnd - res.startTime; if (!summary[type]) { summary[type] = { count: 0, totalTime: 0, slowCount: 0 }; } summary[type].count += 1; summary[type].totalTime += totalTime; // 超过阈值的资源记录详情 if (totalTime > this.reportThreshold) { details.push({ name: res.name, type: type, dnsTime: Math.round(dnsTime), connectTime: Math.round(connectTime), ttfb: Math.round(ttfb), downloadTime: Math.round(downloadTime), totalTime: Math.round(totalTime), transferSize: res.transferSize, protocol: res.nextHopProtocol || 'unknown', // http/1.1, h2, h3 startTime: Math.round(res.startTime) }); } } // 计算各类型的平均耗时 for (const type of Object.keys(summary)) { summary[type].avgTime = Math.round(summary[type].totalTime / summary[type].count); } return { details, summary }; } inferResourceType(res) { if (res.initiatorType === 'script') return 'script'; if (res.initiatorType === 'link' && res.name.includes('.css')) return 'css'; if (res.initiatorType === 'img') return 'img'; if (res.initiatorType === 'fetch' || res.initiatorType === 'xmlhttprequest') return 'fetch'; return res.initiatorType || 'other'; } }

这段代码的作用是：对所有成功加载的资源做一次扫描，生成两个维度的产物——summary是各类型资源的数量与平均耗时，适合做概览；details是超过200ms阈值的资源明细，适合做问题追踪。

排查一个真实案例：我监控到一个业务页面总是"感觉加载慢"，从summary里看到CSS平均耗时370ms，但首屏HTML本身TTFB只有90ms。点进details才发现有一条link类型的资源加载耗时800ms，但请求URL指向的是一个旧的静态资源CDN，内容已经迁移到了新域名。这属于典型的资源路径未更新问题，如果没有details里的具体URL，光靠Summary几乎不可能发现。

4.2 加载失败捕获：错误事件与Performance Buffer的互补

成功的资源可以靠Performance API拿数据，失败的不行。我采用window.addEventListener('error', ..., true)配合PerformanceObserver一起用：

class LoadErrorMonitor { constructor() { this.errorEvents = []; } start() { // 捕获阶段监听资源加载错误 window.addEventListener('error', (event) => { // 只有资源加载错误才会进入这里 // 且事件对象是Event而不是ErrorEvent if (event.target && event.target.tagName && event.target.src) { this.errorEvents.push({ type: 'resource-error', tagName: event.target.tagName, src: event.target.src, timestamp: performance.now(), // 有些资源加载错误event.target上会有完整信息 naturalWidth: event.target.naturalWidth || null, complete: event.target.complete || false }); } }, true); } }

一个小技巧：有些团队会把error监听器挂在每个img元素上，但元素多了之后既影响代码整洁度，又容易漏掉动态加载的元素。事件冒泡到window的捕获阶段搞定所有资源是最好的做法——捕获阶段意味着即使在document之前发生的错误也能被拦截到，而且不用关心元素是静态写的还是JS动态创建的。

4.3 Monitoring Buffer溢出与资源条目上限

performance.getEntriesByType('resource')有个隐形的坑：浏览器的PerformanceEntryBuffer是有容量上限的。Chrome默认最多保存250条资源条目，超过之后最老的会被丢弃。一个复杂页面脚本加图片加接口请求很容易就爆了这个数，所以全量扫描的正确姿势是先观察再决定是否扩buffer：

// 如果想增加缓冲区上限 // 注意：这个调用必须在使用PerformanceObserver之前执行，且只能执行一次 // 不生效的话说明浏览器不支持该属性 if (performance && performance.setResourceTimingBufferSize) { performance.setResourceTimingBufferSize(1000); }

另外一个与此相关的坑：如果你的页面有SPA路由，多次路由切换累积下来的资源条目会一直堆积在buffer里，老条目被新条目挤掉。这时候如果想要完整的性能数据，就得在每次路由切换后主动调用performance.clearResourceTimings()清空缓冲，不然你看到的数据永远是"最近250条"，而不是"本次路由周期内所有资源"。

我当时在这个问题上栽过一次：SPA页面用户从首页跳到详情页再跳到个人中心，查询资源性能列表发现首页的静态资源全部消失了，以为是上报逻辑bug，排查了半天才想到是buffer溢出淘汰了老条目的缘故。

4.4 上报策略：不做全量，按需聚合与发送

资源加载性能数据如果全量上报，一个用户一次访问就可能产生上百条请求记录，服务器压力大，存储成本也高。我在实践中采用了两级策略：

第一级，页面级汇总上报。每个访问会话结束（pagehide或visibilitychange到hidden状态）时，把当前页面的Summary数据和筛选出的慢资源明细通过sendBeacon发送。sendBeacon的优势是不受页面卸载影响，数据一定能送出去，而且不会阻塞页面关闭流程——相比用fetch在beforeunload里异步发送，可靠性高很多。

window.addEventListener('pagehide', () => { const resourceMonitor = getResourceMonitor(); const report = resourceMonitor.collect(); const payload = { type: 'resource-performance', url: location.href, route: getCurrentRoute(), summary: report.summary, slowDetails: report.details, timestamp: Date.now(), userAgent: navigator.userAgent }; // 用sendBeacon发送，可靠性优先 if (navigator.sendBeacon) { navigator.sendBeacon('/api/perf/collect', JSON.stringify(payload)); } else { // 降级方案 const img = new Image(); img.src = `/api/perf/collect?data=${encodeURIComponent(JSON.stringify(payload))}`; } });

第二级，卡顿时段内触发实时上报。如果在上面渲染监控里生成了一个severe级别的卡顿时段，立即上报，不要等页面卸载。否则主要问题数据可能会因为页面直接崩溃而丢失——比如用户操作引发内存暴涨导致浏览器关闭标签页，pagehide虽然能触发，但网络请求可能来不及发出。

function onStallEvent(stallSession) { if (stallSession.severity === 'severe' && !isThrottled) { const payload = { type: 'stall-event', url: location.href, stallSession: stallSession, fpsSamples: getRecentFpsSamples(), longTasks: getRecentLongTasks(), timestamp: Date.now() }; navigator.sendBeacon('/api/perf/stall', JSON.stringify(payload)); } }

这套上报策略我压测过的数据量大概是：一个日活5万的中型站点，每天的性能上报请求数在10万~20万左右，单条payload平均不到2KB，完全在可接受的范围内。如果全量上报的话这个数字少说要翻十倍，无论是内网带宽还是对象存储成本都会明显增加。

5. 实时检测的展示层设计：怎么让老板和同事都看得懂

手搓监控最怕什么？最怕你辛苦做出了一堆数据，但同事看不懂，老板不认可。数据要发挥价值，必须可视化。我把展示层做成一个内部性能看板，这里分享一下设计维度和几个关键图表的实现思想。

5.1 看板的目标与布局思路

性能看板的受众有三类人：

• 自己（前端程序员）：需要能下钻到具体资源URL、具体长任务归属、具体时间线的原始数据；
• 后端同事：需要能看到接口的TTFB趋势、DNS耗时趋势，用来区分是前端渲染问题还是服务端响应问题；
• 产品或运营：只看LCP、CLS之类的业务感知指标，用红黄绿三色标注健康状态。

看板布局按这个思路拆成三个板块：顶部是核心Web指标健康卡，中间是渲染性能时间趋势图，底部是资源加载明细表。细节不用多说，我重点讲两个容易被忽略的设计判断。

第一个是时间窗口选择要给"慢"留出空间。默认展示过去5分钟的数据看起来实时性很强，但遇到"偶发某页面卡顿两秒"的情况，5分钟窗口里只有一两个数据点，看不出趋势规律。我最终采用5分钟+30分钟+24小时三档切换，默认落在30分钟档，既能看出规律又能保留一定的时效性。

第二个是指标颜色的阈值边界必须可配置。不要写死在代码里。比如LCP 2.5秒以内算好、4秒以上算差，这是Chrome官方阈值，但不同业务场景接受度不一样——B端后台管理系统3秒内就很好，C端电商首页1.8秒都嫌慢。看板上同一个指标在不同项目里要有不同的水位线，配色逻辑跟着阈值走，别搞一套标准打天下。

5.2 卡顿时段的可视化回放

前面提到的卡顿时段事件流，在看板上的呈现形式是一条带严重级别色块的时间轴。色块的高度代表卡顿持续时长，颜色代表严重等级，点击色块弹出该时段的事件明细列表：

[时间轴示例 - 用文字描述避免依赖图表] 15:23:15 - 15:23:17 [红色色块] FPS低谷(22), 长任务2次, 最慢任务220ms 15:28:42 - 15:28:43 [黄色色块] 长任务1次, 耗时180ms 15:30:00 [绿色标记] FPS恢复正常(60)

这个视图上线后，运营同事第一次主动来找我反馈问题，说"看到了下午3点28分的那次卡顿，正好对应他们双11大促优惠券下发弹窗的时间点"——那确实是我们埋点触发逻辑里一个很隐蔽的重DOM操作，之前一直没被重视。

渲染性能监控的展示部分我在实现时的细节处理：每一条卡顿时段都带上FPS采样数据和长任务列表的JSON快照，用户点开可以直接在控制台粘贴运行，复现当时的部分数据状态。这个"可导入"设计让前端团队内部的bug流转效率提升了很多——以前是"我看到页面卡了，但不知道怎么描述给你"，现在是"发你一个事件JSON，你直接分析就行"。

5.3 资源加载明细表与慢资源排行榜

渲染指标做趋势图，资源指标做明细表就够用。表格的关键列是：资源URL、资源类型、触发页面、TTFB、下载耗时、总耗时、传输大小、协议版本、出现次数。

协议版本这一列很有价值。我通过res.nextHopProtocol拿到资源是http/1.1还是h2还是h3之后，发现一个很典型的问题：部分第三方的广告脚本走的是http/1.1，而我们的业务资源都走h2，并行加载时HTTP/1.1的多个连接很容易挤占浏览器连接池，导致业务资源排队等待。后来我们一不做二不休，把所有第三方脚本改到async加载并降低优先级，首屏整体速度快了20%。

慢资源排行榜按出现次数和平均耗时综合排序，这里的出现次数是判断优先级的核心依据。单个资源加载慢但只出现一次，可能只是偶发网络问题；慢且高频出现，就是值得优化的对象。我把这两个参数都展示出来，并且默认按"慢次数*平均耗时"排序，让真正的"毒瘤资源"自动浮到列表顶部。

6. 上线后踩过的坑与调优记录

最后这部分完全是经验之谈。这一套监控体系从搭建到稳定运行，我踩了很多坑，这里挑几个最有代表性的记录下来，希望后来者别在同样的地方浪费时间。

6.1 PerformanceObserver的bufferFull事件有多容易被忽略

PerformanceObserver默认会往Performance Buffer里写入数据，不同浏览器的buffer容量不一致。在移动端低端机上，资源条目和长任务条目涌入很可能导致buffer溢出。溢出后有两种表现：新条目不再写入，以及触发performanceObserverBufferFull事件（部分浏览器支持）。我当时在低端安卓测试机上复现了一个诡异现象——监控数据采集一会儿有、一会儿没有，排查了半天才发现是buffer在极端场景下被打满了，新数据根本进不来。

解法是提前监听bufferfull事件并在触发时清空buffer：

performanceObserver.addEventListener('bufferfull', () => { // 先把已收集的数据发送出去，再清空 flushCollectedData(); performance.clearResourceTimings(); });

6.2 跨域资源拿不到精确耗时的坑

resource条目里很多字段在跨域请求时会被置为0——比如transferSize、domainLookupStart这些。Chrome的全新Timing-Allow-Origin机制决定了：如果资源响应头里没有设置Timing-Allow-Origin: *或者具体域名，浏览器为了安全会把这些敏感时间戳隐藏掉。

最要命的是图片走CDN的跨域场景。我查一个背景图加载慢的问题时发现responseStart是0，整个TTFB也算不出来，列在明细表里就是一行"总耗时0ms的异常条目"。解决方案如下：

// 跨域资源要拿到精确性能数据，需要服务器响应头支持： // Timing-Allow-Origin: <你的域名> // 前端侧也可以主动开启crossOrigin属性增强时间戳的可见性 // 但注意这会给请求增加Origin头，CDN需要相应做跨域放行 const img = new Image(); img.src = 'https://cdn.example.com/xxx.jpg'; img.crossOrigin = 'anonymous';

如果CDN是你自己控制的范围，强烈建议统一加上Timing-Allow-Origin响应头。这一个小改动，能让所有跨域资源加载时间戳全部可见，排查效率天壤之别。

6.3 数据上报的时序要不要加锁

pagehide事件里发sendBeacon，逻辑上没问题，但如果用户在极短时间里快速切换多个页面，每个页面的pagehide都想发一次上报，后端就可能收到乱序数据。比如A页面上报了10:00:00的LCP数据，B页面上报了9:59:58的LCP数据，后端如果按时间排序展示曲线就会出现回退跳变。

我在上报数据里加了一个自增的页面会话序列号sessionSeq，后端按"用户维度+序列号"去重和排序，才彻底解决了这个问题。这个字段在采集端生成，一次访问会话内单调递增，简单靠谱。

6.4 监控代码本身对性能的影响

最后说一个让人哭笑不得的问题——监控代码自己成了性能瓶颈。第一版手搓监控的FPS采样回调里，我顺便执行了一些字符串拼接和日志记录操作，结果在低端机上每帧大约多了1.2ms的开销。虽然单帧影响不大，但监控目标本身如果是"首屏加载耗时"，监控代码在地基里就掺入了干扰因素，测出来的数据永远比真实值偏大。

所以我把监控脚本做了四件事：压缩后体积控制在6KB以内、全部逻辑放在requestIdleCallback或setTimeout中延迟初始化、FPS采样回调中只做加减法和对象字段赋值，不做字符串拼接、不写console日志、samples的内存队列有上限，超过则丢弃最旧数据。开发环境可以通过URL参数开启debug模式打印详细日志，生产环境一律静默运行。

实践下来，加监控前后页面性能波动控制在1%以内，这个误差在可接受范围内。

这套手搓监控从构思、开发到上线调优，前后大概用了两周时间。比起商业解决方案，它确实需要自己维护、自己升级、自己排查各种浏览器兼容问题。但回报是实实在在的：数据完全归自己掌控，可以深度定制任何业务维度的分析逻辑，配合内部系统做告警、做报表、做自动化的性能回归测试。如果你也正面临"页面性能问题靠人工排查效率太低"的困境，动手搓一套也许不如直接引入现成工具来得快，但长期来看，这一趟下来你对自己页面运行机制的了解会深一个量级。别的不说，光是搞明白Long Task、LCP、FPS、TTFB这一整套指标怎么联动，就已经值回票价了。