使用 Lighthouse CI 和 GitHub Actions 进行持续性能分析

Lighthouse 是一个免费且开源的工具，用于评估网站的性能、可访问性、渐进式 Web 应用指标、SEO 等。最简单的方法是通过 Chrome DevTools 面板使用它。打开 DevTools 后，您将看到一个“Lighthouse”选项卡。点击“生成报告”按钮将在网页上运行一系列测试，并在 Lighthouse 选项卡中显示结果。这使得测试任何网页变得容易，无论其是否公开或需要身份验证。

如果您不使用 Chrome 或基于 Chromium 的浏览器（如 Microsoft Edge 或 Brave），可以通过其 Web 界面运行 Lighthouse，但它只适用于公开可用的网页。对于希望从命令行运行 Lighthouse 审计的人来说，还提供了一个 Node CLI 工具。

上面列出的所有选项都需要某种形式的手动干预。如果我们可以将 Lighthouse 测试集成到持续集成过程中，以便代码更改的影响可以在每个拉取请求中内联显示，并且如果某些性能阈值未满足，我们可以使构建失败，那不是很好吗？这就是 Lighthouse CI 存在的原因！

它是一套工具，可帮助您识别特定代码更改对网站的影响，不仅是性能方面，还包括 SEO、可访问性、离线支持和其他最佳实践方面。它提供了一种很好的方式来执行性能预算，还可以帮助您跟踪每个报告的指标，以便您可以查看它们如何随着时间的推移而变化。

在本文中，我们将介绍如何设置 Lighthouse CI 并将其在本地运行，然后介绍如何通过 GitHub Actions 将其作为 CI 工作流程的一部分进行运行。请注意，如果您不想使用 GitHub Actions，Lighthouse CI 也适用于其他 CI 提供商，例如 Travis CI、GitLab CI 和 Circle CI。

在本地设置 Lighthouse CI

在本节中，您将在机器上本地配置和运行 Lighthouse CI 命令行工具。在继续之前，请确保您的机器上安装了 Node.js v10 LTS 或更高版本以及 Google Chrome（稳定版），然后继续全局安装 Lighthouse CI 工具

$ npm install -g @lhci/cli

CLI 安装成功后，运行 lhci --help 以查看该工具提供的所有可用命令。在撰写本文时，有八个可用命令。

$ lhci --help
lhci <command> <options>

Commands:
  lhci collect      Run Lighthouse and save the results to a local folder
  lhci upload       Save the results to the server
  lhci assert       Assert that the latest results meet expectations
  lhci autorun      Run collect/assert/upload with sensible defaults
  lhci healthcheck  Run diagnostics to ensure a valid configuration
  lhci open         Opens the HTML reports of collected runs
  lhci wizard       Step-by-step wizard for CI tasks like creating a project
  lhci server       Run Lighthouse CI server

Options:
  --help             Show help  [boolean]
  --version          Show version number  [boolean]
  --no-lighthouserc  Disables automatic usage of a .lighthouserc file.  [boolean]
  --config           Path to JSON config file

此时，您已准备好为您的项目配置 CLI。Lighthouse CI 配置可以通过（按优先级递增顺序）配置文件、环境变量或 CLI 标志进行管理。它使用 Yargs API 来读取其配置选项，这意味着在配置方式方面具有很大的灵活性。完整的文档涵盖了所有内容。在这篇文章中，我们将使用配置文件选项。

继续在项目的根目录中创建一个 lighthouserc.js 文件。确保项目正在使用 Git 进行跟踪，因为 Lighthouse CI 会自动从 Git 存储库中推断构建上下文设置。如果您的项目不使用 Git，则可以通过环境变量来控制构建上下文设置。

touch lighthouserc.js

以下是最简单的配置，它将为静态网站项目运行并收集 Lighthouse 报告，并将它们上传到临时公共存储中。

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      staticDistDir: './public',
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

ci.collect 对象提供了一些选项来控制 Lighthouse CI 如何收集测试报告。staticDistDir 选项用于指示静态 HTML 文件的位置 - 例如，Hugo 构建到 public 目录，Jekyll 将其构建文件放在 _site 目录中，等等。您只需将 staticDistDir 选项更新到您的构建所在的任何位置。当 Lighthouse CI 运行时，它将启动一个服务器，该服务器能够相应地运行测试。测试完成后，服务器将自动关闭。

如果您的项目需要使用自定义服务器，则可以通过 startServerCommand 属性输入用于启动服务器的命令。使用此选项时，您还需要通过 url 选项指定要测试的 URL。此 URL 应该可以由您指定的自定义服务器提供服务。

