performance-optimization

パフォーマンスの最適化

ウェブパフォーマンスの問題を診断し、改善計画を作成します。技術スタックを問いません。Core Web Vitals と一般的なブラウザーのパフォーマンスパターンに基づいています。

このスキルは、qa-testing と seo-technical のパフォーマンスチェックよりも詳しく分析します。パフォーマンスそのものが目的の場合に使用してください。

---

使用する場合

• Core Web Vitals（LCP、INP、CLS）の改善
• ページの読み込みが遅い原因の診断
• JavaScript バンドルサイズの削減
• 画像、フォント、その他のアセットの最適化
• レイアウトシフト、レンダリングをブロックするリソース、ジャンクの修正
• リリース前のパフォーマンス検証
• 年次パフォーマンス健全性チェック

使用しない場合

• デプロイ後の一般的な QA（qa-testing を使用）
• インデックス登録やクロールを含むテクニカル SEO（seo-technical を使用）
• 一般的なバグのコードレビュー（code-review-web を使用）

---

必要な入力

• 監査対象のサイトまたはページ
• パフォーマンスに関する具体的な問題（あれば）
• 目標指標（Core Web Vitals のしきい値、Lighthouse スコア、カスタム指標）
• ブラウザーデベロッパーツールへのアクセス
• 利用可能な場合はパフォーマンス監視データ（リアルユーザーモニタリング、ラボデータ）

---

フレームワーク：Core Web Vitals

ユーザー体験と SEO の両方において、主に次の 3 つの指標が重要です。

LCP（Largest Contentful Paint）

測定内容： 最も大きな可視コンテンツ要素のレンダリングが完了するまでの時間です。

目標：

• 良好：2.5 秒未満
• 改善が必要：2.5〜4.0 秒
• 不良：4.0 秒超

LCP が不良になる一般的な原因：

• サーバー応答時間が遅い（TTFB が 800ms 超）
• レンダリングをブロックする JavaScript または CSS
• LCP 要素に使われている、最適化されていない大きな画像
• テキストのレンダリングを遅らせる、読み込みの遅いフォント
• LCP 要素のクライアントサイドレンダリング

一般的な修正方法：

• LCP 要素をサーバー側でレンダリングする（クライアントサイドレンダリングは行わない）
• LCP 画像を最適化する（適切な形式とサイズを選び、事前読み込みする）
• レンダリングをブロックするリソースを減らす（重要度の低い CSS と JS を遅延させる）
• 最新の画像形式（WebP、AVIF）を使用する
• 画像の寸法を指定し、レイアウトの再計算を回避する

INP（Interaction to Next Paint）

測定内容： ユーザー操作に対する応答性です。標準的なインタラクティビティ指標として FID に代わるものです。

目標：

• 良好：200ms 未満
• 改善が必要：200〜500ms
• 不良：500ms 超

INP が不良になる一般的な原因：

• メインスレッドをブロックする、実行時間の長い JavaScript
• 負荷の高いイベントハンドラー
• React／フレームワークの過剰な再レンダリング
• イベントハンドラー内の同期処理
• レイアウト計算の負荷が高い、大規模な DOM

一般的な修正方法：

• 長時間のタスクを分割する（scheduler.yield() または setTimeout）
• 負荷の高い計算をメモ化する
• 高頻度で発生するイベントハンドラー（スクロール、mousemove、入力）にデバウンスまたはスロットリングを適用する
• ハンドラー内で同期的なストレージ操作や DOM 操作を避ける
• DOM サイズを縮小する（理想的には 1500 要素未満）
• 可能であれば、アニメーションに JS ではなく CSS を使用する

CLS（Cumulative Layout Shift）

測定内容： ページの読み込み中にレイアウトがどれだけ動くかを示します。予期しないレイアウトシフトは使いやすさを損ないます。

目標：

• 良好：0.1 未満
• 改善が必要：0.1〜0.25
• 不良：0.25 超

CLS が不良になる一般的な原因：

• 明示的な寸法が指定されていない画像
• 読み込みが遅い広告、埋め込みコンテンツ、iframe
• 既存のコンテンツより上に動的に挿入されるコンテンツ
• FOIT／FOUT を引き起こすウェブフォント（不可視／未スタイルのテキストのちらつき）
• JS で読み込んだデータに依存する CSS

