测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载本篇技术指南以 sitespeed.io 8.1发布于 2019-02-01的发布说明为骨架围绕三个核心新特性展开基于视频录制自动生成的Filmstrip 胶片条视图、在 HTML 报告中展示的Server Timings服务端计时以及随 Browsertime 4.1 引入的新脚本命令commands.js.runAndWait()。阅读本文后你将掌握如何用配置参数控制胶片条的采样密度与画质、如何在 Metrics 页解读后端计时数据以及如何编写脚本逐步测量购物/结算这类多步骤用户旅程。文中所有实现细节均对照当前仓库源码filmstrip.js、serverTimings.pug 等与官方文档交叉验证。版本背景8.1 带来了什么sitespeed.io 8.1.0 于 2019 年 2 月 1 日发布。根据仓库中的 CHANGELOG.md本次发布的核心变更包括新增 Filmstrip 标签页录制视频并保留截图时自动展示页面渲染过程的时间序列截图灵感来自 Stefan Burnicki 的 wpt-filmstrip 项目在 Metrics 指标区展示 Server Timings前提是页面返回了 Server-Timing 响应头Docker 容器升级至 Chrome 72 与 Firefox 65并同步更新 ChromeDriver / GeckoDriver升级到 Browsertime 4.1新增脚本命令js.runAndWait()允许执行自定义 JavaScript、点击链接并等待页面导航完成修复了 metric 页面显示 FullyLoaded 而非 N/A、补全 CLI 中缺失的 pre/post script 参数等问题#2278、#2282。下面逐一深入这些新能力的用法与底层实现。Filmstrip把视频帧变成可阅读的渲染时间线它是什么Filmstrip胶片条是把浏览器录制视频按固定时间间隔抽帧并按时间顺序排列成一条可视化时间线。它让你无需逐帧播放视频就能一眼看出页面何时开始渲染、何时出现关键内容、以及渲染在哪个阶段卡住。这个功能的想法最早由社区成员 Rod Barlow 提出而其呈现形式参考了 iteratec 的 wpt-filmstrip。sitespeed.io 此前在录制视频时已经通过 Visual Metrics 自动生成了逐帧截图只是没有在结果页面中利用起来——8.1 将其以独立标签页的形式呈现。如何使用使用前提是开启视频录制。在使用 Docker 运行 sitespeed.io 时视频录制默认开启因此会直接得到 Filmstrip 标签页。手动运行时可以显式指定sitespeed.io https://example.com --video --visualMetrics默认行为是以100 ms为时间跨度采样只展示那些“画面发生变化”或“恰好有指标metric落在这个时间点”的截图。换句话说一个画面长时间不变的阶段胶片条会自动跳过重复帧避免冗余。运行效果见下图控制胶片条的相关参数参数作用默认值取值范围/说明--filmstrip.showAll是否展示每一帧截图不做去重false设为true时每个 100 ms 采样点都展示--videoParams.filmstripQuality胶片条截图的压缩质量750-100数值越高画质越好、文件越大--videoParams.filmstripFullSize是否保留原始分辨率的全尺寸截图false开启后占用磁盘更多、运行耗时更长--videoParams.thumbsize缩略图最大边长400单位为像素filmstripFullSize开启时此值被覆盖--videoParams.createFilmstrip是否创建胶片条截图true不需要时可显式关闭--browsertime.videoParams.createFilmstrip false--videoParams.filmstripDiff为每帧生成与前帧的差异图及整段录制的视觉不稳定热力图false需要额外后处理时间每帧多存一张图以上参数的当前默认值与说明可以在 configuration/config.md 中找到完整记录。一个常见的调优组合示例# 展示所有帧、提高画质到 90、但不使用全尺寸截图 sitespeed.io https://example.com --video --visualMetrics \ --filmstrip.showAll \ --videoParams.filmstripQuality 90 \ --videoParams.thumbsize 800源码级实现胶片条是如何拼出来的胶片条的数据组装逻辑位于 lib/plugins/browsertime/filmstrip.js核心流程如下前置条件判断getFilmstrip()首先检查options.browsertime.visualMetrics true且options.browsertime.videoParams.createFilmstrip true第 L179-L185任一不满足则直接返回空数组保证没有录制视频时不会产生无意义的胶片条数据。读取帧文件从结果目录data/filmstrip/run/读取截图文件只处理以ms_开头的帧文件diff_*.png会被跳过见第 L196-L203。收集指标锚点通过getMetricsFromBrowsertime()把 Browsertime 数据里的事件提取为“时间锚点”包括 User Timing marks、CPU Long Task、Fully Loaded、DCL / Page Load Time、FCP、LCP、以及 Visual Metrics 的 First Visual Change、Visual Complete 85/95/99、Largest Image 等第 L20-L167。这些指标随后被映射到胶片条的时间轴上用于决定哪些帧必须展示。按步长采样默认以 100 ms 为步长遍历时间轴一个特殊细节是当启用--filmstrip.showAll且总时长超过 10 秒时步长会自动放宽到 200 ms避免帧数过多第 L209-L212。去重与锚点注入只有当当前帧文件与上一帧不同、或该时间段内有指标命中、或开启了showAll时该帧才会进入最终渲染列表第 L220-L232。这正是“默认只展示变化的帧和带指标的帧”这一行为的实现来源。此外lib/plugins/browsertime/index.js 会在汇总阶段调用getFilmstrip把胶片条数据挂到每个 run 的_meta.filmstrip上供 HTML 模板渲染。在现代版本中Filmstrip 与视频播放器、时间线一起整合进了Rendering 标签页rendering/index.pug有视频时点击帧会跳转视频到对应时刻只录屏不录视频时则由胶片条驱动大图预览。Server Timings让后端耗时出现在 HTML 报告中背景与价值Server Timing 是 W3C 提出的规范Server-Timing响应头服务端可以在响应头中携带后端处理的耗时信息例如数据库查询时间、缓存命中状态、渲染时间等。sitespeed.io 在此前几个版本中已让 Browsertime 自动采集这些数据8.1 则把它们正式呈现到 HTML 结果中——这是服务端计时能力落地的第一步当时官方也展望了后续将其接入 Graphite/Grafana 进行存储和时序展示的可能。在报告中查看只要被测页面返回了Server-Timing响应头你就能在Metrics 标签页中看到 Server timings 区块每一行包含三项内容名称Name、耗时Duration、描述Description。典型数据包括后端处理时间、缓存状态、实验开关标记等。源码级实现模板与渲染逻辑服务端计时区块的模板位于 serverTimings.pug。它的渲染逻辑有几个值得注意的工程细节条件渲染只有timings.serverTimings存在且长度大于 0 时才输出该卡片第 L12没有 Server-Timing 数据的页面不会显示空状态占位避免大多数普通页面上的无意义空白表头结构模板修复了早期版本thead/tr结构不合法的问题改用规范的 thead/tbody 结构使data-sortable排序功能可以正常工作耗时的统一格式化duration 通过h.time.ms辅助函数渲染与报告中其他计时列保持一致显示为 0 ms 这类统一格式入口挂载在 metrics/index.pug 中Server timings 会被加入页面锚点导航#server-timings并在第 L241 行通过include ./serverTimings.pug注入页面主体。后端只需在响应头中返回类似Server-Timing: db;dur23, cache;deschit的内容sitespeed.io 便会自动采集并在报告里呈现无需任何额外配置。新浏览器版本跟上用户的自更新节奏8.1 的 Docker 容器升级到了Chrome 72与Firefox 65并同步使用最新的 ChromeDriver / GeckoDriver。这一更新的意义在于如今浏览器都会自动更新你的用户大概率已经在用最新版本性能测试工具只有同样使用相近的浏览器版本才能真实还原用户环境下的表现。因此定期升级容器中的浏览器与驱动是保证测试结果与现实一致的基本维护动作。新脚本命令js.runAndWait()执行 JS 并等待页面导航完成命令语义在 8.0 引入的脚本化能力基础上8.1 随 Browsertime 4.1 带来了新命令commands.js.runAndWait()。它与普通commands.js.run()的区别在于执行 JavaScript 之后会等待页面完成导航page navigation。也就是说当你的脚本需要在页面里执行一段 JS 来点击链接、触发表单提交或引发软导航并希望完整测量这个导航过程时runAndWait正是为此设计的。相关的用法说明可以在 interact-with-the-page/index.md 中看到runAndWait会执行 JS 并等待页面加载完成检查即 Browsertime 判断“测试何时结束”的完整加载条件。在现代版本中同类的“点击后等待导航”能力也可以直接用commands.click(selector, { waitForNavigation: true })实现见 interact-with-the-page/index.md。为什么需要它在脚本测量用户旅程时最常见的需求是“点击某个元素后等待新页面加载完成再继续下一步”。如果只用js.run()触发点击却不等待测量就会在不正确的时机结束如果用measure.start()加手动等待代码又显得笨重。js.runAndWait()把“执行 JS → 等待导航完成”封装为一个原子操作让脚本更简洁、时序更可靠。典型写法module.exports async function (context, commands) { await commands.measure.start(https://shop.example.org); // 在页面中点击某个元素并等待导航完成 await commands.js.runAndWait(document.querySelector(.checkout-as-guest).click();); return commands.measure.stop(); };实战示例用脚本测量购物/结算全流程8.1 官方特别强调了脚本化测量在多步骤用户旅程Multi-step user journey上的价值你可以把购物结算的每一个环节都拆成一次独立的测量得到每个步骤各自的性能指标多次运行时还能用中位数median获得更稳定的统计结果。下面是一个完整示例在示例商店中把一件商品加入购物车并以访客身份完成结算。脚本对每个步骤分别启动/停止测量从而获得首页 → 商品页 → 购物车 → 以访客身份结算 → 完成结算五个环节各自独立的时间线。这个示例的当前版本也收录在 examples/index.md 中。module.exports async function(context, commands) { // 先测量商店首页 await commands.measure.start(https://shop.example.org); // 然后是商品页 // 你的商店可能有一个专用于测试的通用商品 // 真实场景下或许需要先校验商品确实有库存没有则换一个商品 await commands.measure.start(https://shop.example.org/prodcucs/theproduct); // 把商品加入购物车 await commands.js.run(document.querySelector(.add-to-cart).click();); // 进入购物车页并测量它 await commands.measure.start(https://shop.example.org/cart/); // 以访客身份结算也可以登录为正式客户。 // 我们隐藏 HTML避免点击链接触发 First Visual Change // 最佳情况下你不需要这么做但这里故意用一个复杂的例子 await commands.js.run(document.body.style.display none); await commands.measure.start(CheckoutAsGuest); await commands.js.runAndWait(document.querySelector(.checkout-as-guest).click();); // 停止测量并收集 CheckoutAsGuest 步骤的指标 await commands.measure.stop(); // 完成结算 await commands.js.run(document.body.style.display none); await commands.measure.start(FinishCheckout); await commands.js.runAndWait(document.querySelector(.checkout-finish).click();); // 收集 FinishCheckout 步骤的指标 return commands.measure.stop(); // 真实商店里你通常无法真正走完最后一步或者可以选择退货 // 以保证库存正确可以在脚本末尾处理也可以把商品 id 放进 // context 对象如 context.itemId yyyy然后在 postScript 里 // 用这个 id 做必要的善后处理 };这个示例的关键设计点分段测量measure.start(url)与measure.start(别名)配合measure.stop()把一次长旅程切分成多个独立的测量段落每个段落都有独立的加载时间、资源统计和视觉指标runAndWait承担导航第 9 步和第 11 步用js.runAndWait()触发点击并等待页面导航这正是 8.1 新增命令的核心应用场景隐藏 HTML 以保护视觉指标结算页点击前把document.body隐藏是为了避免点击本身引起的 DOM 变化被当作 First Visual Change从而污染视觉指标的测量结果善后钩子脚本注释中提到的context.itemId与 postScript 配合是一个处理测试下单后需要清理订单/恢复库存这类问题的推荐模式。关于measure.start/stop、click、wait等更完整的命令用法可继续阅读 measurement-commands/index.md 与 interact-with-the-page/index.md脚本的 API 参考入口是 Commands.html。运行与验证运行以上脚本文件例如保存为checkout.mjssitespeed.io checkout.mjs --multi --video --visualMetrics -n 3参数说明--multi允许脚本内部进行多次测量多步骤旅程必须开启--video --visualMetrics录制视频并计算视觉指标同时获得 Filmstrip-n 3重复运行 3 次之后在报告中取中位数结果得到更稳定的指标。运行结束后打开生成的 HTML 报告即可验证Rendering / Filmstrip 视图确认每个步骤的渲染时间线是否正确、视觉指标First Visual Change、Visual Complete 等是否与胶片条吻合关于用胶片条校准视觉指标的实践见 developers/index.mdMetrics 标签页确认每个步骤的指标是否独立呈现若有 Server-Timing 响应头则能看到 Server timings 区块。结语sitespeed.io 8.1 是脚本化测量能力走向成熟的一个重要里程碑Filmstrip 把视频从难以回放的原始素材变成了可阅读、可定位问题的渲染时间线Server Timings 让前端性能报告第一次系统性地容纳后端耗时信息js.runAndWait()则补齐了在页面内触发导航并完整测量的关键脚本原语。三个能力叠加使得购物结算这类多步骤用户旅程可以像单页测试一样被精确、稳定地逐段量化——这套方法论至今仍是 sitespeed.io 用户旅程测试的基石。完整的版本变更清单可查阅仓库根目录的 CHANGELOG.md。赞分享测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载相关推荐Nightwatch.js 性能测试初探测量页面加载与交互速度Nightwatch.js 性能测试初探测量页面加载与交互速度 为什么性能测试对现代Web应用至关重要 在用户体验至上的时代页面加载速度直接影响用户留存率与测试质量保障Elvish用 Go 打造的可编程脚本语言与交互式 Shell 深度解析Elvish用 Go 打造的可编程脚本语言与交互式 Shell 深度解析 Elvish 是一个用 Go 实现的跨平台命令行工具同时具备强大脚本语言与内CLI编程语言开发工具create-gatsby 深度解析Gatsby 交互式站点脚手架的命令、源码与版本演进create gatsby 深度解析Gatsby 交互式站点脚手架的命令、源码与版本演进 create gatsby 是 Gatsby 官方 monorepo前端静态站点Web框架上一篇如何通过AutoFilm实现Emby/Jellyfin性能飞跃直链播放解决方案下一篇用 OfficeCLI 在 PPT 中嵌入视频四张幻灯片的完整实战与 OOXML 底层原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/13 2:13:30 · 阅读 1.2k sitespeed.io 8.1 深度解析：Filmstrip 胶片条、Server Timings 与页面交互式脚本测量
测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载本篇技术指南以 sitespeed.io 8.1发布于 2019-02-01的发布说明为骨架围绕三个核心新特性展开基于视频录制自动生成的Filmstrip 胶片条视图、在 HTML 报告中展示的Server Timings服务端计时以及随 Browsertime 4.1 引入的新脚本命令commands.js.runAndWait()。阅读本文后你将掌握如何用配置参数控制胶片条的采样密度与画质、如何在 Metrics 页解读后端计时数据以及如何编写脚本逐步测量购物/结算这类多步骤用户旅程。文中所有实现细节均对照当前仓库源码filmstrip.js、serverTimings.pug 等与官方文档交叉验证。版本背景8.1 带来了什么sitespeed.io 8.1.0 于 2019 年 2 月 1 日发布。根据仓库中的 CHANGELOG.md本次发布的核心变更包括新增 Filmstrip 标签页录制视频并保留截图时自动展示页面渲染过程的时间序列截图灵感来自 Stefan Burnicki 的 wpt-filmstrip 项目在 Metrics 指标区展示 Server Timings前提是页面返回了 Server-Timing 响应头Docker 容器升级至 Chrome 72 与 Firefox 65并同步更新 ChromeDriver / GeckoDriver升级到 Browsertime 4.1新增脚本命令js.runAndWait()允许执行自定义 JavaScript、点击链接并等待页面导航完成修复了 metric 页面显示 FullyLoaded 而非 N/A、补全 CLI 中缺失的 pre/post script 参数等问题#2278、#2282。下面逐一深入这些新能力的用法与底层实现。Filmstrip把视频帧变成可阅读的渲染时间线它是什么Filmstrip胶片条是把浏览器录制视频按固定时间间隔抽帧并按时间顺序排列成一条可视化时间线。它让你无需逐帧播放视频就能一眼看出页面何时开始渲染、何时出现关键内容、以及渲染在哪个阶段卡住。这个功能的想法最早由社区成员 Rod Barlow 提出而其呈现形式参考了 iteratec 的 wpt-filmstrip。sitespeed.io 此前在录制视频时已经通过 Visual Metrics 自动生成了逐帧截图只是没有在结果页面中利用起来——8.1 将其以独立标签页的形式呈现。如何使用使用前提是开启视频录制。在使用 Docker 运行 sitespeed.io 时视频录制默认开启因此会直接得到 Filmstrip 标签页。手动运行时可以显式指定sitespeed.io https://example.com --video --visualMetrics默认行为是以100 ms为时间跨度采样只展示那些“画面发生变化”或“恰好有指标metric落在这个时间点”的截图。换句话说一个画面长时间不变的阶段胶片条会自动跳过重复帧避免冗余。运行效果见下图控制胶片条的相关参数参数作用默认值取值范围/说明--filmstrip.showAll是否展示每一帧截图不做去重false设为true时每个 100 ms 采样点都展示--videoParams.filmstripQuality胶片条截图的压缩质量750-100数值越高画质越好、文件越大--videoParams.filmstripFullSize是否保留原始分辨率的全尺寸截图false开启后占用磁盘更多、运行耗时更长--videoParams.thumbsize缩略图最大边长400单位为像素filmstripFullSize开启时此值被覆盖--videoParams.createFilmstrip是否创建胶片条截图true不需要时可显式关闭--browsertime.videoParams.createFilmstrip false--videoParams.filmstripDiff为每帧生成与前帧的差异图及整段录制的视觉不稳定热力图false需要额外后处理时间每帧多存一张图以上参数的当前默认值与说明可以在 configuration/config.md 中找到完整记录。一个常见的调优组合示例# 展示所有帧、提高画质到 90、但不使用全尺寸截图 sitespeed.io https://example.com --video --visualMetrics \ --filmstrip.showAll \ --videoParams.filmstripQuality 90 \ --videoParams.thumbsize 800源码级实现胶片条是如何拼出来的胶片条的数据组装逻辑位于 lib/plugins/browsertime/filmstrip.js核心流程如下前置条件判断getFilmstrip()首先检查options.browsertime.visualMetrics true且options.browsertime.videoParams.createFilmstrip true第 L179-L185任一不满足则直接返回空数组保证没有录制视频时不会产生无意义的胶片条数据。读取帧文件从结果目录data/filmstrip/run/读取截图文件只处理以ms_开头的帧文件diff_*.png会被跳过见第 L196-L203。收集指标锚点通过getMetricsFromBrowsertime()把 Browsertime 数据里的事件提取为“时间锚点”包括 User Timing marks、CPU Long Task、Fully Loaded、DCL / Page Load Time、FCP、LCP、以及 Visual Metrics 的 First Visual Change、Visual Complete 85/95/99、Largest Image 等第 L20-L167。这些指标随后被映射到胶片条的时间轴上用于决定哪些帧必须展示。按步长采样默认以 100 ms 为步长遍历时间轴一个特殊细节是当启用--filmstrip.showAll且总时长超过 10 秒时步长会自动放宽到 200 ms避免帧数过多第 L209-L212。去重与锚点注入只有当当前帧文件与上一帧不同、或该时间段内有指标命中、或开启了showAll时该帧才会进入最终渲染列表第 L220-L232。这正是“默认只展示变化的帧和带指标的帧”这一行为的实现来源。此外lib/plugins/browsertime/index.js 会在汇总阶段调用getFilmstrip把胶片条数据挂到每个 run 的_meta.filmstrip上供 HTML 模板渲染。在现代版本中Filmstrip 与视频播放器、时间线一起整合进了Rendering 标签页rendering/index.pug有视频时点击帧会跳转视频到对应时刻只录屏不录视频时则由胶片条驱动大图预览。Server Timings让后端耗时出现在 HTML 报告中背景与价值Server Timing 是 W3C 提出的规范Server-Timing响应头服务端可以在响应头中携带后端处理的耗时信息例如数据库查询时间、缓存命中状态、渲染时间等。sitespeed.io 在此前几个版本中已让 Browsertime 自动采集这些数据8.1 则把它们正式呈现到 HTML 结果中——这是服务端计时能力落地的第一步当时官方也展望了后续将其接入 Graphite/Grafana 进行存储和时序展示的可能。在报告中查看只要被测页面返回了Server-Timing响应头你就能在Metrics 标签页中看到 Server timings 区块每一行包含三项内容名称Name、耗时Duration、描述Description。典型数据包括后端处理时间、缓存状态、实验开关标记等。源码级实现模板与渲染逻辑服务端计时区块的模板位于 serverTimings.pug。它的渲染逻辑有几个值得注意的工程细节条件渲染只有timings.serverTimings存在且长度大于 0 时才输出该卡片第 L12没有 Server-Timing 数据的页面不会显示空状态占位避免大多数普通页面上的无意义空白表头结构模板修复了早期版本thead/tr结构不合法的问题改用规范的 thead/tbody 结构使data-sortable排序功能可以正常工作耗时的统一格式化duration 通过h.time.ms辅助函数渲染与报告中其他计时列保持一致显示为 0 ms 这类统一格式入口挂载在 metrics/index.pug 中Server timings 会被加入页面锚点导航#server-timings并在第 L241 行通过include ./serverTimings.pug注入页面主体。后端只需在响应头中返回类似Server-Timing: db;dur23, cache;deschit的内容sitespeed.io 便会自动采集并在报告里呈现无需任何额外配置。新浏览器版本跟上用户的自更新节奏8.1 的 Docker 容器升级到了Chrome 72与Firefox 65并同步使用最新的 ChromeDriver / GeckoDriver。这一更新的意义在于如今浏览器都会自动更新你的用户大概率已经在用最新版本性能测试工具只有同样使用相近的浏览器版本才能真实还原用户环境下的表现。因此定期升级容器中的浏览器与驱动是保证测试结果与现实一致的基本维护动作。新脚本命令js.runAndWait()执行 JS 并等待页面导航完成命令语义在 8.0 引入的脚本化能力基础上8.1 随 Browsertime 4.1 带来了新命令commands.js.runAndWait()。它与普通commands.js.run()的区别在于执行 JavaScript 之后会等待页面完成导航page navigation。也就是说当你的脚本需要在页面里执行一段 JS 来点击链接、触发表单提交或引发软导航并希望完整测量这个导航过程时runAndWait正是为此设计的。相关的用法说明可以在 interact-with-the-page/index.md 中看到runAndWait会执行 JS 并等待页面加载完成检查即 Browsertime 判断“测试何时结束”的完整加载条件。在现代版本中同类的“点击后等待导航”能力也可以直接用commands.click(selector, { waitForNavigation: true })实现见 interact-with-the-page/index.md。为什么需要它在脚本测量用户旅程时最常见的需求是“点击某个元素后等待新页面加载完成再继续下一步”。如果只用js.run()触发点击却不等待测量就会在不正确的时机结束如果用measure.start()加手动等待代码又显得笨重。js.runAndWait()把“执行 JS → 等待导航完成”封装为一个原子操作让脚本更简洁、时序更可靠。典型写法module.exports async function (context, commands) { await commands.measure.start(https://shop.example.org); // 在页面中点击某个元素并等待导航完成 await commands.js.runAndWait(document.querySelector(.checkout-as-guest).click();); return commands.measure.stop(); };实战示例用脚本测量购物/结算全流程8.1 官方特别强调了脚本化测量在多步骤用户旅程Multi-step user journey上的价值你可以把购物结算的每一个环节都拆成一次独立的测量得到每个步骤各自的性能指标多次运行时还能用中位数median获得更稳定的统计结果。下面是一个完整示例在示例商店中把一件商品加入购物车并以访客身份完成结算。脚本对每个步骤分别启动/停止测量从而获得首页 → 商品页 → 购物车 → 以访客身份结算 → 完成结算五个环节各自独立的时间线。这个示例的当前版本也收录在 examples/index.md 中。module.exports async function(context, commands) { // 先测量商店首页 await commands.measure.start(https://shop.example.org); // 然后是商品页 // 你的商店可能有一个专用于测试的通用商品 // 真实场景下或许需要先校验商品确实有库存没有则换一个商品 await commands.measure.start(https://shop.example.org/prodcucs/theproduct); // 把商品加入购物车 await commands.js.run(document.querySelector(.add-to-cart).click();); // 进入购物车页并测量它 await commands.measure.start(https://shop.example.org/cart/); // 以访客身份结算也可以登录为正式客户。 // 我们隐藏 HTML避免点击链接触发 First Visual Change // 最佳情况下你不需要这么做但这里故意用一个复杂的例子 await commands.js.run(document.body.style.display none); await commands.measure.start(CheckoutAsGuest); await commands.js.runAndWait(document.querySelector(.checkout-as-guest).click();); // 停止测量并收集 CheckoutAsGuest 步骤的指标 await commands.measure.stop(); // 完成结算 await commands.js.run(document.body.style.display none); await commands.measure.start(FinishCheckout); await commands.js.runAndWait(document.querySelector(.checkout-finish).click();); // 收集 FinishCheckout 步骤的指标 return commands.measure.stop(); // 真实商店里你通常无法真正走完最后一步或者可以选择退货 // 以保证库存正确可以在脚本末尾处理也可以把商品 id 放进 // context 对象如 context.itemId yyyy然后在 postScript 里 // 用这个 id 做必要的善后处理 };这个示例的关键设计点分段测量measure.start(url)与measure.start(别名)配合measure.stop()把一次长旅程切分成多个独立的测量段落每个段落都有独立的加载时间、资源统计和视觉指标runAndWait承担导航第 9 步和第 11 步用js.runAndWait()触发点击并等待页面导航这正是 8.1 新增命令的核心应用场景隐藏 HTML 以保护视觉指标结算页点击前把document.body隐藏是为了避免点击本身引起的 DOM 变化被当作 First Visual Change从而污染视觉指标的测量结果善后钩子脚本注释中提到的context.itemId与 postScript 配合是一个处理测试下单后需要清理订单/恢复库存这类问题的推荐模式。关于measure.start/stop、click、wait等更完整的命令用法可继续阅读 measurement-commands/index.md 与 interact-with-the-page/index.md脚本的 API 参考入口是 Commands.html。运行与验证运行以上脚本文件例如保存为checkout.mjssitespeed.io checkout.mjs --multi --video --visualMetrics -n 3参数说明--multi允许脚本内部进行多次测量多步骤旅程必须开启--video --visualMetrics录制视频并计算视觉指标同时获得 Filmstrip-n 3重复运行 3 次之后在报告中取中位数结果得到更稳定的指标。运行结束后打开生成的 HTML 报告即可验证Rendering / Filmstrip 视图确认每个步骤的渲染时间线是否正确、视觉指标First Visual Change、Visual Complete 等是否与胶片条吻合关于用胶片条校准视觉指标的实践见 developers/index.mdMetrics 标签页确认每个步骤的指标是否独立呈现若有 Server-Timing 响应头则能看到 Server timings 区块。结语sitespeed.io 8.1 是脚本化测量能力走向成熟的一个重要里程碑Filmstrip 把视频从难以回放的原始素材变成了可阅读、可定位问题的渲染时间线Server Timings 让前端性能报告第一次系统性地容纳后端耗时信息js.runAndWait()则补齐了在页面内触发导航并完整测量的关键脚本原语。三个能力叠加使得购物结算这类多步骤用户旅程可以像单页测试一样被精确、稳定地逐段量化——这套方法论至今仍是 sitespeed.io 用户旅程测试的基石。完整的版本变更清单可查阅仓库根目录的 CHANGELOG.md。赞分享测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载相关推荐Nightwatch.js 性能测试初探测量页面加载与交互速度Nightwatch.js 性能测试初探测量页面加载与交互速度 为什么性能测试对现代Web应用至关重要 在用户体验至上的时代页面加载速度直接影响用户留存率与测试质量保障Elvish用 Go 打造的可编程脚本语言与交互式 Shell 深度解析Elvish用 Go 打造的可编程脚本语言与交互式 Shell 深度解析 Elvish 是一个用 Go 实现的跨平台命令行工具同时具备强大脚本语言与内CLI编程语言开发工具create-gatsby 深度解析Gatsby 交互式站点脚手架的命令、源码与版本演进create gatsby 深度解析Gatsby 交互式站点脚手架的命令、源码与版本演进 create gatsby 是 Gatsby 官方 monorepo前端静态站点Web框架上一篇如何通过AutoFilm实现Emby/Jellyfin性能飞跃直链播放解决方案下一篇用 OfficeCLI 在 PPT 中嵌入视频四张幻灯片的完整实战与 OOXML 底层原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考