フロントエンドのパフォーマンスモニタリングについて調査
- 結論
- 計測対象を決める
- 計測タイミングを決める
- モニタリング指標を決める
- モニタリングの方法（Synthetic monitoring と Real User Monitoring）
- ツールの評価ポイント
- 計測ツールを決める
- パフォーマンスモニタリングするために必要なアクション
- 用語メモ
- 参考にしたサイトや書籍
結論
- 計測する項目がいろいろあるので、プロダクトの特性に合わせて見るべき数値を考える
- とりあえず計測してみてデータを集める
- まずは計測、いきなり改善しようとしない
計測対象を決める
計測タイミングを決める
- PRのタイミング
- masterにmargeされたとき
- 定期的に
細かく計測できるのが理想だが、料金と相談
ピーク時間のパフォーマンスが重要なので予めピーク時間の検討をつける（計測してみて、アクセスが少ない時間帯の計測を削る方法もありそう）
モニタリング指標を決める
主な計測指標
- Time To First Byte...最初のバイトを受け取るまでの時間
- DOMContentLoaded...HTMLドキュメントのダウンロードとDOMツリーの構築が完了するまでの時間
- load...CSS/JS/画像などのサブリソースのダウンロードと評価が完了（遅延ロード除く）
Throughput...同時接続数/同時リクエスト数
First Paint (FP)...ページが表示され始める（Paint Timing APIで定義）
- First Contentful Paint (FCP)...コンテンツが表示され始める（Paint Timing APIで定義）
- First Meaningful Paint (FMP)...ユーザに意味のある表示になる（標準化されていないので実装側で要算出）
- Time To Interactive (TTI)...ユーザの操作に応答できるようになる（標準化されていないので実装側で要算出）
- Speed Index...Above the Fold（ファーストビュー）のレンダリング時間を示すスコア（Resource Timing APIから算出） https://github.com/WPO-Foundation/RUM-SpeedIndex
アプリの特性によって見るべき指標は異なる
- CSR(クライアントサイトレンダリング): 真っ白な時間が長いのでFMPを指標に
- SSR(サーバサイドレンダリング): 真っ白な時間は短いが、操作できるまで(JSを読む)の時間を測るためTTIを指標に
ページロードはn秒以内を目指す。
『入門監視』では4秒とある。
競合サービスを計測し、目標値を決める。
モニタリングの方法（Synthetic monitoring と Real User Monitoring）
Synthetic monitoring
サーバから計測のためのリクエストを送る。
環境にばらつきなし、定期実行しやすい、実際の環境とは乖離することがある。
Real User Monitoring
ユーザがアクセスしたときに埋め込まれたJavaScriptが走りサーバにデータを投げる。
環境にばらつきあり、実際の環境に近い。
ツールの評価ポイント
- RUM、Synthetic対応しているか
- 対応ブラウザ
- 対応デバイス
- 対応リージョン
- CIに組み込めるか
計測ツールを決める
下記に一部の計測ツール例を示す。
WebPageTest
https://www.webpagetest.org/
SaaS。Synthetic Monitoring。
SpeedCurve
SaaS。SpeedCurve syntheticはWebPageTestを使用している。
SpeedCurve LUXというツールでRUMも計測できる。
Lighthouse
ChromeのDebbuggingAPIを使って動く。参考
PageSpeed Insights
Lighthouseの上で動いている分析ツール
sitespeed.io
https://www.sitespeed.io/
pluginとしてWebPageTestを動かせる。
gitlab-ciとsitespeed.ioのドキュメント
pingdom
appdynamics
catchpoint
パフォーマンスモニタリングするために必要なアクション
- とりあえず無料枠でやってみる
- RUMとSynthetic両方やる
- 計測ツールの比較
- 計測ツールの動作原理を把握
- アプリの特性の把握
用語メモ
- median：中央値
- avarage：平均値（外れ値の影響を受けやすい）
- nパーセンタイル：上位(100-n)%のデータを捨てた最大値。大部分の傾向はどの様になっているか把握する。
例：課金やレイテンシのレポート - performance budget：パフォーマンスにおいて一定の基準を決めて、それを超えないように管理すること。
c.f. https://developers-jp.googleblog.com/2019/03/blog-post_15.html