一般的な修正方法：

• 画像と動画には必ず width と height（または aspect-ratio）を指定する
• 広告や埋め込みコンテンツが読み込まれる前に、そのためのスペースを確保する
• font-display: optional または font-display: swap を適切に使用する
• 初回レンダリング後にファーストビューより上へコンテンツを挿入しない
• 重要なフォントを事前読み込みする

---

Core Web Vitals 以外

Time to First Byte（TTFB）

サーバーの応答時間です。TTFB が悪いと、ほかのすべての指標も悪化します。

目標： 800ms 未満が理想です。

よくある原因：

• リクエスト処理経路上のデータベースクエリが遅い
• N+1 クエリのパターン
• キャッシュがない
• サーバーとユーザーの地理的な距離（CDN がない）
• サーバーレス環境でのコールドスタート

対策：

• データベースクエリをキャッシュする
• 静的コンテンツとキャッシュ可能な動的コンテンツに CDN を使う
• クリティカルパスのクエリを最適化する
• 可能な場合は事前にレンダリングする（SSG、ISR）
• レイテンシーを抑えた動的コンテンツにはエッジ関数を使う

バンドルサイズ

ブラウザーに配信される JavaScript のサイズです。

目標：

• 一般的なページの初期 JS は圧縮後 170KB 未満
• 遅延読み込みされる各チャンクは圧縮後 100KB 未満

サイズ肥大化のよくある原因：

• 1 つの関数だけを使うのにライブラリ全体をインポートする
• 最新のブラウザー向けにポリフィルをバンドルする
• 開発専用コードを本番環境に含める
• 依存関係の重複（同じライブラリの複数バージョン）
• クライアント側の状態が大きい（Redux ストアのスナップショットなど）

対策：

• インポートをツリーシェイクする（import lib from 'lib' ではなく import { fn } from 'lib' を使う）
• ルートごとにコードを分割する
• ファーストビューより下のコンポーネントを遅延読み込みする
• 依存関係を監査し、容量の大きいものを置き換える（例：moment.js → date-fns またはネイティブの Intl）
• ビルド時のバンドルアナライザーで肥大化を特定する
• 使用頻度の低い機能には動的インポートを使う

画像の最適化

画像は通常、ページ容量の 60〜80 パーセントを占めます。

ベストプラクティス：

• 最新の形式を使う：対応環境では WebP、対応環境では AVIF
• レスポンシブ画像を使う：ビューポートのサイズに応じて srcset を指定する
• 遅延読み込みを使う：ファーストビューより下には loading="lazy" を指定する
• 寸法を明示する：CLS の発生を防ぐ
• 適切なサイズにする：800px で表示する画像に 4000px の画像を配信しない
• LCP 画像：プリロードし、遅延読み込みはしない

フォントの読み込み

Web フォントはテキストの表示を遅らせ、CLS を引き起こすことがよくあります。

ベストプラクティス：

• フォントをセルフホストする（サードパーティによるブロックを避ける）
• 重要なフォントをプリロードする（<link rel="preload" as="font">）
• 重要でないフォントには font-display: swap を使う
• 使用していないグリフを削除するためにフォントをサブセット化する
• 可能な場合はバリアブルフォントを使う
• 見た目が近いシステムフォントのフォールバックを指定する

サードパーティ製スクリプト

サードパーティ（分析、広告、チャットウィジェットなど）がパフォーマンス予算の大部分を占めることがよくあります。

それぞれを監査します：

• 必要ですか？
• ページを操作した後に読み込めますか（遅延実行）？
• ワーカーで実行できますか（メインスレッド外）？
• サードパーティ自体の速度は十分ですか？
• より軽量な代替手段はありますか？

よくあるパターンとして、パフォーマンス問題の 50 パーセントはサードパーティ製スクリプトに起因します。

---

ワークフロー