module.exports = {
  ci: {
    collect: {
      startServerCommand: 'npm run server',
      url: ['http://localhost:4000/'],
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

当 Lighthouse CI 运行时，它会执行 server 命令并监视 listen 或 ready 字符串以确定服务器是否已启动。如果它在 10 秒后没有检测到此字符串，则认为服务器已启动并继续进行测试。然后它会针对 url 数组中的每个 URL 运行三次 Lighthouse。测试完成后，它会关闭服务器进程。

您可以分别通过 startServerReadyPattern 和 startServerReadyTimeout 选项配置要监视的模式字符串和超时持续时间。如果您想更改针对每个 URL 运行 Lighthouse 的次数，请使用 numberOfRuns 属性。

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      startServerCommand: 'npm run server',
      url: ['http://localhost:4000/'],
      startServerReadyPattern: 'Server is running on PORT 4000',
      startServerReadyTimeout: 20000 // milliseconds
      numberOfRuns: 5,
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

ci.upload 对象内的 target 属性用于配置测试完成后 Lighthouse CI 上传结果的位置。temporary-public-storage 选项表示报告将上传到 Google 的云存储，并保留几天。它还将对拥有链接的任何人可用，无需身份验证。如果您希望更详细地控制报告的存储方式，请参考文档。

此时，您应该已经准备好运行 Lighthouse CI 工具。使用以下命令启动 CLI。它将针对提供的 URL（除非通过 numberOfRuns 选项更改）运行三次 Lighthouse，并将中位数结果上传到配置的目标。

lhci autorun

输出应该类似于下面显示的内容

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

Started a web server on port 52195...
Running Lighthouse 3 time(s) on http://localhost:52195/web-development-with-go/
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on http://localhost:52195/custom-html5-video/
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:52195/web-development-with-go/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1606403407045-45763.report.html
Uploading median LHR of http://localhost:52195/custom-html5-video/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1606403400243-5952.report.html
Saving URL map for GitHub repository ayoisaiah/freshman...success!
No GitHub token set, skipping GitHub status check.

Done running autorun.

GitHub 令牌消息暂时可以忽略。我们将在设置 Lighthouse CI 与 GitHub Actions 一起使用时配置一个。您可以在浏览器中打开 Lighthouse 报告链接，以查看每个 URL 的中位数测试结果。

配置断言

使用 Lighthouse CI 工具来运行和收集 Lighthouse 报告已经足够好了，但我们可以更进一步，配置该工具，以便如果测试结果不符合某些标准，则构建会失败。通过 assert 属性可以配置控制此行为的选项。以下是一段显示示例配置的代码片段

// lighthouserc.js
module.exports = {
  ci: {
    assert: {
      preset: 'lighthouse:no-pwa',
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'categories:accessibility': ['warn', { minScore: 0.9 }],
      },
    },
  },
};

preset 选项是配置 Lighthouse 断言的快速方法。有三种选择

lighthouse:all：断言每个审计都获得了满分
lighthouse:recommended：断言每个性能以外的审计都获得了满分，并在指标值低于 90 分时发出警告
lighthouse:no-pwa：与 lighthouse:recommended 相同，但没有 PWA 审计

您可以使用 assertions 对象来覆盖或扩展预设，或者从头开始构建自定义断言集。上面的配置断言 performance 和 accessibility 类别的基线分数为 90。区别在于前者失败将导致非零退出代码，而后者则不会。可以对 Lighthouse 中任何审计的结果进行断言，因此您可以做很多事情。请务必查阅文档以了解所有可用的选项。

您还可以针对 budget.json 文件配置断言。可以手动创建此文件，也可以通过 performancebudget.io 生成。获得文件后，将其作为 assert 对象的一部分提供，如下所示

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      staticDistDir: './public',
      url: ['/'],
    },
    assert: {
      budgetFile: './budget.json',
    },
    upload: {
      target: 'temporary-public-storage',
    },
  },
};

使用 GitHub Actions 运行 Lighthouse CI

将 Lighthouse CI 集成到开发工作流程中的一种有用方法是为提交到项目 GitHub 存储库的每个提交或拉取请求生成新的报告。这就是 GitHub Actions 的作用所在。

要进行设置，您需要在项目的根目录中创建一个 .github/workflow 目录。这是您项目的全部分工作流程将被放置的位置。如果您不熟悉 GitHub Actions，可以将工作流程视为一组一个或多个操作，这些操作将在事件触发时执行（例如，当对仓库进行新的拉取请求时）。Sarah Drasner 有一篇关于使用 GitHub Actions 的不错的入门介绍。

mkdir -p .github/workflow

