フロント側のパフォーマンス改善を行なっていくため、各ツールの比較を行いました。
今のプロジェクトでは「運用・保守」の工程に携わっていて、パフォーマンス改善を絶賛やっています。そこで「フロント側のパフォーマンス改善をするにはどうやっていく？」を考えるために「目的」「進め方」「使用するツール」の整理・調査をしたので、こちらにまとめておきたいと思います。
各ツールの詳細な調査結果は 「ツール候補」 から書いているので、各ツールについて知りたい方はそこからどうぞ。
評価
早速、結論から。
ツール候補の一覧と要件+その他の観点で評価した表がこちらです。
| ツール名 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Lighthouse-ci | ○ | ○ | × | × | × | ○ | × |
| datadog RUM | ○ | ○ | △ | × | ○ | ○ | ○ |
| WebPageTest API | ○ | ○ | ○ | × | △ | △ | ○ |
- 定期的＆自動で計測したい
- 計測結果は時系列で記録してクラウド（box, S3等）に蓄積したい
- ツールの設定は自チームで完結させたい
- 修正箇所の指摘内容が具体的であること
- 環境構築の工数・手間
- Core Web Vitalsで評価
- サイト全体を確認できるダッシュボード有無
目的
サイト全体でパフォーマンスの改善ができる箇所の発見＆改善を通して、サイトの速度/使いやすさ/SEOを向上させること。
どの指標で改善を行うのか？
指標には「Core Web Vitals」を使います。
「Core Web Vitals」とはGoogleが提唱する、Webのパフォーマンスを評価するための品質指標です。
・LCP：重要なコンテンツがどれだけ早く読み込まれたか
・FID：ユーザーが最初の操作ができるようになるまでの時間(入力で計測)
・CLS：レイアウトの変化が大きく生じていないか
要件
使用するツールを検討するために要件の整理、つまり、"使用するツール・計測方法には何が必要か"を整理しました。
-
定期的＆自動で計測したい
手動での計測だと手間がかかったり、実行漏れが起きたりするため -
計測結果は時系列で記録してクラウド（box, S3等）に蓄積したい
パフォーマンスの改善は長期的な取り組みとなるため時系列で追う必要があるため -
ツールの設定は自チームで完結させたい
設定変更に他チームが絡むことで対応待ちが発生し、改善のスピードが遅くなるため -
修正箇所の指摘内容が具体的であること
計測結果が数値のみだと、その数値を改善するためにどのような対応が必要なのかを調査するコストがかかるため。具体的な内容であればあるほど対応コストを削減できる。
対応方針
「改善サイクルをまず回す」「改善サイクルを効率的に回すための取り組みを実施」の2つをメインに取り組んでいきます。
改善サイクルの内容
- 対象の画面に計測を実施。結果を保存
- 結果から必要となる改善を実施
- 対応後に再度計測を実施。結果から効果検証を行う。
→ 1.に戻る
上記の改善サイクルを回す中で、"どの項目の数値が重要なのか"、"どの値を継続的に見たいのか"、"そもそも継続的に見る必要があるのか"、を把握する。また、このサイクルの中で、結果の評価方法(どの点が良くなれば改善されたと判断するのか)も固めていきたい。
その中で、継続的に結果を蓄積する必要があるのか？定期的に計測することが必要なのか？視覚化する必要があるか？を判断していきたいと考えました。
ツール候補
フロントエンドのパフォーマンス改善を行うために使うツールの候補がこれらです。
・Lighthouse-ci
・Datadog RUM
・WebPageTest
それぞれのツールについて深掘りしていきます。
Lighthouse-ci
Webページの品質を測定できるツール「LightHouse」をCIに組み込んで実行が可能なツール。CIとして使用することが基本的な使い方です。
▼特徴
・Core Web Vitalsを数値で計測できる
・結果を継続的に蓄積する場合はそれ専用にサーバーを立てる必要がある
▼要件を満たしているか
■定期的＆自動で計測したい：○
- Github PRをトリガーにできる ※その他をトリガーにできるかは要確認
- cronでも可能そう
■計測結果はクラウド（box, S3等）にアップして時系列で追えるようにしたい：○
- 但し、別途、蓄積用のサーバーが必要
- 結果について、Github Actionsの場合はログに出力される
- 継続的な結果を見たいのであれば、CI Serverの構築が必要(EC2?)
■ツールの設定は自チームで完結させたい：×
- サーバー構築の部分でインフラチームとの連携が必要
- 実行のみであればGithubで可能
- 継続的な結果を見たい場合はEC2にCI Serverの構築が必要になるため、始めはインフラチームへの依頼が必要になる可能性あり
■修正箇所の指摘内容が具体的であること：×
- 指摘事項と関連している対象のリソースはレポートで確認可能
要確認事項
- Lighthouse-ciを使用するための条件に該当しているかどうか
▼使用条件
https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#prerequisites
Datadog RUM
サービスの監視ツール「Datadog」内にある別ツールです。フロントのパフォーマンス計測だけでなく、フロントで発生するエラーの収集も可能。
▼特徴
・Core Web Vitalsを数値で計測できる
(@datadog/browser-rum v2.2.0以降が必要)
・ダッシュボードでサイト全体のパフォーマンス状況の確認が可能
▼要件を満たしているか
■定期的＆自動で計測したい：○
- ダッシュボード or レポートで計測結果を見ることが可能
- Syntheticsと組み合わせることでCI/CDへの組み込みも可能
(↑コメントにて情報提供いただきました
)
■計測結果はクラウド（box, S3等）にアップして時系列で追えるようにしたい：○
- CoreWebVitalsはSession Replaysから算出しており、保存期間は30日
- 手動でcsv出力ができるため、別途記録するのであればスプレッドシート等に記録する
参考:収集された RUM ブラウザデータ
https://docs.datadoghq.com/ja/real_user_monitoring/browser/data_collected/
参考:Datadog のデータ収集、解決、保持
https://docs.datadoghq.com/developers/guide/data-collection-resolution-retention/
■ツールの設定は自チームで完結させたい：△
- 設定に際して、datadogアカウントの権限が必要になる可能性があるため、権限の対応をインフラチームに依頼する必要がある(datadogの管理を自チームで行なっている場合は○)
参考：RUM の使用方法
https://docs.datadoghq.com/ja/real_user_monitoring/installation/?tab=us
■修正箇所の指摘内容が具体的であること：×
- 計測結果の可視化はできるが、レポート機能や指摘事項は無い。改善内容は考える必要あり
要確認事項
- Datadogの@datadog/browser-rum v2.2.0以降をインストールできるかどうか(Core Web Vitalsの確認のために必要)
WebPageTest
Googleが中心に開発しているOSSです。APIを使用するのであれば有料プランの契約必要です。
▼特徴
・スプレッドシート＆GoogleDataStudio等、別ツールと組み合わせることでダッシュボードの生成が可能(デフォルトは無い)
・定期的な計測にはAPIが必要であり、APIを定期的に実行するための環境が別途必要
・Core Web Vitalsの計測は不可
※有料プラン(2022年9月確認時点)
月間プラン：18.75＄/月
年間プラン：180＄/年
▼要件を満たしているか
■定期的＆自動で計測したい：○
- GAS or CloudWatchEvents + WebPageTestAPIで可能
結果を見るだけの用途であれば集計の手間は生じないため、選択肢としてはアリ。
■計測結果はクラウド（box, S3等）にアップして時系列で追えるようにしたい：○
- APIの実行結果をスプレッドシートに記載することが可能
■ツールの設定は自チームで完結させたい：○
- GASで可能
CloudWatchEventsを使用する場合はインフラチームとの連携が必要になる可能性あり
■修正箇所の指摘内容が具体的であること：×
- 数値の結果は出力可能
同時にLightHouseの実行も可能なので、具体的な修正箇所はそちらで確認するのもアリか
その他
評価段階で惜しくも落選しましたが、調査段階で候補として上がっていた測定方法です。
Chrome Developer Tools
計測のための環境構築不要。定期実行、ダッシュボード等は不可。
JavaScriptによる計測
ソースの変更が必要。定期実行、ダッシュボード等は不可。
まとめ：あるべき姿を見据えて、対応工数とのバランスを考える
以上、各ツールとパフォーマンス改善の目的や対応フローについて整理しました。
様々なツールはありますが「何をゴールとするのか」をきちんと整理しておくことが重要だと思います。
それでは！
参考
▼Core Web Vitals関連
Web Vitals の概要: サイトの健全性を示す重要指標
https://developers-jp.googleblog.com/2020/05/web-vitals.html
▼lighthouse-ci
GoogleChrome/lighthouse-ci
https://github.com/GoogleChrome/lighthouse-ci/blob/main/README.md
ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)
https://techblog.yahoo.co.jp/entry/2022090530337093/
Lighthouse CIを利用したWebサイト品質監査の自動化
https://medium.com/@yonemoto/lighthouse-ci%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9Fweb%E3%82%B5%E3%82%A4%E3%83%88%E5%93%81%E8%B3%AA%E7%9B%A3%E6%9F%BB%E3%81%AE%E8%87%AA%E5%8B%95%E5%8C%96-9f1b3b431c54
▼datadog
収集された RUM ブラウザデータ
https://docs.datadoghq.com/ja/real_user_monitoring/browser/data_collected/
RUM の使用方法
https://docs.datadoghq.com/ja/real_user_monitoring/installation/?tab=us
スケジュールされたレポート
https://docs.datadoghq.com/ja/dashboards/scheduled_reports/
Datadog Synthetic テストを CI/CD パイプラインに組み込む
https://www.datadoghq.com/ja/blog/datadog-synthetic-ci-cd-testing/
Datadog のデータ収集、解決、保持
https://docs.datadoghq.com/developers/guide/data-collection-resolution-retention/
▼WebpageTest
Webpagetestから始める継続的パフォーマンス改善
https://azu.github.io/slide/2018/roppongijs/webpagetest-performance.html