1. ベースラインを確立します。 Lighthouse のスキャン、WebPageTest の実行、またはリアルユーザーモニタリングのデータを使います。現在の Core Web Vitals を記録します。
2. 最も大きな問題を特定します。 LCP、INP、CLS のうち、どれが基準を満たしていませんか？ まずそこに集中します。
3. 具体的に診断します。 ブラウザーの開発者ツール（Performance タブ、Network タブ、Coverage タブ）を使います。指標が基準を満たさない実際の原因を特定します。
4. 対策を計画します。 特定した問題ごとに、具体的な変更を計画します。効果と作業量を見積もります。
5. 実装します。 可能な場合は、一度に 1 つずつ対策します。効果を測定しやすくなります。
6. 再測定します。 大きな対策を行うたびに Lighthouse を再実行し、リアルユーザーモニタリングを確認します。
7. 繰り返します。 パフォーマンスの問題は、一度の作業で解決することはほとんどありません。継続的な監視と対策を計画します。

---

ツール

ラボツール（必要に応じて実行）：

• Lighthouse（Chrome DevTools に組み込み）
• PageSpeed Insights（オンライン）
• WebPageTest（オンライン、設定の自由度が高い）
• ブラウザーの Performance タブ（詳細なフレームグラフ分析）

フィールドツール（実ユーザーデータ）：

• Chrome User Experience Report（CrUX）- 任意のサイトの公開データ
• リアルユーザーモニタリング（RUM）- 自社ユーザーのデータ（DataDog、New Relic、カスタムなど）
• Search Console の Core Web Vitals レポート

ラボツールは診断に役立ちます。ユーザーが実際に体験している内容を把握するための信頼できる情報源は、フィールドツールです。

---

失敗パターン

• 測定せずに最適化する。 ベースライン指標を測定せずに、最適化したように見せかけます。まず必ず測定してください。
• 誤った指標を最適化する。 Lighthouse のスコアが高くても、実ユーザーの指標が悪ければ、テスト条件がユーザーの実環境と一致していません。
• 過剰に最適化する。 CLS が 0.4 のまま、TTFB を 10ms 短縮するために何週間も費やします。まず最も問題の大きい箇所を修正してください。
• Lighthouse の結果だけを基準に最適化する。 Lighthouse は理想的な条件で実行されます。必ずフィールドデータも確認してください。
• 単一ページだけを最適化する。 コードベース全体でパフォーマンスの低下が進行します。パフォーマンス予算と CI チェックを導入してください。
• すべてのバイトを同じように扱う。 レンダリングを妨げる 100KB のスクリプトは、遅延読み込みされる 500KB のスクリプトより問題です。
• バンドルサイズに固執する。 バンドルサイズも重要ですが、実行時間はそれ以上に重要です。解析に 5 秒かかる小さなバンドルより、速く実行される大きなバンドルのほうが優れています。
• サードパーティを無視する。 「分析タグだから、私たちの責任ではありません」と考えます。ユーザーから見れば、サードパーティも自社ドメイン上で実行されます。責任を持って管理してください。

---

出力形式

デフォルトの出力は、performance-audit.md に保存されるパフォーマンスレポートです。

構成：

1. エグゼクティブサマリー
2. 方法論（ツール、条件、サンプルページ）
3. 現状（Core Web Vitals、Lighthouse スコア、RUM データ）
4. 重大な問題（Core Web Vitals の不合格）
5. 重要な問題（最適ではないが、不合格ではないもの）
6. 仕上げ（必須ではないが効果のある改善）
7. 改善ロードマップ（順序付け）
8. パフォーマンス予算の推奨事項
9. モニタリング計画

複雑な監査では、以下を含めてください。

• ページごとの Lighthouse エクスポート
• バンドル分析の出力
• ネットワークウォーターフォールのスクリーンショット
• 変更すべき具体的なコードスニペット

---

必要なデータを入手できない場合

このスキルの出力は、自力では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められている出力は、何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを明記した成果物です。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足事項を明記すれば、それで回答として十分です。

---

参照ファイル

• references/audit-template.md - パフォーマンス監査レポートの完全なテンプレート。
• references/optimization-checklist.md - 優先度別に一般的な最適化をまとめたクイックリファレンスチェックリスト。
• references/optimization-playbook.md - よくある Core Web Vitals の問題（LCP、INP、CLS）に対する、症状別の修正ガイド。