接下来，在 .github/workflow 目录中创建一个 YAML 文件。您可以将其命名为任何名称，只要以 .yml 或 .yaml 扩展名结尾即可。此文件是放置 Lighthouse CI 工作流程配置的位置。

cd .github/workflow
touch lighthouse-ci.yaml

lighthouse-ci.yaml 文件的内容会根据项目的类型而有所不同。我将描述我如何为我的 Hugo 网站设置它，以便您可以将其应用于其他类型的项目。这是我的完整配置文件

# .github/workflow/lighthouse-ci.yaml
name: Lighthouse
on: [push]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        with:
          token: ${{ secrets.PAT }}
          submodules: recursive

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.76.5"
          extended: true

      - name: Build site
        run: hugo

      - name: Use Node.js 15.x
        uses: actions/setup-node@v2
        with:
          node-version: 15.x
      - name: Run the Lighthouse CI
        run: |
          npm install -g @lhci/[email protected]
          lhci autorun

上面的配置创建了一个名为 Lighthouse 的工作流，它包含一个名为 ci 的作业，该作业在 Ubuntu 实例上运行，并在代码被推送到存储库中的任何分支时触发。该作业包括以下步骤

检出 Lighthouse CI 将要运行的存储库。Hugo 使用子模块来管理其主题，因此必须确保存储库中的所有子模块都被检出。如果任何子模块位于私有存储库中，您需要创建一个新的个人访问令牌，并启用 repo 范围，然后将其作为存储库机密添加到 https://github.com/<username>/<repo>/settings/secret。如果没有此令牌，如果遇到私有存储库，此步骤将失败。

在 GitHub Actions 虚拟机上安装 Hugo，以便可以使用它来构建网站。这是我在这里使用的 Hugo 设置操作。您可以在 GitHub Actions 市场中找到其他设置操作。
通过 hugo 命令将站点构建到 public 文件夹中。
通过 setup-node 操作在虚拟机上安装和配置 Node.js
安装 Lighthouse CI 工具并执行 lhci autorun 命令。

设置完配置文件后，您可以提交并推送更改到您的 GitHub 存储库。这将触发您刚刚添加的工作流，前提是您的配置设置正确。转到项目存储库中的 Actions 选项卡，查看最近提交下工作流的状态。

如果您点击并展开 ci 作业，您将看到每个作业步骤的日志。在我的情况下，一切都运行成功，但我的断言失败了——因此失败状态。就像我们在本地运行测试时看到的那样，结果被上传到临时公共存储，您可以通过点击日志中的相应链接来查看它们。

设置 GitHub 状态检查

目前，Lighthouse CI 已被配置为在代码被推送到存储库时立即运行，无论是在直接推送到分支还是通过拉取请求。测试状态显示在提交页面上，但您需要点击并展开日志才能查看完整详细信息，包括报告链接。

您可以设置一个 GitHub 状态检查，以便构建报告直接显示在拉取请求中。要进行设置，请访问 Lighthouse CI GitHub 应用页面，点击“配置”选项，然后在您的 GitHub 帐户或拥有您要使用的 GitHub 存储库的组织上安装并授权它。接下来，复制确认页面上提供的应用程序令牌，并将其添加到您的存储库机密中，名称字段设置为 LHCI_GITHUB_APP_TOKEN。

状态检查现在可以用了。您可以通过打开新的拉取请求或将提交推送到现有的拉取请求来试用它。

通过 Lighthouse CI 服务器进行历史报告和比较

使用临时公共存储选项来存储 Lighthouse 报告是一种很好的入门方式，但如果您想将数据保密或保存更长时间，它就远远不够。这就是 Lighthouse CI 服务器可以提供帮助的地方。它提供了一个仪表板来浏览历史 Lighthouse 数据，并提供了一个很棒的比较 UI 来发现构建之间的差异。

要使用 Lighthouse CI 服务器，您需要将其部署到您自己的基础设施中。有关部署到 Heroku 和 Docker 的详细说明和食谱可以在 GitHub 上找到。

结论

设置配置时，最好包含几个不同的 URL，以确保良好的测试覆盖率。对于一个典型的博客，您肯定需要包含主页、一到两篇代表网站内容类型的文章，以及任何其他重要的页面。

虽然我们没有涵盖 Lighthouse CI 工具的所有功能，但我希望这篇文章不仅能帮助您开始使用它，还能让您了解它还能做什么。感谢您的阅读，祝您编码愉快！

在本地设置 Lighthouse CI

配置断言

使用 GitHub Actions 运行 Lighthouse CI

设置 GitHub 状态检查

通过 Lighthouse CI 服务器进行历史报告和比较

结论

评论