使用 Lighthouse CI 进行性能监控

Lighthouse CI是一套用于在持续集成期间使用 Lighthouse 的工具。Lighthouse CI 可以通过多种不同方式整合到开发人员工作流程中。本指南涵盖以下主题：

使用 Lighthouse CI CLI。
配置 CI 提供程序以运行 Lighthouse CI。
为 Lighthouse CI设置GitHub 操作和状态检查。这将在 GitHub 拉取请求上自动显示 Lighthouse 结果。
为 Lighthouse 报告构建性能仪表板和数据存储。

概述

Lighthouse CI 是一套免费工具，有助于使用 Lighthouse 进行性能监控。单个 Lighthouse 报告提供了网页在运行时的性能快照；Lighthouse CI 显示了这些发现是如何随着时间而变化的。这可用于识别特定代码更改的影响或确保在持续集成过程中满足性能阈值。尽管性能监控是 Lighthouse CI 最常见的用例，但它也可用于监控 Lighthouse 报告的其他方面——例如 SEO 或可访问性。

Lighthouse CI 的核心功能由 Lighthouse CI 命令行界面提供。（注意：这是一个独立于Lighthouse CLI的工具。） Lighthouse CI CLI 提供了一组使用 Lighthouse CI 的命令。例如，该autorun命令执行多次 Lighthouse 运行，识别中值 Lighthouse 报告，并上传报告以供存储。通过传递额外的标志或自定义 Lighthouse CI 的配置文件，可以高度自定义此行为，lighthouserc.js.

尽管 Lighthouse CI 的核心功能主要封装在 Lighthouse CI CLI 中，但 Lighthouse CI 通常通过以下方法之一使用：

运行 Lighthouse CI 作为持续集成的一部分
使用 Lighthouse CI GitHub Action 运行并对每个拉取请求进行评论
通过 Lighthouse Server 提供的仪表板随时间跟踪性能。

所有这些方法都建立在 Lighthouse CI CLI 之上。

Lighthouse CI 的替代方案包括第三方性能监控服务或编写你自己的脚本以在 CI 过程中收集性能数据。如果你希望让其他人处理你的性能监控服务器和测试设备的管理，或者如果你想要通知功能（例如电子邮件或 Slack 集成）而无需构建这些，则应该考虑使用第三方服务以自己为特色。

在本地使用 Lighthouse CI

本节介绍如何在本地运行和安装 Lighthouse CI CLI 以及如何配置lighthouserc.js. 在本地运行 Lighthouse CI CLI 是确保lighthouserc.js正确配置的最简单方法。

安装 Lighthouse CI CLI。
```
npm install -g @lhci/cli
```
Lighthouse CI 是通过将lighthouserc.js文件放在项目 repo 的根目录中来配置的。该文件是强制性的，将包含 Lighthouse CI 相关的配置信息。尽管可以将 Lighthouse CI配置为在没有 git repo的情况下使用，但本文中的说明假定你的项目 repo 已配置为使用 git。
在存储库的根目录中，创建一个lighthouserc.js 配置文件。
```
touch lighthouserc.js
```

将以下代码添加到lighthouserc.js. 此代码是一个空的 Lighthouse CI 配置。您将在后面的步骤中添加到此配置。

module.exports = {
  ci: {
    collect: {
      /* Add configuration here */
    },
    upload: {
      /* Add configuration here */
    },
  },
};

每次 Lighthouse CI 运行时，它都会启动一个服务器来为你的站点提供服务。即使没有其他服务器正在运行，该服务器也使 Lighthouse 能够加载你的站点。当 Lighthouse CI 完成运行时，它会自动关闭服务器。为确保服务正常工作，应该配置staticDistDir或startServerCommand属性。

如果你的站点是静态的，请将该staticDistDir属性添加到ci.collect对象以指示你的静态文件所在的位置。Lighthouse CI 将在测试你的站点时使用自己的服务器来提供这些文件。如果你的站点不是静态的，请将startServerCommand属性添加到ci.collect对象以指示启动服务器的命令。Lighthouse CI 将在测试期间启动一个新的服务器进程并在之后将其关闭。
```
// Static site example
collect: {
  staticDistDir: './public',
}
```
```
// Dynamic site example
collect: {
  startServerCommand: 'npm run start',
}
```
将url属性添加到ci.collect对象以指示 Lighthouse CI 应针对其运行 Lighthouse 的 URL。该url属性的值应作为 URL 数组提供；该数组可以包含一个或多个 URL。默认情况下，Lighthouse CI 将对每个 URL 运行 Lighthouse 三次。
```
collect: {
  // ...
  url: ['http://localhost:8080']
}
```
注意：这些 URL 应该可以由你在上一步中配置的服务器提供服务。因此，如果你在本地运行 Lighthouse CI，这些 URL 可能应该包含localhost而不是你的生产主机。
将target属性添加到ci.upload对象并将值设置为'temporary-public-storage'。Lighthouse CI 收集的 Lighthouse 报告将上传到临时公共存储。该报告将保留 7 天，然后自动删除。本设置指南使用“临时公共存储”上传选项，因为它可以快速设置。有关存储 Lighthouse 报告的其他方式的信息，请参阅文档。
```
upload: {
  target: 'temporary-public-storage',
}
```
报告的存储位置将与此类似：
```
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
```
（此 URL 将无法使用，因为该报告已被删除。）
使用命令从终端运行 Lighthouse CI CLI autorun。这将运行 Lighthouse 三次并上传 Lighthouse 报告的中值。
```
lhci autorun
```
如果已经正确配置 Lighthouse CI，则运行此命令应产生类似于以下内容的输出：
```
✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server on port 65324...
Running Lighthouse 3 time(s) on http://localhost:65324/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:65324/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.
```
GitHub token not set控制台输出中的消息可以忽略。只有当你想将 Lighthouse CI 与 GitHub 操作一起使用时，才需要 GitHub 令牌。本文稍后将解释如何设置 GitHub 操作。

