在 Discourse 核心/插件/主题上进行客户端工作时，考虑性能影响非常重要。Google 的“Tachometer”项目提供了一个统计上严谨的基准测试工具，我们可以使用它来精确衡量更改的效果。
本质上，这个工具会接收一个 URL 列表，并以“循环”方式加载它们。对于每次页面加载，它都会进行一些性能测量。在数百/数千次迭代后，它会生成一个比较表。
这种“循环”方法的优点在于，它有助于减少外部因素对测量的影响。
步骤 1：添加 performance.measure()
这里的方法会根据您要测试的内容而有所不同。但根本上：您需要引入一个 performance.measure() 值供 Tachometer 读取。
如果您想衡量 Discourse 启动和渲染所需的时间，可以使用内置的“discourse-init-to-paint”测量。对于其他任何内容，您可以引入自己的 performance.measure 并使用它。
您可以使用浏览器开发者工具中的性能选项卡来检查它是否正常工作：
如果您试图测量需要用户交互的活动（例如，打开菜单），您可以通过在初始化器中添加类似以下内容来实现，该初始化器会在页面加载 1 秒后单击按钮：
setTimeout(() => document.querySelector(".my-button").click(), 1000);
步骤 2：确定要测试的 URL
首先，请确保您正在以生产模式构建 Ember 资源。这可以通过使用 EMBER_ENV=production 启动服务器来实现。
要获得两个不同的 URL，主要有两种方法：
如果您的更改足够小，可以轻松地通过功能标志来控制，那么您可以添加逻辑来根据URL 查询参数来切换它。然后您的两个 URL 可以是：
http://localhost:4200?flag=before
http://localhost:4200?flag=after
如果更改太大而无法实现，那么您可以将 Discourse 克隆到第二个目录中，并启动第二个 ember-cli 实例。可以使用类似以下的命令将其代理到同一个 Rails 服务器：
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
然后您的两个 URL 将是：
http://localhost:4200
http://localhost:4201
如果您采用此方法，请确保应用程序的两个实例都具有您在此指南的步骤 1 中引入的性能遥测功能。
步骤 3：配置 Tachometer
这是我的 bench.json 文件，它将为每个目标获取 300 个样本：
{
"timeout": 5,
"sampleSize": 300,
"benchmarks": [
{
"measurement": {
"mode": "performance",
"entryName": "discourse-init-to-paint"
},
"expand": [
{
"url": "http://localhost:4200",
"name": "before"
},
{
"url": "http://localhost:4201",
"name": "after"
}
]
}
]
}
步骤 4：运行基准测试
为了减少噪音，请停止工作站上的任何无关活动，然后使用类似以下的命令启动基准测试：
npx tachometer@latest --config ./bench.json
完成后，您应该会看到前后性能的比较。
警告
与任何此类实验一样，值得考虑其局限性。例如：
-
在您的开发工作站上的性能差异可能不会直接映射到其他浏览器/设备。
-
通过 Ember-CLI 代理的 Discourse 的启动过程与生产环境中的过程不完全相同。在进行结构性更改（例如框架更新）时，这一点可能很重要。
-
性能通常会根据应用程序状态（例如，要渲染的主题数量）而变化，因此您的结果在其他环境中可能不完全可重现。
本文档已进行版本控制 - 请在 github 上建议更改。