1
网站性能监控不是测一次分数就完事了,需要从"真实用户监控"和"合成监控"两个维度持续采集数据,两者各看各的东西,数据差了30%以上才是正常的
2
免费工具够用但各有盲区:PageSpeed Insights看的是Lab数据不是真实用户、GTmetrix免费版只能选北美节点、Pingdom不测CLS和INP、WebPageTest功能最强但上手门槛最高
3
真正有用的监控不是看总分,是看趋势。LCP从2.1秒涨到3.5秒的那周,查一下是不是上了新插件或者CDN节点出了故障
一、监控之前,先把这九个指标搞清楚
Google的Core Web Vitals是基准,但实际需要监控的远不止这三个。| 指标 | 健康标准 | 衡量什么 | 优化方向 |
|---|---|---|---|
| TTFB 首字节时间 | < 800ms | 服务器响应速度 | 升级服务器配置、换DNS、用CDN、优化数据库查询、开缓存 |
| FCP 首次内容绘制 | < 1.8s | 用户看到第一个内容的时间 | 消除渲染阻塞资源、减少关键CSS/JS、服务器推送 |
| LCP 最大内容绘制 | < 2.5s | 主要内容加载完成时间 | 优化主图加载(preload/webp)、减少DOM大小、服务端渲染 |
| TBT 总阻塞时间 | < 200ms | 主线程被长任务阻塞的总时长 | 拆分长任务、延迟加载第三方脚本、Web Worker |
| CLS 累积布局偏移 | < 0.1 | 页面视觉稳定性 | 给图片/视频/广告预留宽高、字体加载用font-display、避免动态注入内容 |
| INP 交互到下一次绘制 | < 200ms | 用户交互响应速度(替代FID) | 减少事件处理耗时、用requestAnimationFrame、防抖节流 |
| Speed Index 速度指数 | < 3.4s | 页面内容可视化的平均速度 | 减少视觉空白期、优先加载视口内内容、懒加载视口外图片 |
| 可用性 Uptime | > 99.9% | 网站是否在线可访问 | 多节点监控、DNS健康检查、SSL证书过期检测 |
| 服务器资源 | CPU < 70% 内存 < 80% | 服务器负载和资源消耗 | 升级配置、优化慢查询、清理日志、加Swap、负载均衡 |
TTFB不能只看平均值。P50的TTFB可能是300ms看起来很健康,但P95可能是2.5秒——这意味着每20个用户里就有1个在等两秒半才收到第一个字节。性能监控一定要看P75、P95、P99这些分位数,平均值会掩盖长尾问题。
二、两类监控方式:真实用户监控 vs 合成监控
RUM(真实用户监控)
原理:在页面里嵌入JS代码,采集真实用户访问时的性能数据。
能看到:不同地区、不同设备、不同网络环境下真实用户的加载体验,所有Core Web Vitals指标。
看不到:未访问页面的性能、竞品对比数据。
典型工具:Google CrUX报告、Cloudflare Web Analytics、Akamai mPulse、自建web-vitals.js采集
能看到:不同地区、不同设备、不同网络环境下真实用户的加载体验,所有Core Web Vitals指标。
看不到:未访问页面的性能、竞品对比数据。
典型工具:Google CrUX报告、Cloudflare Web Analytics、Akamai mPulse、自建web-vitals.js采集
合成监控(Synthetic Monitoring)
原理:从固定的测试节点模拟用户访问,在受控环境下测量性能。
能看到:任何页面的性能评分、优化建议、瀑布图、竞品对比、持续趋势。
看不到:真实用户的设备和网络多样性、长尾性能问题。
典型工具:PageSpeed Insights、GTmetrix、WebPageTest、Pingdom、Lighthouse CI
能看到:任何页面的性能评分、优化建议、瀑布图、竞品对比、持续趋势。
看不到:真实用户的设备和网络多样性、长尾性能问题。
典型工具:PageSpeed Insights、GTmetrix、WebPageTest、Pingdom、Lighthouse CI
两者必须配合使用。合成监控告诉你"在理想条件下你的网站能跑多快",RUM告诉你"真实用户实际体验有多快"。如果合成监控LCP是1.2秒但RUM显示P75用户LCP是3.8秒,说明你的CDN覆盖不到核心用户所在的地区,或者你的用户设备普遍比较旧。
三、八个性能监控工具实测对比
| 工具 | 类型 | 免费程度 | 核心能力 | 最大盲区 |
|---|---|---|---|---|
| Google PageSpeed Insights | 合成 | 完全免费 | Lab数据+CrUX真实用户数据双面板,Core Web Vitals评估,优化建议按优先级排序 | 测试节点单一,不显示瀑布图细节,不能持续监控 |
| WebPageTest | 合成 | 完全免费 | 40+全球节点、可选设备/浏览器/网速、完整瀑布图、电影胶片视图、内容拆分分析 | 界面老旧,上手门槛高,免费版有排队等待 |
| GTmetrix | 合成 | 免费版有限 | Lighthouse+自研引擎双评分、瀑布图、视频回放、定时监控、告警 | 免费版仅加拿大节点、每月100次测试、不能自定义网速 |
| Pingdom | 合成+可用性 | 14天试用 | 全球100+节点、页面速度+可用性监控一体、事务监控、实时告警 | 不测Core Web Vitals(无LCP/CLS/INP),付费较贵 |
| Lighthouse CI | 合成 | 完全免费 | 集成到CI/CD流水线,每次部署自动跑性能测试,分数下降自动阻断部署 | 只适合开发者,需要CI/CD环境,配置有一定门槛 |
| Google Search Console | RUM | 完全免费 | 基于CrUX数据,按URL分组显示Core Web Vitals,直接关联搜索表现 | 数据延迟约28天,只有Chrome用户数据,不显示具体优化建议 |
| Cloudflare Web Analytics | RUM | 完全免费 | 无需Cookie的隐私友好型分析,自动采集Core Web Vitals,按页面/国家/设备分组 | 仅限接入Cloudflare的站点,功能比GA4少 |
| UptimeRobot / BetterStack | 可用性 | 基础免费 | 多节点Ping/HTTP检查、SSL证书过期告警、关键词检测、状态页 | 只看"能不能访问",不看"快不快",不测前端性能指标 |
四、Lighthouse CI:把性能监控嵌入部署流水线
手工跑PageSpeed Insights的问题在于:今天测了明天忘了,上线了新功能后性能偷偷降了也不知道。Lighthouse CI解决的就是"每次部署自动测,分数降了就拦截"这件事。# 安装 Lighthouse CInpm install -g @lhci/cli# 项目根目录创建 lighthouserc.jsmodule.exports = {ci: {collect: {// 要测试的页面列表url: ['https://你的网站.com/','https://你的网站.com/product/','https://你的网站.com/blog/sample-post',],// 每个URL跑3次取中位数(避免网络波动影响)numberOfRuns: 3,settings: {// 模拟移动端 + 3G网络preset: 'desktop', // 或 'desktop'onlyCategories: ['performance', 'accessibility', 'best-practices', 'seo'],},},assert: {// 断言规则:不达标则CI失败assertions: {'categories:performance': ['error', { minScore: 0.8 }], // 性能低于80分就报错'categories:accessibility': ['warn', { minScore: 0.9 }], // 可访问性低于90分警告'first-contentful-paint': ['error', { maxNumericValue: 2000 }], // FCP超过2秒报错'largest-contentful-paint': ['error', { maxNumericValue: 3000 }], // LCP超过3秒报错'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }], // CLS超过0.1报错'total-blocking-time': ['warn', { maxNumericValue: 300 }], // TBT超过300ms警告},},upload: {// 上传结果到临时公开存储(可选,方便团队查看)target: 'temporary-public-storage',},},};# 运行 Lighthouse CIlhci autorun# GitHub Actions 集成示例 (.github/workflows/lighthouse.yml)name: Lighthouse CIon: [pull_request]jobs:lighthouse:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v3- uses: actions/setup-node@v3- run: npm install -g @lhci/cli- run: lhci autorun
CI中的断言阈值怎么设:第一次跑的时候先把minScore设成当前的实际分数减5分,让CI先通过。然后逐步收紧阈值,每次部署的目标是"不降低性能",而不是一开始就追求90分。如果当前网站只有60分,直接设80分的阈值等于禁止了所有部署,反而会逼团队关掉这个检查。
五、自建性能监控面板:web-vitals + 自建数据收集
如果你不想用第三方工具,完全可以用Google官方的web-vitals.js库在前端采集Core Web Vitals数据,发送到自己的后端存储。// 1. 安装 web-vitals// npm install web-vitals// 2. 前端采集代码 (performance-monitor.js)import { onLCP, onFID, onCLS, onINP, onTTFB } from 'web-vitals';function sendToAnalytics(metric) {const body = {name: metric.name, // LCP, FID, CLS, INP, TTFBvalue: metric.value, // 数值rating: metric.rating, // good / needs-improvement / poordelta: metric.delta, // 与上次上报的差值id: metric.id, // 指标唯一ID(同页面多次触发时去重)page: window.location.pathname,timestamp: Date.now(),// 附带设备信息帮助分析device: {width: window.screen.width,height: window.screen.height,connection: navigator.connection?.effectiveType || 'unknown', // 4g/3g/2g},};// 用 sendBeacon 确保页面关闭时也能发送(CLS 在页面卸载时触发)if (navigator.sendBeacon) {navigator.sendBeacon('/api/vitals', JSON.stringify(body));} else {fetch('/api/vitals', {method: 'POST',body: JSON.stringify(body),keepalive: true,headers: { 'Content-Type': 'application/json' },});}}// 注册所有 Core Web Vitals 指标onCLS(sendToAnalytics);onINP(sendToAnalytics);onLCP(sendToAnalytics);onTTFB(sendToAnalytics);// 额外采集:自定义业务指标const observer = new PerformanceObserver((list) => {for (const entry of list.getEntries()) {if (entry.entryType === 'navigation') {// DNS查询时间、TCP连接时间、TLS握手时间、请求响应时间const timing = {dns: entry.domainLookupEnd - entry.domainLookupStart,tcp: entry.connectEnd - entry.connectStart,tls: entry.secureConnectionStart > 0 ? entry.connectEnd - entry.secureConnectionStart : 0,request: entry.responseStart - entry.requestStart,response: entry.responseEnd - entry.responseStart,dom: entry.domContentLoadedEventEnd - entry.domContentLoadedEventStart,load: entry.loadEventEnd - entry.loadEventStart,};sendToAnalytics({ name: 'NAV-TIMING', value: timing, rating: 'good' });}}});observer.observe({ type: 'navigation', buffered: true });
数据存哪里:量小的话存SQLite或者MySQL足够,每天几万条写入没问题。量大的话考虑时序数据库(InfluxDB、TimescaleDB)或者直接用Google Analytics 4的自定义事件(免费、免运维),缺点是数据粒度粗、有采样。
六、服务器端性能监控:只看前端不够
前端指标再好看,服务器CPU打满了照样崩。服务器监控至少要看这四个维度:系统资源
CPU使用率、内存使用量、磁盘IO、磁盘空间、网络吞吐量
推荐工具:htop / atop / Netdata
告警阈值:CPU持续 > 80% 超过5分钟
常见问题:慢SQL查询导致CPU飙升、日志文件撑爆磁盘
推荐工具:htop / atop / Netdata
告警阈值:CPU持续 > 80% 超过5分钟
常见问题:慢SQL查询导致CPU飙升、日志文件撑爆磁盘
Web服务器
请求数/秒、响应时间分布、5xx错误率、活跃连接数、Worker进程状态
推荐工具:Nginx Amplify / Apache mod_status / GoAccess
告警阈值:5xx错误率 > 1%、响应时间P95翻倍
常见问题:php-fpm进程池耗尽、KeepAlive连接堆积
推荐工具:Nginx Amplify / Apache mod_status / GoAccess
告警阈值:5xx错误率 > 1%、响应时间P95翻倍
常见问题:php-fpm进程池耗尽、KeepAlive连接堆积
数据库
慢查询数量、查询吞吐量、连接数、InnoDB缓冲池命中率、复制延迟
推荐工具:MySQL慢查询日志 + Percona PMM / phpMyAdmin状态页
告警阈值:慢查询 > 10次/分钟、缓冲池命中率 < 95%
常见问题:缺少索引导致全表扫描、连接数耗尽
推荐工具:MySQL慢查询日志 + Percona PMM / phpMyAdmin状态页
告警阈值:慢查询 > 10次/分钟、缓冲池命中率 < 95%
常见问题:缺少索引导致全表扫描、连接数耗尽
应用层
PHP错误日志、WordPress插件性能、API响应时间、缓存命中率、队列积压
推荐工具:Query Monitor(WordPress)/ New Relic / 自定义日志
告警阈值:PHP Fatal Error出现、缓存命中率 < 80%
常见问题:某个插件在特定页面执行了30+次数据库查询
推荐工具:Query Monitor(WordPress)/ New Relic / 自定义日志
告警阈值:PHP Fatal Error出现、缓存命中率 < 80%
常见问题:某个插件在特定页面执行了30+次数据库查询
6.1 Netdata:一行命令搞定服务器全栈监控
# 一行命令安装 Netdata(支持所有主流Linux发行版)wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh# 安装完成后访问 http://你的服务器IP:19999# 自动监控以下所有内容(无需额外配置):# - CPU / 内存 / 磁盘 / 网络 / 温度# - Nginx / Apache 状态# - MySQL / PostgreSQL / Redis / MongoDB# - PHP-FPM 进程状态# - 系统日志异常检测# - 每个进程的CPU/内存/IO占用# 配置告警(/etc/netdata/health_alarm_notify.conf)# 支持邮件、Slack、Discord、Telegram、Webhook等通知方式
七、可用性监控:网站挂了第一时间知道
性能优化再好,网站打不开一切都白费。可用性监控是最基础也最重要的一层。| 检查类型 | 检查内容 | 频率 | 推荐工具 |
|---|---|---|---|
| HTTP(S)状态检查 | 返回200 OK,响应时间 < 阈值 | 每1-5分钟 | UptimeRobot、BetterStack、Pingdom |
| 关键词检查 | 页面HTML中包含特定关键词(确认页面正常渲染) | 每5-15分钟 | BetterStack、Pingdom、自建脚本 |
| SSL证书过期 | 证书剩余有效天数,提前告警 | 每天 | UptimeRobot、SSL Labs API |
| DNS健康检查 | 域名解析是否正常、NS服务器是否全部可达 | 每15分钟 | DNS Spy、自建dig脚本 |
| 端口检查 | SSH(22)、MySQL(3306)、Redis(6379)等关键端口是否开放 | 每1-5分钟 | UptimeRobot、自建nc脚本 |
#!/bin/bash# 简易自建可用性监控脚本(配合crontab使用)# */5 * * * * /opt/scripts/uptime-check.shURLS=("https://site1.com" "https://site2.com" "https://site3.com")TIMEOUT=10ALERT_WEBHOOK="https://hooks.slack.com/xxx"for url in "${URLS[@]}"; dostatus_code=$(curl -o /dev/null -s -w '%{http_code}' --max-time $TIMEOUT "$url")if [ "$status_code" != "200" ]; thenecho "[ALERT] ${url} 返回 ${status_code} - $(date)"# 发送告警到 Slack / 钉钉 / 飞书 / 企业微信curl -X POST -H 'Content-type: application/json' \--data "{\"text\":\"⚠️ 网站异常: ${url} 返回状态码 ${status_code}\"}" \$ALERT_WEBHOOKfidone
八、不同规模的监控方案选择
个人博客 / 小型企业站
推荐组合:
· 可用性:UptimeRobot 免费版(50个监控项,5分钟间隔)
· 性能:PageSpeed Insights + GSC Core Web Vitals
· 服务器:Netdata 单机部署
· 告警:UptimeRobot自带邮件通知
总成本:0元/月
适合:1-5个站点,不需要历史趋势分析
· 可用性:UptimeRobot 免费版(50个监控项,5分钟间隔)
· 性能:PageSpeed Insights + GSC Core Web Vitals
· 服务器:Netdata 单机部署
· 告警:UptimeRobot自带邮件通知
总成本:0元/月
适合:1-5个站点,不需要历史趋势分析
中型企业 / 电商网站
推荐组合:
· 可用性:BetterStack 或 Pingdom(多节点+关键词检查)
· 前端性能:GTmetrix Pro(定时监控+历史趋势+告警)
· RUM:web-vitals自建采集 或 Cloudflare Web Analytics
· 服务器:Netdata + Prometheus + Grafana
· 数据库:Percona PMM 或 MySQL Enterprise Monitor
总成本:200-800元/月
适合:5-50个站点,需要历史趋势和告警
· 可用性:BetterStack 或 Pingdom(多节点+关键词检查)
· 前端性能:GTmetrix Pro(定时监控+历史趋势+告警)
· RUM:web-vitals自建采集 或 Cloudflare Web Analytics
· 服务器:Netdata + Prometheus + Grafana
· 数据库:Percona PMM 或 MySQL Enterprise Monitor
总成本:200-800元/月
适合:5-50个站点,需要历史趋势和告警
大型平台 / SaaS产品
推荐组合:
· APM:New Relic / Datadog / Dynatrace
· 前端RUM:自建web-vitals + ClickHouse/InfluxDB + Grafana
· 合成监控:自建多节点Puppeteer脚本 + CI定时跑
· 可用性:Pingdom Enterprise(事务监控+全球节点)
· 日志分析:ELK Stack 或 Loki + Grafana
总成本:3000-20000元/月
适合:50+站点或单个高流量应用
· APM:New Relic / Datadog / Dynatrace
· 前端RUM:自建web-vitals + ClickHouse/InfluxDB + Grafana
· 合成监控:自建多节点Puppeteer脚本 + CI定时跑
· 可用性:Pingdom Enterprise(事务监控+全球节点)
· 日志分析:ELK Stack 或 Loki + Grafana
总成本:3000-20000元/月
适合:50+站点或单个高流量应用
UC建站系统的性能监控方案
如果你用UC建站系统管理多个站点,后台内置了统一的性能监控面板:· 多站点性能总览:一个界面看到所有站点的Core Web Vitals评分,按站点/页面/设备分组,哪个站的LCP在恶化一眼就能发现。· 自动合成监控:系统每天定时从多个地理节点对每个站点跑Lighthouse测试,生成性能趋势图,分数连续下降自动告警。· 真实用户数据采集:内置web-vitals采集模块,自动统计每个站点的P50/P75/P95性能分位数,按国家、设备、网络类型分组。· 服务器健康度:CPU、内存、磁盘、数据库慢查询、PHP错误日志统一收集,异常时推送到钉钉/飞书/邮件。· 性能优化建议引擎:针对检测到的具体问题(如图片未压缩、CSS阻塞渲染、缺少缓存头),自动生成按优先级排序的优化清单,包含具体的操作步骤和预期提升效果。



