ブラウザ・パフォーマンス・テスト

アプリケーションがウェブインターフェースを提供し、GitLab CI/CDを使用している場合、ブラウザで保留中のコード変更のレンダリングパフォーマンスへの影響を素早く判断することができます。

note
Auto DevOps を使用することで、アプリケーションでこの機能を自動化できます。

概要

GitLab では、Web サイトのレンダリングパフォーマンスを測定するための無料のオープンソースツールSitespeed.io を使用しています。GitLab が構築したSitespeed プラグインは、分析した各ページのパフォーマンススコアをbrowser-performance.json と呼ばれるファイルに出力します。

ユースケース

次のようなワークフローを考えてみましょう。

  1. マーケティングチームのメンバーが、新しいツールを追加してエンゲージメントをトラッキングしようとしています。
  2. ブラウザのパフォーマンスメトリクスを使用すると、変更がエンドユーザーにとってページのユーザビリティにどのような影響を与えているかを確認できます。
  3. メトリクスは、変更後にページのパフォーマンススコアが下がっていることを示しています。
  4. 詳細なレポートを見ると、新しいJavaScriptライブラリが<head> 、ページの読み込み速度に影響を与えていることがわかります。
  5. 彼らはフロントエンド開発者に助けを求め、ライブラリを非同期にロードするように設定します。
  6. フロントエンド開発者はマージリクエストを承認し、本番環境へのデプロイを承認します。

ブラウザのパフォーマンステストの仕組み

まず、ブラウザパフォーマンスレポートのアーティファクトを生成するジョブを.gitlab-ci.yml ファイルに定義します。GitLab はこのレポートをチェックし、各ページの主要なパフォーマンスメトリクスをソースブランチとターゲットブランチの間で比較し、マージリクエストに情報を表示します。

ブラウザパフォーマンスジョブの例については、ブラウザパフォーマンステストの設定を参照してください。

note
.gitlab-ci.yml にブラウザ・パフォーマンス・ジョブを初めて追加した場合など、ブラウザ・パフォーマンス・レポートに比較するデータがない場合、ブラウザ・パフォーマンス・レポート・ウィジェットは表示されません。そのブランチをターゲットとするマージリクエストで表示する前に、ターゲットブランチ (.gitlab-ci.yml など) で少なくとも 1 回実行する必要があります。

Browser Performance Widget

ブラウザパフォーマンステストの設定

この例では、GitLab CI/CDとDocker-in-Dockerを使用したsitespeed .ioコンテナをコード上で実行する方法を示します。

  1. まず、Docker-in-DockerビルドでGitLab Runnerをセットアップします。

  2. .gitlab-ci.yml ファイルで、デフォルトの Browser Performance Testing CI/CD ジョブを以下のように設定します：

    include:
  template: Verify/Browser-Performance.gitlab-ci.yml
   
browser_performance:
  variables:
    URL: https://example.com

上記の例では

  • CI/CDパイプラインにbrowser_performance ジョブを作成し、URL で定義したウェブページに対して sitespeed.io を実行し、主要メトリクスを収集します。
  • Kubernetesクラスタでは動作しないテンプレートを使用しています。Kubernetesクラスタを使用している場合は、代わりにtemplate: Jobs/Browser-Performance-Testing.gitlab-ci.yml 。

このテンプレートはsitespeed.io の GitLab プラグインを使用し、後でダウンロードして分析できるように、完全な HTML sitespeed.io レポートをブラウザパフォーマンスレポートのアーティファクトとして保存します。この実装では、常に最新のブラウザパフォーマンスのアーティファクトを使用します。GitLab Pagesが有効になっていれば、ブラウザで直接レポートを見ることができます。

CI/CD 変数を使ってジョブをカスタマイズすることもできます：

  • SITESPEED_IMAGE:ジョブに使用するDockerイメージを設定します（デフォルトsitespeedio/sitespeed.io ）が、イメージのバージョンは設定できません。
  • SITESPEED_VERSION:ジョブに使用するDockerイメージのバージョンを設定します (デフォルト14.1.0)。
  • SITESPEED_OPTIONS:必要に応じて、追加のsitespeed.ioオプションを設定します（デフォルトnil ）。詳細はsitespeed.ioのドキュメントを参照してください。

例えば、指定したURLでsitespeed.ioが実行する回数を上書きしたり、バージョンを変更したりできます：

include:
  template: Verify/Browser-Performance.gitlab-ci.yml

browser_performance:
  variables:
    URL: https://www.sitespeed.io/
    SITESPEED_VERSION: 13.2.0
    SITESPEED_OPTIONS: -n 5

劣化しきい値の設定

劣化アラートの感度を設定することで、メトリクスのわずかな低下をアラートとして受け取らないようにすることができます。これは、DEGRADATION_THRESHOLD CI/CD 変数を設定することで行います。以下の例では、Total Score メトリックが 5 ポイント以上低下した場合にのみアラートが表示されます：

include:
  template: Verify/Browser-Performance.gitlab-ci.yml

browser_performance:
  variables:
    URL: https://example.com
    DEGRADATION_THRESHOLD: 5

Total Score メトリクスは、sitespeed.io のcoach パフォーマンススコアに基づいています。詳細はcoach のドキュメントを参照してください。

レビューアプリのパフォーマンステスト

上記のCIのYAML設定は静的環境に対するテストに最適で、動的環境にも拡張できますが、いくつかの追加ステップが必要です：

  1. browser_performance のジョブは動的環境の開始後に実行されなければなりません。
  2. review のジョブの場合：
    1. 動的URLのURLリストファイルを生成します。
    2. このファイルをアーティファクトとして保存します。例えば、ジョブのscriptにecho $CI_ENVIRONMENT_URL > environment_url.txt と記述します。
    3. このリストをURL環境変数(URLもしくはURLを含むファイル)としてbrowser_performance のジョブに渡してください。
  3. これで、sitespeed.ioコンテナを任意のホスト名とパスに対して実行できるようになります。

.gitlab-ci.yml ファイルは以下のようになります：

stages:
  - deploy
  - performance

include:
  template: Verify/Browser-Performance.gitlab-ci.yml

review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: http://$CI_COMMIT_REF_SLUG.$APPS_DOMAIN
  script:
    - run_deploy_script
    - echo $CI_ENVIRONMENT_URL > environment_url.txt
  artifacts:
    paths:
      - environment_url.txt
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: never
    - if: $CI_COMMIT_BRANCH

browser_performance:
  dependencies:
    - review
  variables:
    URL: environment_url.txt