做前端性能测试的人多半都装过 hiper 这个命令行工具。它给人的第一印象是“简单到有点简陋”敲一行hiper -u 页面地址它就拉一个无头浏览器把页面真实打开一遍然后把 DNS、TCP、TTFB、下载耗时这些拆解后的数字打在一张表里。上手五分钟就能跑出结果这也是很多人对它的全部印象——跑一次看看数字关掉下次再跑一次。但真正在项目里用久了你会发现工具本身几乎没有门槛门槛全在“配置怎么定、场景怎么搭、数据怎么看”这三件事上。默认参数跑出来的那一行数字噪声大得离谱你今天测 800ms 明天测 1300ms拿着这种数据去跟团队汇报除了制造焦虑没有任何价值。这篇内容想聊的就是 hiper 的进阶用法怎么把它的自定义配置组织成一套可复用的东西怎么针对不同场景冷启动基线、弱网、登录后页面、版本回归设计不同的跑法以及拿到数据之后怎么处理才不至于自欺欺人。适合已经能跑通基础命令、但苦于“数据不稳、没法对比、进不了流程”的前端、测试、运维同学也适合刚接手性能专项、不知道从哪下手的人。下面所有的脚本、参数、目录结构都是可以直接抄走改改就用的涉及具体参数名的地方我会提醒你以本地hiper --help的输出为准因为不同版本的参数命名确实有出入。1. 先把能力边界摸清楚再谈自定义1.1 hiper 测的到底是什么东西很多人把 hiper 和 ab、wrk 这类工具混为一谈其实它们测的是完全不同的东西。压测工具干的事是往一个接口上猛发请求看服务端能扛多少 QPS它不解析 HTML、不执行 JS、不会因为页面里有一张 2MB 的首屏大图而改变任何行为。hiper 走的是另一条路它启动一个无头浏览器内核把 URL 当成一个真实用户会打开的页面去访问HTML 要解析、外链 CSS 和 JS 要下载执行、图片要加载、页面里发起的接口请求也要走一遍。所以它量出来的是“一个用户打开这个页面网络层面到底花了多久”这个数字和用户的实际感受更接近。也正因为“重”它的数据天然比纯接口压测更容易抖。浏览器内有并发连接数限制、有资源加载优先级、有 JS 执行阻塞任何一个环节的波动都会传导到最终数字上。理解这一点非常关键你后面做的所有配置工作本质上都是在压缩这些波动源让每次跑出来的数字具备可比性而不是追求某个绝对准确的“真值”。性能测试里没有真值只有同一把尺子量出来的相对变化。它输出的核心是一张网络时间拆解表一次请求的生命周期被切成几段DNS 查询域名解析花了多久、TCP 建连三次握手、TLS 握手HTTPS 才有、TTFB发出请求到收到第一个字节这段基本反映服务端处理能力、内容下载首字节到最后一个字节。这五段加起来才是一个请求的完整耗时任何一段异常都值得单独拎出来看。实践中最常见的情况是总耗时很长但 DNS 只有 2ms、TCP 只有 15msTTFB 却占了 900ms——问题根本不在网络而在服务端或者数据库。1.2 默认跑一遍为什么数据不能直接用刚上手的人最容易犯的错就是把默认参数跑出来的单次结果当成结论。我见过不少人在群里贴一张表问“我这个页面 TTFB 600ms 正常吗”但这个 600ms 背后可能有四种完全不同的情况结论天差地别。第一种是采样次数不够。默认跑一次就是一次而单次测量的方差极大尤其在共享网络、虚拟机、笔记本降频这些环境下第一次和第二次差出 50% 都不奇怪。解决办法很简单加次数取统计值这一步不做后面的分析全是空中楼阁。第二种是缓存状态不明确。浏览器有 HTTP 缓存、DNS 缓存、连接池复用你连着跑两次第二次很可能直接复用了第一次的连接和缓存数字好看得不像话但这个数字代表的不是“用户首次访问”的体验。所以要么明确禁用缓存测冷启动要么明确保留缓存测二次访问绝对不能含含糊糊地跑跑完还不知道自己测的是哪种。第三种是环境不一致。同一份代码在开发机上跑和在构建机上跑在白天跑和凌晨跑连的公司网络和连的公共网络结果能差出一倍。这里的一致包括机器负载是否接近、浏览器版本是否一致、是否开了其他占资源的程序、被测服务当前是否在做别的压测。这些变量你不控制就别指望数据能横向对比。第四种是没有基线。一个孤零零的数字没有意义“首屏 1.8 秒”到底是好是坏取决于你上周是多少、竞品是多少、你的目标是多少。性能测试的价值 90% 来自对比而不是来自绝对值。所以从第一天起就应该把每次结果存下来形成一条时间线。1.3 自定义配置的三层结构hiper 本身是个命令行工具它没有那种 yaml 配置文件的机制所以“自定义配置”这件事实际上要靠三层结构自己搭起来我把它总结成参数层、封装层、调度层。参数层就是命令行开关本身负责控制这一次运行的行为——跑几次、开不开缓存、用什么 UA、结果输出到哪。这一层是基础但如果你每次都要手敲一长串参数早晚会敲错也早晚会因为“这次少写了个参数”导致数据不可比。封装层是关键的中间层用一个 shell 脚本或者 npm script 把常用的参数组合固化下来对外只暴露少数几个有意义的输入比如环境名、页面标识。这一层解决的是“一致性”问题同一个场景永远用同一套参数人不可能记错。调度层负责跑完之后的事情结果文件按时间戳归档、和历史数据对比、超阈值告警、接到流水线里。这一层决定了性能测试是“一次性活动”还是“持续能力”。大部分团队卡在第一层少数做到第二层真正把第三层跑起来的性能问题基本不会等到上线才暴露。下面两章就按这个结构往下拆先讲参数再讲封装和场景。2. hiper 自定义配置体系拆解2.1 参数优先级与覆盖规则在写封装脚本之前先把优先级规则想清楚否则脚本写到后面会变成一团乱麻。我的做法是三层覆盖从高到低命令行显式传入的值、脚本内置的场景默认值、环境变量兜底。举个具体例子PERF_COUNT这个环境变量在构建机上设成 5脚本里某个场景的默认次数是 3而你在命令行手动传了-c 10那最终生效的就是 10。这个规则听起来简单但它带来的好处是日常开发用默认值图省事构建机上用环境变量统一口径排查问题时又能临时覆盖三种需求互不打架。实现上没有那么玄乎bash 里用${VAR:-default}就够了。真正需要注意的是两个细节。第一布尔型参数要显式区分“没传”和“传了假值”很多脚本在这里翻车比如缓存开关--no-cache传了是禁用不传是启用你没法用空值表示“不传”所以要单独用一个变量记录“用户是否显式指定过”。第二所有最终生效的参数必须在日志里打印一遍包括那些走了默认值的。这一条看着啰嗦但它是事后复盘唯一的依据没有这行日志三个月后你根本说不清那次数据是用什么配置跑出来的。2.2 核心参数逐项拆解不同版本的 hiper 参数名会有差异所以第一步永远是先跑一遍hiper --help把输出存到项目文档里和你的脚本放在一起。下面这张表是常见参数的作用和建议值具体名称请对照你本地的帮助输出替换。参数类别典型写法作用我的建议值容易踩的坑目标地址-u/--url指定被测页面每个场景固定一个带随机参数会导致缓存行为不一致运行次数-c/--count重复执行的轮数基线场景 7 到 10 轮只跑 1 轮方差大到无法分析输出文件-o/--output结果落到文件带时间戳和场景名覆盖写导致历史数据丢失缓存控制--no-cache一类禁用浏览器缓存冷启动场景必开只清了 HTTP 缓存没清 DNSJS 开关--disable-javascript一类关闭脚本执行仅用于定位 JS 影响当成常规场景用脱离真实体验UA 标识--useragent一类指定浏览器标识固定成目标端机型不同 UA 触发不同的服务端下发逻辑关于次数我强烈建议至少 7 轮这个数字不是拍脑袋来的。你要算中位数样本少于 5 个时中位数几乎没有抗噪能力要算 P90 分位理论上有意义的样本量得 10 个以上考虑到还要剔除首轮预热数据7 到 10 轮是个比较平衡的区间——再多单次跑批时间会拉长到影响日常节奏。关于缓存这里有个容易被忽略的点浏览器的 DNS 缓存和连接池复用不受页面级缓存开关控制。也就是说你加了禁用缓存的参数HTTP 资源确实重新下载了但域名解析可能还是走的系统缓存TCP 连接也可能是复用的。如果被测页面前面有 CDN 或者多级网关这个差异会直接影响 TTFB 的真实性。要彻底冷启动得在跑之前清一下本机 DNS 缓存或者干脆每轮之间隔开足够长的时间。2.3 用 shell 封装一套可复用的跑批脚本下面这个脚本是我目前在用的简化版思路是把“场景”当成一等公民每个场景一组固定参数跑完自动归档。你可以直接拿去改。#!/usr/bin/env bash set -euo pipefail # 全局默认值可被环境变量覆盖 SCENE${1:-cold} # 场景名cold / warm / mobile / api RUN_COUNT${PERF_COUNT:-7} # 轮数 TARGET_URL${PERF_URL:-https://demo-site.test/} OUT_ROOT${PERF_OUT:-./perf-results} STAMP$(date %Y%m%d-%H%M%S) OUT_DIR${OUT_ROOT}/${SCENE}/${STAMP} mkdir -p $OUT_DIR # 场景参数装配 EXTRA_ARGS() case $SCENE in cold) EXTRA_ARGS(--no-cache) EXTRA_ARGS(--useragent Mozilla/5.0 (perf-bot desktop)) ;; warm) # 保留缓存测二次访问体验 EXTRA_ARGS(--useragent Mozilla/5.0 (perf-bot desktop)) ;; mobile) EXTRA_ARGS(--no-cache) EXTRA_ARGS(--useragent Mozilla/5.0 (perf-bot mobile)) ;; *) echo [ERR] 未知场景: $SCENE 2 exit 1 ;; esac # 记录本次生效配置事后复盘的唯一依据 { echo scene$SCENE echo url$TARGET_URL echo count$RUN_COUNT echo extra${EXTRA_ARGS[*]:-none} echo host$(hostname) echo start$(date -Iseconds) } | tee ${OUT_DIR}/config.log # 执行 hiper \ --url $TARGET_URL \ --count $RUN_COUNT \ --output ${OUT_DIR}/result.csv \ ${EXTRA_ARGS[]} echo [OK] 结果目录: ${OUT_DIR}这段脚本有三个设计意图值得展开说。第一场景用 case 分支装配参数而不是让调用方自己拼这样任何人在任何机器上跑./run-perf.sh cold拿到的都是完全一致的参数组合一致性靠代码保证而不是靠自觉。第二每次运行单独建目录目录名带场景和时间戳天然形成一条时间线后面做趋势对比直接按目录排序就行不需要额外建库。第三config.log 记录全部生效参数包括机器名和开始时间这份日志在排查“为什么这次数据异常”时能省掉大量扯皮。注意脚本里set -euo pipefail这一行别省。性能测试脚本最怕的是中途某一步失败了但整体还返回成功结果归档了一个空文件等到第二天看趋势图才发现数据断了一天。2.4 用 npm scripts 把日常动作串起来如果项目本身是 Node 工程把这套东西挂到 package.json 里会更顺手团队成员不需要记 shell 路径。{ scripts: { perf:cold: bash scripts/run-perf.sh cold, perf:warm: bash scripts/run-perf.sh warm, perf:mobile: PERF_COUNT5 bash scripts/run-perf.sh mobile, perf:report: node scripts/perf-report.js } }这里的取舍是脚本本身保持纯 shell不引入额外的依赖保证在任何装了 bash 的环境里都能跑报告分析这类需要数据处理的部分才用 Node 写。这样即使在只有基础镜像的构建机上跑批这一步也不会因为依赖缺失而挂掉——这是被坑过之后的设计之前有个项目图省事把跑批逻辑写进了一个需要装一堆依赖的 JS 脚本里结果构建机镜像一升级整个性能流水线停了两周没人发现。3. 多场景实战四套可以直接抄的配置3.1 场景一首屏冷启动基线这是最基础也最重要的场景回答的问题是“一个全新用户第一次打开这个页面网络层面要花多久”。它是所有对比的原点一旦这套基线不稳后面所有场景的分析都会跟着歪。关键配置就三条禁用缓存、固定 UA、轮数拉满到 10。禁用缓存不必解释固定 UA 是因为很多服务端会根据 UA 下发不同的 HTML 结构甚至不同的图片格式UA 变了等于被测对象变了轮数拉满是给后面的统计处理留足样本。跑之前还有两件事要做。一是确认被测页面没有依赖登录态如果一打开就被重定向到登录页那你测的其实是登录页的性能这个错误极常见尤其在 SPA 项目里路由守卫会静默跳转你不看日志根本发现不了。二是确认首轮预热数据要被剔除第一轮往往包含浏览器冷启动、DNS 首次解析、连接池建立等一次性开销把它算进统计会系统性拉高结果。我的做法是照跑 10 轮但在分析阶段丢掉第 1 轮用剩下 9 轮算中位数。项目取值理由缓存禁用模拟首次访问UA固定桌面标识保证服务端下发一致轮数10分析用 9留出预热轮时段固定在业务低峰避开网络与服务端波动前置清 DNS 缓存避免解析结果被复用3.2 场景二弱网环境下的真实体感桌面宽带下测出来的数字和用户在电梯里、在地铁上用手机打开同一个页面的体验完全是两回事。弱网场景要回答的是“网络变差时这个页面是优雅降级还是直接崩掉”。hiper 本身不提供网络模拟这是它的边界得靠外部手段补。有两种思路各有适用场合。第一种是在操作系统层面做流量整形Linux 下的 tc netem 是标准做法# 在 eth0 上注入 200ms 基础延迟、50ms 抖动、1% 丢包 sudo tc qdisc add dev eth0 root netem delay 200ms 50ms loss 1% # 跑完一定要清掉否则会影响这台机器上所有网络行为 sudo tc qdisc del dev eth0 root这条命令的意图要理解清楚它是在网卡出口上做队列延迟影响的是这台机器的所有流量不只是浏览器。所以千万别在生产构建机上随手加很容易把同机器上跑的其他任务一起拖慢。稳妥的做法是在一次性容器里做跑完容器一销毁环境天然干净。参数上200ms 延迟大概对应 4G 网络一般水平50ms 抖动模拟真实无线环境的不稳定1% 丢包用来触发 TCP 重传逻辑这三项组合基本能覆盖移动端的常见劣化情况。第二种思路是在被测服务侧注入延迟比如在网关层给特定接口加固定延时。这种做法的好处是粒度细、可控性强能精确模拟“某个后端接口慢”而不是“整条网络慢”坏处是需要服务端配合不适合快速验证。弱网场景的判读逻辑和基线完全不同。基线看的是总耗时弱网更该关注资源数量和串行依赖如果页面有 80 个请求每个请求在 200ms 延迟下都要多花一个 RTT总时间会被放大得极其难看反过来如果页面只有 20 个请求并且大量并行弱网下的衰减就温和得多。所以这个场景跑完先别盯着总时长去看请求数量和水瀑布形状优化方向往往在那里。3.3 场景三带登录态的页面怎么测这是 hiper 使用者最常卡住的地方。它的定位是“给一个 URL打开它”没有内置的登录流程编排能力遇到需要登录才能访问的页面就抓瞎。绕过去的思路有三条按推荐程度排序。第一条最省事让被测页面支持一个带签名的直达链接后端发一个短期有效的 token 拼在 URL 上访问即视为已登录。这个方案需要后端配合但一旦做好hiper 的用法和测公开页面完全一样配置不用改只是 URL 变了。很多团队内部的管理后台、报表页都能这么改造成本远低于想象。第二条是在跑批之前先把登录态固化下来用一段独立的脚本完成登录、导出凭证然后让被测请求带上。这条路的技术难度取决于工具版本对凭证注入的支持程度如果版本没暴露相关开关就得自己做一层薄封装。第三条是把带交互的部分交给自定义的浏览器自动化脚本hiper 只负责公开页面的基线。这不是妥协而是分工交互链路的性能本来就需要脚本化才能测准硬塞给一个面向单页面的工具反而是错配。这里有个血泪教训值得单独说带登录态的测试千万不要用长期有效的固定账号。曾经有个项目用测试账号跑了一个月某天后端做了登录频次限制超过阈值就返回降级页面hiper 照样跑得通、照样输出数字只是那些数字测的是一个空白错误页。整整一周的数据全废还是人工核对才发现。从那以后我的规矩是跑批脚本里必须有一条断言检查返回内容的特征字符串不匹配就直接报错退出。3.4 场景四版本回归与趋势观测前面三个场景都是“横向”的——不同条件下的表现。回归场景是“纵向”的这次的代码比上次慢了吗。这个场景的技术含量不在跑而在比对。我的做法是每天固定时段跑一次冷启动基线结果按场景/日期归档然后由分析脚本读取最近 N 天的结果算出每天的中位数画出一条趋势线。真正有价值的信号是趋势的拐点而不是某一天的绝对值如果连续三天中位数往上走了 15%那基本可以确定是某次合并引入的问题顺着提交记录往回找命中率非常高。阈值怎么定不要抄网上的经验值比如“TTFB 超过 200ms 就是慢”这种话在具体项目里毫无意义。正确做法是用自己过去 30 天的数据算出一个分布取 P50 作为常态基准P90 作为波动上限然后设两条线中位数超过基线 30% 报警单轮出现超过 P90 两倍的极端值记录待查。这个规则的好处是它会随着项目自身演进自动调整不会因为业务增长导致误报连天。4. 数据解读与结果落地4.1 指标含义与阈值设定拿到一堆数字之后最怕的是逐个看一遍然后凭感觉下结论。先把每个指标代表什么、异常时指向哪个环节搞清楚判断会快很多。指标反映什么异常时的常见原因排查方向DNS 耗时域名解析解析服务响应慢、解析链路长换解析线路、减少跨域域名数TCP 建连三次握手跨地域、网络绕行、连接未复用就近接入、开启长连接TLS 握手加密协商证书链过长、未启用会话复用精简证书链、开启复用TTFB服务端首字节后端处理慢、数据库慢查询、缓存未命中看服务端链路追踪内容下载传输耗时资源体积大、带宽受限压缩、拆分、按需加载看这张表的顺序很重要从前往后排查先排除基础设施层再怀疑应用层。因为 DNS 和建连这两段如果本身就有问题后面所有的分析都是建立在流沙上的。我就见过盯着 TTFB 优化了半个月最后发现是 DNS 解析走了境外节点、每次解析要 300ms 的情况。4.2 多次采样的统计处理原始数据是一堆轮次直接用平均值是最常见的错误。平均值对极端值极度敏感10 轮里有 1 轮因为机器在做其他事飙到了 5 秒平均值立刻被拉高 400ms但这个 5 秒根本不能代表任何东西。正确做法是用中位数做主指标用 P90 做波动性参考。下面这段脚本用来把结果文件里的耗时列取出来做统计思路是通用的字段名按你实际的表头调整即可。const fs require(fs); function stats(nums) { const s [...nums].sort((a, b) a - b); const n s.length; const median n % 2 ? s[(n - 1) / 2] : (s[n / 2 - 1] s[n / 2]) / 2; const p90 s[Math.min(n - 1, Math.ceil(n * 0.9) - 1)]; const min s[0]; const max s[n - 1]; return { median, p90, min, max, count: n }; } const raw fs.readFileSync(process.argv[2], utf8).trim().split(\n); const header raw[0].split(,); const ttfbIdx header.findIndex(h /ttfb/i.test(h)); // 丢掉第一轮预热数据 const rows raw.slice(2).map(line line.split(,)); const values rows .map(r Number(r[ttfbIdx])) .filter(v Number.isFinite(v) v 0); const r stats(values); console.log(样本数${r.count} 中位数${r.median.toFixed(1)}ms P90${r.p90}ms 极差${r.min}-${r.max}ms); // 波动过大时给出提示避免拿噪声当结论 if (r.p90 r.median * 1.5) { console.warn([WARN] 波动偏大建议增加轮数或检查机器负载); }这段代码里有个细节值得说它会把极差也打印出来。中位数好看但极差巨大比如中位数 400ms最小 380ms 最大 2400ms说明环境里存在间歇性干扰这种数据拿去对比是没有意义的。我通常拿极差和中位数的比值做健康度判断超过 3 倍就先别分析业务先查环境。4.3 报告归档与流水线集成单机跑批的价值有限接进流水线之后价值才真正释放。最小可行的集成方式是每天定时跑一次产物按日期归档跑完自动和历史中位数比对超过阈值就往团队频道发一条消息。这里有两个实操上的注意点。第一流水线机器必须是专用的不要和构建任务混跑。构建任务本身吃满 CPU 的时候跑性能测试结果必然是噪声而且这种噪声具有随机性非常难排查。第二历史数据要有保留策略不要无限堆积我一般保留 90 天明细加永久保留每日中位数这样趋势图有足够长的视野存储又不会爆。5. 常见问题与排查速查表5.1 跑不起来或结果为空这类问题基本都在环境和参数上。最典型的是浏览器内核没装好或者版本不匹配表现是命令执行了但没有输出。先看错误日志里有没有内核启动相关的提示有的话重新初始化一下运行环境。其次是参数写错尤其是布尔型参数拼错一个字母工具会当作未知参数忽略或者报错退出看着像是跑了其实什么都没做。还有一种隐蔽情况是超时。无头浏览器打开一个特别重的页面如果默认超时时间不够会在页面还没加载完就截断结果里只有部分请求。这种半截数据比没有数据更危险因为它的数值往往还很好看。所以跑完一定要核对一下请求数量是否和浏览器手动打开时的数量接近差距超过两成就要怀疑是不是被截断了。5.2 数据剧烈抖动怎么定位抖动是性能测试最常见的困扰排查顺序我总结成从外到内四层机器、网络、服务、页面。层级检查项快速验证方法机器CPU 占用、内存压力、是否降频跑批期间盯一眼负载网络是否共享带宽、是否有大文件传输换时段复跑一次对比服务后端是否有定时任务、是否在做发布查服务端监控和发布记录页面是否有随机内容、是否有轮询请求固定随机种子或屏蔽轮询按这个顺序走八成问题能在前三层定位。剩下的两成往往在页面本身比如首页有个推荐模块每次拉不同的内容图片数量不一样耗时自然不一样。这种就要在测试环境里把随机性关掉或者干脆给模块加个固定开关。5.3 几条用血换来的经验不要把 hiper 当成全能的性能平台。它的强项是快速、低成本地拿到一个页面的网络层时间线弱项是交互编排、弱网模拟、多页面流程。认清这一点用它做它擅长的事剩下的部分老老实实用别的工具补效率远高于硬掰。不要在没有基线的项目上直接上告警。没有历史数据的时候任何阈值都是拍脑袋第一天上线就会误报连连然后团队就会开始忽略告警最后整套机制形同虚设。先默默收集两周数据看清楚了分布再定线。不要在同一个时段跑多个场景。看着是省时间实际上是让几个跑批互相抢资源最后每个场景的数据都不干净还不如分开跑、慢一点但每份数据都能用。不要相信第一次跑出来的漂亮数字。性能测试里“好得超出预期”几乎总是配置问题——缓存没禁、登录态失效跳到了轻量页、页面被截断这几种情况我都遇到过。看到异常好的结果第一反应应该是怀疑而不是高兴。最后分享一个我一直在用的习惯每次调整配置或者优化上线之后除了看中位数我一定会把原始结果文件打开扫一眼看那几个极端值是什么样子、出现在第几轮。很多次我都是这么发现“第 4 轮开始变慢”这类线索的而这类信息在汇总数字里完全看不到。工具给的是数据判断还得自己来。