UIパフォーマンステスト：読み込み時間は簡単な方の半分です

UIパフォーマンステストが通常測定しているもの

初回読み込み、つまり最初の描画までの時間、操作可能になるまでの時間、バンドルサイズです。初回訪問では確かに重要で、既存のツールでも十分に測定でき、そしてその多くはセッションごとに一度きりのコストです。

ユーザーが実際に気づくもの

3つ目は本番環境に最も多く流出します。テスト環境は小さく、顧客のアカウントはそうではないからです。

重要なのに、たいてい欠けている測定

同じフローを、現実的な規模のデータセットに対して実行してください。負荷テストではありません。実際の顧客が持つデータ量のアカウントに対して、ユーザー1人で実行するだけです。10行なら80ミリ秒で描画されるリストが、2,000行では4秒かかるなら、それは欠陥です。そしてクリーンな環境でどれだけ負荷テストを重ねても、それは見つかりません。

ここでも動作の正しさが先である理由

リクエストが黙って失敗したために即座に描画される画面は、速いとは言えません。何かを測定する前に、そのフローが本来の動作をしているかを確認し、それからその所要時間を測定してください。順序が逆だと、壊れた画面について自信満々の数値が出来上がります。

誰も保守しないシードデータ入りアカウント

このページで勧めている内容の大半は、現実的なデータを持つ環境があることを前提にしています。そして、チームがそれを用意できない理由には、正面から触れておく価値があります。

用意すること自体は簡単です。難しいのは、それを現実的なまま保つことです。スキーマは変わり、シードスクリプトは古びていき、2四半期も経てば、もはや何にも似ていないアカウントが出来上がります。そうなると誰もそれを信用しなくなり、また10行でのテストに戻ってしまいます。

生き残るのは、固定のスクリプトではなく本番のデータの姿から生成する方式です。実際のアカウントが持つレコード数の分布を取り、その90パーセンタイルに当たるテストアカウントを作ります。継続的に保守する必要はなく、ときどき再生成すれば済みますし、実際の顧客が持っているデータから導かれているため、現実とずれません。

絶対値よりも、劣化の検出を

ベンチマークから借りてきた絶対的な目標値が、そのまま当てはまることはほとんどありません。同じ環境で自分たちの数値を記録し、その変化を見てください。役に立つアラートは、今週このフローが遅くなったという通知であって、誰かが決めた数値を超えたという通知ではありません。

ローカルにインストールしたくない場合は、ダッシュボードでも同じ範囲をカバーできます。コマンドの全容は CLIリポジトリにあります。

パイプラインが別のチームの管轄なら、最も摩擦が少ないのは GitHub App です。これはWebhookであり、リポジトリには何も変更を加えず、ビルドが新しいバージョンの公開を通知した時点で実行されます。そうではなく、チェックをリポジトリ上で見えるようにしたい場合は、 GitHub Actions のステップでそれができます。

TestSpriteが最初に検証すること

動作の正しさです。これは、あらゆるパフォーマンスの数値が意味を持つための前提になります。リクエストが黙って失敗したために即座に描画される画面は、見事なスコアを出します。TestSpriteが捉えるのは、まさにその種の不具合です。

テストは製品そのものから生成され、変更のたびにデプロイ済みのアプリケーションに対して実行されます。そこには、現実的なデータ量を投入したアカウントに対する実行も含まれます。本番環境まで到達する性能劣化が実際に姿を現すのは、そこだからです。

計測やプロファイリングは、専用のツールの担当領域です。ここで得られるのは、測定しているフローがきちんと動いているという確信と、リストがスケールしなくなったときの早期のシグナルです。変わるのは時間だけでなく、挙動そのものだからです。