モーションアナリティクス は何をしますか？
モーションの品質は測定可能です。「スムーズに感じる」「参照に近い見た目」というのは主張に過ぎません。このスキルはそれらを来週も再現できる数値に変換します。
2つのジョブ:
- パフォーマンス: 各フレームにかかる時間、ページの重さ、デバイスが遅いときのページの適応方法を測定します。ガイド: references/performance.md。ツール: scripts/frame-meter.js。
- 参照グレーディング: ページが参照または自身の設計目標にどれだけ近いかを公平に判断します。ガイド: references/reference-grading.md。ツール: scripts/compare-sheet.mjs。
クイックスタート
任意のページでフレームタイムを測定する
メーターをドロップして、?meter を付けてページを開きます:
<script src="frame-meter.js" defer></script>
小さな読み取り表示にp50、p95、および推奨品質段階が表示され、コンソールには5秒ごとにサマリーがログ出力されます。コンソールから次のコマンドも実行できます:
frameMeter.start(); // クリーンな測定を開始
// ...ページをスクロールし、主なインタラクションを使用...
frameMeter.report(); // { frames, p50, p95, p99, max, fps, longFrames, jank, suggest }
ワークステーションではなく、気にする最も遅いデバイスで測定してください。アイドルフレームは負荷の高い瞬間を隠してしまうため、測定中はページ全体をスクロールし、主なインタラクションを使用してください。
サイドバイサイドシートを作成する
node scripts/compare-sheet.mjs ./shots/ours ./shots/reference ./compare --labels "Ours,Reference"
同じファイル名の画像をペアリングし、compare.html（常に作成）とcompare.png（sharpがインストールされている場合）を書き出します。グレーディングガイドに従って、このシートを評価者に渡します。
重要な数値
| 測定項目 | 目標 | 理由 |
|---|---|---|
| フレームタイム p95 | ターゲットデバイスで16.7 ms以下（60 Hz） | p95は人が感じる値。中央値はカクつきを隠す |
| フレームタイム p50 | p95よりかなり低い | ギャップが大きいとスパイク（アップロード、GC、シェーダーコンパイル）が存在する |
| 長いフレーム（50 ms超） | スクロール中は0 | それぞれが目に見えるひっかかりになる |
| 最初の画面のページウェイト | 3 MB未満 | モバイルデータでの第一印象 |
| ページ全体 | 10 MB未満 | 読み込み時間、データコスト、バッテリー |
| Largest Contentful Paint | 2.5 s未満 | 重いアセットが到着する前に合成された静止画を表示する |
| Cumulative Layout Shift | 0.1未満 | Canvasとビデオのボックスは領域を確保する必要がある |
| Interaction to Next Paint | 200 ms未満 | 重いレンダーループが入力をブロックしてはならない |
詳細、アセットタイプごとの予算、および実用的な品質ラダーについては、references/performance.mdを参照してください。
ワークフロー
- ベースライン。
?meterを付けてページを読み込み、上から下まで2回スクロールし、主なインタラクションを使用してから、frameMeter.report()を読み取ります。デバイス、ブラウザ、ビューポート、数値を書き留めます。 - 負荷の高いセクションを見つける。 セクションごとに
frameMeter.start()で開始し、report()で終了して繰り返します。最も悪いp95が作業箇所です。 - 原因を修正する。 通常は、デバイスピクセル比が高すぎる、フル解像度のポストパス、ドローコールが多すぎる、スクロール中にアップロードされるテクスチャ、初回表示時にコンパイルされるシェーダー、または非表示時のレンダリングのいずれかです。パフォーマンスガイドの修正テーブルを参照してください。
- ラダーを追加する。 高速なページでも、弱いスマートフォンではダウンスケールが必要です。ローリングラダースニペットを使用します: p95が22 msを超えたら一段階下げ、12 ms未満なら一段階上げます。
- 同じ方法で再測定する。 同じデバイス、同じパス、同じ時間。改善前後の数値を報告します。
- ターゲットと比較して評価する。 ページがデザインや参照ルックを再現する場合、4モーメントシートを作成し、references/reference-grading.md の3評価者方式を実行します。
レポート形式
Page: <name> Device: <model, browser> Viewport: <w x h, DPR>
Path: full scroll x2 + signature interaction, 60 s
Before: p50 9.8 ms, p95 31.2 ms, long frames 6, weight 14.1 MB
After: p50 7.1 ms, p95 15.9 ms, long frames 0, weight 8.7 MB
Changes: DPR cap 1.5 on phones, bloom at half res, hero textures to WebP 2048, shaders pre-compiled in loader
Ladder: tiers 0 to 3, settles at tier 3 on desktop, tier 2 on the test phone
ルール
- 平均FPSではなくp95を報告する。 平均58 fpsは毎秒のカクつきを隠す可能性があります。
- 数値ごとに1つのデバイスクラス。 1つの主張にラップトップの測定値とスマートフォンの測定値を混在させないでください。
- 毎回同じパス。 スクロールパス、インタラクション、時間が一致した場合のみ、測定値は比較可能です。
- コールドロードも測定する。 初回表示ではシェーダーのコンパイルとテクスチャのアップロードが行われます。そこに長いフレームが存在します。
- 証拠に基づいて評価する。 「近い」という判定には、一致した瞬間のシートと、ページを作成していない評価者が必要です。
関連
- レビュールーブリックとブロッキングQAチェック: ../motion-review/SKILL.md。
- クラフトワークフローとテクニックライブラリ: ../motioncraft-builder/SKILL.md。