性能问题最让人头疼的地方在于它的隐蔽性：用户反馈页面卡顿，你在本地打开却一切正常；测试环境响应飞快，线上却总有几个慢请求说不清原因。这时候，与其反复猜测，不如直接使用浏览器内置的Performance API，把页面从导航开始到渲染完成的每一个时间节点都记录下来，用数据说话。这套API不需要引入任何第三方库，所有主流浏览器都原生支持，是做前端性能监控绕不开的基础能力。
一、先弄清楚要监控哪些指标
在动手写代码之前，得先明确监控目标。传统上大家习惯看window.onload的触发时间，但这个指标其实相当粗糙——它只告诉页面整体加载完成了，却看不出用户什么时候第一次看到内容、什么时候可以交互。
目前业界更关注的是以用户为中心的指标体系。FCP（First Contentful Paint）表示浏览器渲染出第一个内容元素的时间；LCP（Largest Contentful Paint）衡量视口内最大内容元素渲染完成的时间点，直接关联用户的视觉感受；而CLS（Cumulative Layout Shift）则统计布局偏移的程度，反映页面稳定性。除此之外，长任务（执行时间超过50毫秒的任务）也是导致卡顿的常见元凶。Performance API对这些指标都有对应的事件或条目可以采集，下面逐个展开。
二、使用PerformanceObserver采集关键性能指标
Performance API的现代用法核心是PerformanceObserver，它可以异步监听各类性能条目，不会阻塞主线程，比旧的getEntries()轮询方式更可靠。以LCP为例，代码可以这样写：
// 监听最大内容绘制时间
try {
let lcp;
const po = new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
// 取最后一个条目作为最终LCP值
lcp = entries[entries.length - 1];
console.log('LCP:', lcp.startTime, 'ms');
});
po.observe({ type: 'largest-contentful-paint', buffered: true });
} catch (e) {
console.warn('当前浏览器不支持LCP监测');
}
这里有个细节值得注意：buffered: true表示回放已经发生的条目，避免监听器注册之前的事件被漏掉。LCP可能因为懒加载图片陆续出现而多次触发，所以代码里取的是最后一条记录。
FCP和CLS的采集方式类似，只是type不同。FCP对应paint类型，需要过滤出名称为first-contentful-paint的条目；CLS则监听layout-shift类型，累加每个条目的value值（只有没有用户输入参与的偏移才计入）。建议把这几个监听封装成统一的采集模块，在页面初始化时统一注册，避免散落在业务代码各处难以维护。
三、用mark和measure定位代码瓶颈
页面级指标只能告诉你"慢"，但慢在哪一段还得靠手动打点。Performance API提供了mark和measure两个方法，前者在时间轴上打一个标记，后者计算两个标记之间的耗时，配合getEntriesByType('measure')就能取出结果：
// 对数据请求到渲染完成的链路分段计时
performance.mark('fetchStart');
fetch('/api/list')
.then(res => res.json())
.then(data => {
performance.mark('fetchEnd');
performance.mark('renderStart');
renderList(data);
performance.mark('renderEnd');
performance.measure('接口耗时', 'fetchStart', 'fetchEnd');
performance.measure('渲染耗时', 'renderStart', 'renderEnd');
const measures = performance.getEntriesByType('measure');
measures.forEach(m => console.log(m.name, m.duration.toFixed(2), 'ms'));
});
这种方式的优势在于粒度完全由你控制。如果发现接口耗时占比很高，可以进一步在请求侧按域名、按接口路径聚合统计；如果渲染耗时异常，就要检查是不是一次性插入了大量DOM节点，或者存在强制同步布局。相对于自己用Date.now()做减法，performance.now()底层使用的时间戳精度更高（可达微秒级），而且能被浏览器的性能面板识别，调试时可以直接在DevTools的Performance面板里看到这些标记点，排查体验好得多。
一个实用的技巧是封装一个守卫函数，避免重复打同名标记导致的数据污染。同时记得在数据上报完成后调用performance.clearMarks()清理时间轴，防止SPA应用长时间运行后条目越积越多。
四、监测长任务与资源加载
卡顿的另一个主要来源是主线程被长时间占用。PerformanceObserver支持longtask类型，凡是执行超过50毫秒的任务都会被捕获：
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.warn('发现长任务，耗时', entry.duration.toFixed(0), 'ms');
// 可以结合entry.attribution获取任务来源
}
});
observer.observe({ entryTypes: ['longtask'] });
// 统计慢资源
const resources = performance.getEntriesByType('resource');
const slow = resources
.filter(r => r.duration > 500)
.map(r => ({ name: r.name, duration: Math.round(r.duration) }));
console.table(slow);
资源条目里包含了每个请求的完整耗时拆解：DNS查询、TCP连接、SSL握手、请求发送、等待响应、内容下载，各个阶段都有对应字段。分析慢接口或慢静态资源时，这些字段能帮你判断问题在网络层还是服务端。比如等待响应时间（responseStart与requestStart之差）占比高，说明服务端处理慢；下载阶段耗时长则可能是响应体过大，需要考虑压缩或分片。
五、数据上报与持续监控
本地调试用console输出就够了，但要做线上监控就必须把数据送回服务端。上报时机建议选在页面加载基本稳定之后（比如load事件后延迟几秒，或监听到最终LCP时），并统一封装成sendBeacon方式发送，避免请求本身影响页面性能。需要注意部分浏览器对时间戳做了精度限制以防范侧信道攻击，普通场景下毫秒级精度已经够用；对采集逻辑要做好异常兜底，监控代码本身报错就得不偿失了。
最后，指标采回来只是第一步，真正的价值在于建立基线和趋势。把每次发布的指标变化与代码改动关联起来，配合按地区、机型、网络环境的下钻分析，才能从"知道页面慢"进化到"知道为什么慢、改哪里能快"。Performance API给了你数据的地基，剩下的就靠监控体系的设计和团队对性能的持续关注了。
Performance API前端性能监控性能瓶颈分析修改时间：2026-09-10 10:43:03