まず顧客ジャーニーをプロファイルしてからコードを変える
ナビゲーションを開く、結果を絞り込む、フォームを送信するなど、重要なルートと操作を1つ選択します。Chrome DevTools の Performance パネルでクリーンなブラウザ状態から記録してください。アクションを繰り返し、スロットルした CPU の実行と開発機の実行の両方をキャプチャします。デスクトップのトレースは低スペックの電話上で問題を隠すことがあります。
トレースは、バンドルレポートだけを根拠にコンポーネントを決めつけるためではなく、狭い仮説を検証するために使います。Main flame chart では幅の広いバーが処理時間が長いことを示し、積み重なったバーはコールスタックを表します。タスク上の赤い三角は潜在的な長時間タスクを示します。タスクを選択し、発端となったコードへのリンクをたどってください。意味のある変更に備えて、ビフォーアフタートレースを保存します。
アクションの直前から記録を開始し、表示される結果の後で停止します。
ルート、アカウント状態、操作の順序を一貫させます。
各トップコストを変更できるチームまたはベンダに割り当てます。
トレースを作業のキューとして読む
長時間タスクは調査のしきい値であって、完全な診断ではありません。W3C の Long Tasks 仕様は 50 ミリ秒以上のタスクを報告します。タスクの内訳を確認し、JavaScript の評価、イベントハンドラ、スタイル再計算、レイアウト、ペイントなどを探してください。コールスタックはどこから手を付けるべきかを示し、タイミングは問題がコード、レンダリング、またはサードパーティに起因するものかを示します。
価値のある操作中に繰り返し発生するコストを優先してください。短いハンドラでも、レイアウトを引き起こしたり前の作業の後ろで待たされたりすると遅く感じられます。トレースはラボ計測なので、代表的なデバイスと、利用可能ならプライバシーに配慮したフィールド計測で修正を確認してください。
起動時の解析とタップ後のハンドラでは別の対策が必要です。
リファクタ前に繰り返し発生する style-write / layout-read のパターンを見つけます。
トレース、シナリオ、上位コストを作業項目に添付します。
重要なタイミングではコードを減らして出荷する
ルートと用途ごとにスクリプトの在庫を作ります。未使用のパッケージ、重複、終了した実験、終わった機能用のコードを削除します。続いてルート固有やまれに使われる機能を分割し、初期パスではなく必要時に読み込むようにします。動的読み込みは起動時の作業を減らせますが、ユーザーが機能を即時に必要とする場合は目に見える遅延を生むことがあります。
コンポーネントにフル機能のクライアントサイドフレームワークが本当に必要か、ユーティリティが既存の機能と重複していないか、静的 HTML に小さな拡張を加えるだけで十分ではないかを検討してください。遅延読み込みするモジュールのフォールバック状態をテストしてください。ページでは、任意の機能を適切に遅延させ、代わりに機能しないコントロールを表示しないようにすべきです。
どのルートでどのスクリプトを許容するか、理由を文書化します。
オプションのエディタ、地図、プレーヤー、レポートビューなどに検討します。
認証、アクセシビリティ、支払い、フォーム完了をテストし、コントロールに影響がある場合は資格のあるレビューを求めます。
ブラウザが応答できるように作業を分割する
小さな関数に名前を付けても、それらが同期的に実行されればブラウザの別タスクにはなりません。長いループの場合は作業をバッチ化し、ユーザーに即時表示される状態を更新してから続行前に一度割り込み（yield）を入れてください。これによりバッチ間でブラウザが入力やレンダリングを処理できます。
サポートされている場合は scheduler.yield() がメインスレッドに譲り、後で作業を継続できます。未対応ブラウザ用に機能検出とフォールバックを用意してください。すべての小操作後に常に yield するのは避けてください。オーバーヘッドが発生し、完了時間が長くなることがあります。境界は計測に基づいて選び、キャンセルを保持し、古い結果が新しい状態を置き換えないようにします。
視認できる受け入れや進捗を非表示のフォローアップより先に表示します。
アイテムごとではなく、計測で長時間になる前に yield します。
現在の web.dev のガイダンスは isInputPending() に基づく新しい戦略を推奨していません。
インターフェースではなく計算をワーカーに移す
Web Worker はメイン実行スレッドとは別のバックグラウンドスレッドでスクリプトを実行します。高負荷なパース、データ変換、検索インデックス化など、DOM に直接アクセスする必要がない重い計算に適しています。定義された入力を送り、定義された結果を返し、描画と可視状態の変更はメインスレッド上に残します。
ワーカーは万能ではありません。DOM を直接操作できず Window を使えず、一般的なメッセージ通信はデータをコピーします。ワーカーの生成、データ移動、エラー調整は小さな計算ではコストが上回ることがあります。対話全体を計測し、不要なワーカーは終了させ、ワーカーが失敗した場合のフォールバックを設計してください。
入力と出力が直列化（シリアライズ）できてテスト可能な計算から始めます。
古いフィルタ、ルート、または操作向けに作られた結果は破棄します。
通常のインターフェースを通じて意味のある進捗を伝えます。
サードパーティの JavaScript を本番環境の依存関係として管理する
分析、広告、実験、ソーシャル埋め込み、ビデオプレーヤー、サポートウィジェットは、リクエスト、JavaScript 評価、iframe、依存関係を追加します。ベンダのスクリプトは必要かもしれませんがアプリケーションチームの直接管理外にあり、パフォーマンス、プライバシー、セキュリティ、継続性に影響を与えます。目的、ルート、読み込み条件、承認者、同意の要否、削除の責任者を在庫化してください。
条件と契約が許す場合は、代表的なページをサードパーティ起点を含む場合と含めない場合で比較してください。パフォーマンスツールは高コストの評価、ペイロード、長時間タスクの帰属を明らかにできます。文書化された価値が計測されたコストを正当化する場合にのみ、軽量または遅延統合を維持します。オプション依存が遅いか存在しない場合は、コアコンテンツと主要なトランザクションが動くことを確認してください。
タグは必要なルートと条件でのみ読み込むようにします。
タグマネージャーの変更にはパフォーマンス、プライバシー、セキュリティ、ロールバックのレビューを含めます。
非重要な統合を無効にする方法を文書化しテストします。
応答性をリリースの安全装置にする
成果が出たトレースを、重要なジャーニー向けの小規模な回帰チェックに転用します。対象の操作、デバイスまたは CPU の制約、期待する応答、レビュー担当者を定義してください。これをバンドルおよびサードパーティのインベントリレビューと組み合わせ、新しいパッケージやタグがメインスレッドの作業を気付かないうちに再導入しないようにします。
Status Is UP はこれらの証拠を積極的な最適化と安全な是正に使いますが、ライブ可用性監視に代わるものではありません。ハイリスクの変更前にはロールバックを準備し、リリース後に重要フローを検証してください。結果はデバイス、ネットワーク、ブラウザ、コンテンツ、アカウント状態で変わるため、閾値は保証ではなくガードレールとして扱ってください。
共有ナビゲーション、チェックアウト、検索、または大規模バンドルについてはビフォーアフタートレースを求めます。
既知の良好な動作を復元する機能フラグ、タグ設定、またはデプロイバージョンを把握しておきます。
主要リリース、ベンダ変更、デバイス構成の変化後に再プロファイルします。