单击输出中以开头的链接https://storage.googleapis.com...将带您进入与 Lighthouse 运行中值相对应的 Lighthouse 报告。

使用的默认值autorun可以通过命令行或lighthouserc.js. 例如，lighthouserc.js下面的配置表明每次autorun执行时应收集五个 Lighthouse 运行。

更新lighthouserc.js以使用该numberOfRuns属性：

module.exports = {
    // ...
    collect: {
      numberOfRuns: 5
    },
  // ...
  },
};

重新运行autorun命令：

lhci autorun

终端输出应该显示 Lighthouse 已经运行了五次，而不是默认的三次：

✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Automatically determined ./dist as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 64444...
Running Lighthouse 5 time(s) on http://localhost:64444/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:64444/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.

要了解其他配置选项，请参阅 Lighthouse CI配置文档。

设置 CI 流程以运行 Lighthouse CI

Lighthouse CI 可以与你最喜欢的 CI 工具一起使用。Lighthouse CI 文档的配置你的 CI 提供程序部分包含代码示例，展示了如何将 Lighthouse CI 合并到常用 CI 工具的配置文件中。具体来说，这些代码示例展示了如何运行 Lighthouse CI 以在 CI 过程中收集性能测量结果。

使用 Lighthouse CI 收集性能测量是开始性能监控的好地方。但是，如果高级用户不满足预定义的标准（例如通过特定的 Lighthouse 审核或满足所有性能预算），他们可能希望更进一步并使用 Lighthouse CI 来失败构建。此行为是通过文件的assert属性配置的lighthouserc.js。

Lighthouse CI 支持三个级别的断言：

off: 忽略断言
warn: 打印失败到 stderr
error：将失败打印到 stderr 并使用非零退出代码退出 Lighthouse CI

下面是一个lighthouserc.js包含断言的配置示例。它为 Lighthouse 的性能和可访问性类别的分数设置断言。要尝试这一点，请将下面显示的断言添加到您的lighthouserc.js文件中，然后重新运行 Lighthouse CI。

module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },
    upload: {
      // ...
    },
  },
};

它生成的控制台输出如下所示：

有关 Lighthouse CI 断言的更多信息，请参阅文档。

设置 GitHub Action 以运行 Lighthouse CI

GitHub Action可用于运行 Lighthouse CI。每次将代码更改推送到 GitHub 存储库的任何分支时，这都会生成一个新的 Lighthouse 报告。将此与状态检查结合使用，以在每个拉取请求上显示这些结果。

在存储库的根目录中，创建一个名为.github/workflows. 您项目的工作流将进入此目录。工作流是在预定时间（例如，推送代码时）运行的流程，由一个或多个操作组成。
```
mkdir .github
mkdir .github/workflows
```
在.github/workflows创建一个名为lighthouse-ci.yaml. 此文件将保存新工作流的配置。
```
touch lighthouse-ci.yaml
```

将以下文本添加到lighthouse-ci.yaml.

name: Build project and run Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 10.x
        uses: actions/setup-node@v1
        with:
          node-version: 10.x
      - name: npm install
        run: |
          npm install
      - name: run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"

此配置设置了一个由单个作业组成的工作流，只要将新代码推送到存储库，该作业就会运行。这项工作有四个步骤：
- 查看 Lighthouse CI 将运行的存储库
- 安装和配置节点
- 安装所需的 npm 包
- 运行 Lighthouse CI 并将结果上传到临时公共存储。
提交这些更改并将它们推送到 GitHub。如果您已正确执行上述步骤，将代码推送到 GitHub 将触发运行您刚刚添加的工作流。
要确认 Lighthouse CI 已触发并查看它生成的报告，请转到项目的Actions选项卡。你应该会在最近的提交下看到Build project 和 Run Lighthouse CI工作流程。

你可以从Actions选项卡导航到与特定提交对应的 Lighthouse 报告。单击提交，单击Lighthouse CI工作流步骤，然后展开运行 Lighthouse CI步骤的结果。

刚刚设置了一个 GitHub Action 来运行 Lighthouse CI。当与 GitHub状态检查结合使用时，这将是最有用的。

设置 GitHub 状态检查

状态检查（如果已配置）是显示在每个 PR 上的消息，通常包括测试结果或构建成功等信息。

以下步骤说明了如何为 Lighthouse CI 设置状态检查。

转到Lighthouse CI GitHub 应用程序页面，然后单击配置。
（可选）如果您是 GitHub 上多个组织的一部分，请选择拥有要使用 Lighthouse CI 的存储库的组织。
如果要在所有存储库中启用 Lighthouse CI，请选择所有存储库；如果您只想在特定存储库中使用 Lighthouse CI，请选择仅选择存储库，然后选择存储库。然后单击安装和授权。
复制显示的令牌。您将在下一步中使用它。
要添加令牌，请导航到GitHub 存储库的设置页面，单击Secrets，然后单击Add a new secret。
将Name字段LHCI_GITHUB_APP_TOKEN设置为并将Value字段设置为您在上一步中复制的令牌，然后单击Add secret按钮。
状态检查已准备好使用。要对其进行测试，请创建一个新的拉取请求或将提交推送到现有的拉取请求。