ウェブパフォーマンス監査

目次

• 概要
• 使用するべき場面
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

ウェブパフォーマンス監査は、ロード時間を測定し、ボトルネックを特定し、より高速で優れたユーザーエクスペリエンスを実現するための最適化の取り組みを指導します。

使用するべき場面

• 定期的なパフォーマンス監視
• 大規模な変更後
• ユーザーからの速度に関する苦情
• SEO最適化
• モバイル最適化
• パフォーマンスベースラインの設定

クイックスタート

最小限の動作例：

Core Web Vitals (Google):

Largest Contentful Paint (LCP):
  Measure: Time to load largest visible element
  Good: <2.5 seconds
  Poor: >4 seconds
  Impacts: User perception of speed

First Input Delay (FID):
  Measure: Time from user input to response
  Good: <100 milliseconds
  Poor: >300 milliseconds
  Impacts: Responsiveness

Cumulative Layout Shift (CLS):
  Measure: Visual stability (unexpected layout shifts)
  Good: <0.1
  Poor: >0.25
  Impacts: User frustration

---

Additional Metrics:

First Contentful Paint (FCP):
// ... (see reference guides for full implementation)

リファレンスガイド

references/ ディレクトリの詳細な実装：

ベストプラクティス

✅ すべきこと

• 定期的に測定する（1回限りではなく）
• フィールドデータ（実際のユーザー）とラボデータの両方を使用する
• Core Web Vitals に焦点を当てる
• 現実的なターゲットを設定する
• インパクト順に優先順位を付ける
• 継続的に監視する
• パフォーマンスバジェットをセットアップする
• 低速ネットワークでテストする
• テストにモバイルを含める
• 改善を文書化する

❌ してはいけないこと

• フィールドデータを無視する
• 1つのメトリクスだけに焦点を当てる
• 達成不可能なターゲットを設定する
• 測定なしに最適化する
• 画像を忘れる
• JavaScript のコストを無視する
• モバイルパフォーマンスをスキップする
• 時期尚早に過度に最適化する
• 監視を忘れる
• 努力なしに改善を期待する