打开 Chrome DevTools 的简单 Network 面板，刷新页面，网站看到那个蓝色的监控竖线标记着 DOMContentLoaded，红色的简单 load 事件卡在 3.2 秒。这就是网站最原始的性能监控——肉眼盯着瀑布图，数有多少个请求在排队。监控说实话，简单大部分小网站根本用不着上 Sentry 或者 Datadog，网站浏览器自带的监控工具已经能解决八成问题。

我维护过一个日活两千左右的简单内容站，服务器是网站台 2 核 4G 的轻量云。有段时间用户反馈"点开文章要等好久"，监控但我本地测试一切正常。简单后来在 Performance 面板录了一段，网站发现是监控某篇特定文章里嵌了个第三方 iframe，那个 iframe 的域名解析要 800ms。这种问题，APM 工具未必能准确定位到具体页面元素，但浏览器自带的火焰图一眼就看出来了。

Navigation Timing API：几行代码拿到核心指标

现代浏览器提供了 performance.getEntriesByType('navigation')，返回一个对象，里面装着从重定向到 load 的完整时间线。我习惯在页面底部塞一段脚本，把关键数据打到 console：

const nav = performance.getEntriesByType('navigation')[0]; console.log('DNS:', nav.domainLookupEnd - nav.domainLookupStart); console.log('TTFB:', nav.responseStart - nav.requestStart); console.log('DOM解析:', nav.domContentLoadedEventEnd - nav.responseEnd); 

TTFB 超过 500ms 就得查服务器了。有次发现 TTFB 飙到 1.2 秒，登上去看 MySQL 慢查询日志，一条没加索引的 SELECT * FROM comments WHERE article_id = ? 扫了全表。加索引后直接降到 80ms。这种因果关系，靠前端监控工具是推不出来的，得结合服务端日志一起看。

用 PerformanceObserver 盯住长任务

页面卡顿的元凶通常是长任务——执行超过 50ms 的 JS 代码块。PerformanceObserver 能实时捕获：

new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {  if (entry.duration > 50) {  console.warn('长任务:', entry.duration.toFixed(0) + 'ms', entry.name); } } }).observe({  entryTypes: ['longtask'] }); 

我在一个后台管理系统里加过这段，发现每次打开侧边栏菜单都会触发一个 120ms 的长任务。查下去是菜单组件在 render 时递归计算了所有子项的权限，而权限数据有 300 多条。改成扁平化存储加缓存，降到 15ms。这种优化，没数据支撑根本无从下手。

资源加载：别只看总量，要看分布

很多人只关心页面总大小，但更关键的是资源加载的时序。用 performance.getEntriesByType('resource') 能拿到每个资源的耗时。我见过一个页面，CSS 文件只有 20KB，但加载花了 1.8 秒——原因是它排在 6 个同步脚本后面，浏览器要等脚本执行完才去请求 CSS。把 CSS 提到 <head> 最前面，直接降到 200ms。

还有个坑：字体文件。中文字体动辄 3-5MB，如果没做子集化，首屏文字会闪一下默认字体再切换。用 font-display: swap 只是缓解，根本办法是只打包用到的字符。我用 fontmin 把 5MB 的字体压到 80KB，加载时间从 2 秒变成 300ms。

简易上报：别想太复杂

如果只是想长期跟踪几个核心指标，没必要搭整套监控系统。用 navigator.sendBeacon 在页面卸载时发一条 JSON 到自己的接口就行：

window.addEventListener('visibilitychange', () => {  if (document.visibilityState === 'hidden') {  const nav = performance.getEntriesByType('navigation')[0]; navigator.sendBeacon('/api/perf', JSON.stringify({  ttfb: nav.responseStart - nav.requestStart, load: nav.loadEventEnd - nav.startTime, url: location.pathname })); } }); 

后端存进 SQLite 或者直接写日志文件，用 Grafana 或者甚至 Excel 画个趋势图。我这么干了半年，发现每周一上午 TTFB 都会涨 30%，原因是备份脚本在跑。调整备份时间后问题消失。这种规律，商业监控工具不会告诉你，得自己看数据才能发现。

性能监控这事，工具越简单越容易坚持。浏览器自带的 API 已经够用，关键是养成习惯：每次改完代码，打开 Network 面板刷一下，看看那条蓝色竖线有没有往左移。