最適化する前に測定する：Paul Irishのパフォーマンスワークフロー

なぜ最適化から始めると時間を無駄にしがちか

パフォーマンス作業は、最初に修正を始めるとランダムに感じられます。ある日はファイルをミニファイし、次の日はキャッシュを調整し、また別の日にライブラリを外す。時には効果が出ますが、時には何も変わらず理由が分かりません。

最大のリスクは「間違ったもの」を最適化してしまうことです。ページが遅い原因がJavaScriptでメインスレッドが塞がっていることにあるなら、何時間も画像圧縮してもほとんど改善しません。あるいはユーザーが気づかない部分だけ速くして、本当の遅延が長いAPIコールや頻繁に再レイアウトするレイアウト、単一のブロッキングスクリプトにある場合もあります。

「体感」で判断することにも落とし穴があります。「速く感じる」はプラセボ（スピナーなど）や、違うネットワーク・デバイス・時間帯でのテストによる差かもしれません。「実際に速くなった」とは、同じ操作を同じ条件で行ったときに数値が改善したことを意味します。

多くの問題は単純な約束で解決します：最適化の前に測定して、それから判断する。パフォーマンスを測定の問題として扱えば、推測をやめて学習を始められます。

実践的なループはこうです：改善したい1つのユーザーアクションを選び、再現可能な条件でベースラインを記録し、説明できる1つの変更を加え、再測定して数値が改善した場合にのみその変更を採用する。

Paul Irishと「まず測る」習慣

Paul Irishはウェブパフォーマンス分野でよく知られた声の一人です。ブラウザツールやパフォーマンスガイダンスに関わる中で、彼は分かりやすい考えを普及させました：最初の仕事は何が遅いか推測することではなく、それを証明することだと。

その考え方はチームのダイナミクスを変えます。「画像がいつも問題だ」や「フレームワークのせいに違いない」といった習慣的な議論の代わりに、証拠から始められます。タイムラインや遅いクエリ、長時間タスクを指摘できれば、会話は責任追及から修正へと変わります。

「最適化前に測定する」は共通ルールを作るのでパフォーマンスの議論を冷ますことにも役立ちます：何を測るか合意し、「より良い」とは何か合意し、数値が動いたときだけ成果を祝う。

これは小さなサイトにも巨大なアプリにも効きます。単一のベースラインがマーケティングページでの無意味なマイクロ最適化を止められますし、大きなプロダクトでは一貫した計測がパフォーマンスを終わりのないtodoにするのを防ぎます。

これを現実にする簡単な方法は、パフォーマンスをバグレポートのように扱うことです：再現手順、見た指標、そして1つの変更とその結果。もし二人が意見を異にしたら、測定をやり直してデータに判断を委ねましょう。

パフォーマンスはまず計測（インストルメンテーション）の問題

パフォーマンスはまず計測の問題として扱い、ユーザーが実際にどのように体験しているかを観測する手段を追加しましょう。見えなければ、意見のやり取りに終始します。これが「まず測る」の本当の意味です。

計測は派手である必要はありません。いくつかのシグナルを一貫して同じ場所で集めるだけで、基本的な質問に答えられるようになります：

• 何が遅く感じるか？
• 時間はどこに使われているか？
• 変更は助けになったか？

通常は2種類のデータが欲しくなります。

ラボデータは制御されたセットアップで取得します：特定のラップトップやテストデバイス、安定したネットワークプロファイル、毎回同じ手順。再現性があるのでデバッグに最適です。

実ユーザーデータは実際のユーザーが経験するもので、異なるデバイス、場所、接続品質を含みます。実ユーザーデータは優先順位付けに優れており、単なる1回のテストではなく実際のユーザーにとって何が痛いかを示します。

専門家でなくても、ページ読み込みのマイルストーン（最初にコンテンツが表示されるなど）、長時間タスクとメインスレッドのブロッキング、遅いネットワークリクエスト、高コストなレンダリング作業（レイアウト、スタイル、ペイント）、サーバー応答時間を測れます。

これらのシグナルは典型的にはいくつかの場所にあります：ラボプロファイリングにはブラウザの開発者ツール、バックエンドのタイミングにはサーバーログやトレース、実ユーザーデータには分析やRUMダッシュボード。例えばチェックアウトが遅く感じるなら、DevToolsはブラウザが大きなカートUIをレンダリングして忙しいことを示す一方で、サーバーログはAPIが速いことを示すかもしれません。計測がなければバックエンドを最適化しても実際の問題は解決しません。

ステップ1：再現できるベースラインを設定する

最適化の前に測るには、信頼できる出発点が必要です。ベースラインとは、同じアクションを同じ方法で同じ条件下で測ったものです。

まずは「サイト全体」ではなく1つの現実的なユーザージャーニーを選びます。例えば「ホームページを開いて最初の商品グリッドまでスクロールする」や「ログインしてダッシュボードに到達する」など短く記述できるもの。範囲を狭くすることで数値は安定し、次の手順が明確になります。

次に、そのジャーニーに合う1〜3の指標を選びます。ページビューなら一般的にLCP（主要コンテンツが表示される速さ）とTTFB（サーバー応答の速さ）の組み合わせが多いです。チェックアウトのようなフローならステップ1完了までの時間と支払いAPIの応答時間を追う、など。指標を増やしすぎると恣意的に選びやすくなります。

テストのセットアップを誰でも再現できるように書き残してください。小さな違いが結果を大きく左右します：

• デバイスとブラウザ（バージョンを含む）
• ネットワーク（Wi‑Fiか4Gか、スロットリングの有無）
• キャッシュ状態（コールドかウォームか）
• 地域とテストデータ（リージョン、アカウント種別、カートサイズ）
• 実行回数（例えば5回実行して中央値を使う）

最後に、あなたのユーザーにとっての「十分」を定義します。例：「ミッドレンジのスマホで4G環境下でLCPを2.5秒以内にする」。Koder.aiを使うなら、テスト前にスナップショットを取っておくとベースラインが特定のバージョンに紐づくので便利です。

ステップ2：遅延を意図的に再現する

何かをプロファイルする前に、その問題を任意に再現できるようにします。再現できなければ結果は信用できません。

人々が感じていることから出発し、仮定から始めないでください。初回レンダリングが遅いのか？クリックして何も変わらないのか？フォーム送信後に長く待つのか？ユーザーが不満を感じる瞬間を選んでそこに集中します。

短い実行で遅延が実際に再現可能か確認します。可能な限り他を同じに保ちます：同じページ、同じデバイス、同じネットワーク。それからトリガーと正確に遅くなる瞬間を書き留めます（例：「Payをクリックした後、ボタンが1秒固まる」や「商品リスト表示時にスクロールがカクつく」）。

再現性を保つ簡単な方法は小さなスクリプトです：新しいタブでページを開き、遅い動作を行い、速度低下が始まる正確なポイントをメモし、もう一度繰り返して確認する。

ベースラインの録画は1〜2回で十分です。多数回取る必要はなく、「はい、遅延はここで起きる」という証拠があれば次に進みます。

ステップ3：プロファイルして主要なボトルネックを見つける

遅延を再現できたら、推測をやめてプロファイラ（多くの人はブラウザのPerformanceパネル）を開き、遅い操作を1回記録します。目的はすべての問題を見つけることではなく、時間がどこに使われているかを学ぶことです。

時間の大きな塊から読み始めましょう。小さなスパイクは実在することもありますが、目に見える遅延を説明することは稀です。

録画を読むときは時間をいくつかのバケットに分けるのが役立ちます：ネットワークとロード（リクエスト待ち）、メインスレッドでのスクリプト実行（長いJavaScriptタスク）、レンダリングとペイント（レイアウトやスタイル作業）、アイドル時間（他を待っている）、繰り返し作業（同じ高コスト処理が何度も起きている）など。

よくあるミスは、遅いサーバー応答とクライアントの重い処理を混同することです。タイムラインがリクエストの送受信中の長いギャップを示していればボトルネックはネットワークかバックエンドかもしれません。タイムラインに長いタスクが表示されればフロントエンドの問題です。

何も変更する前に、見た結果に基づく短くテスト可能な仮説を書いてください。例：「API応答後のJSONパースがメインスレッドを塞いでいる」。その一文が次のステップを決めます。

ステップ4：意図的に1つだけ変える

可能性のあるボトルネックを特定したら、全部直そうとする衝動に抵抗してください。原因と結果を結びつけるために変数は1つだけにします。

変更は小さく、元に戻しやすいものにします。大きな書き換えは結果を曖昧にします：速くなったとしても何が効いたか分からず、悪化したらロールバックが難しくなります。

良い「1つの変更」の例は具体的でテスト可能です。レンダリングをブロックするサードパーティスクリプトを1つ遅延させるか削除する、遅いページの1枚の巨大な画像を圧縮する、 expensiveなデータベースクエリに1つだけキャッシュを追加する、重いUIコンポーネントを分割して初期レンダリングの負荷を下げる、プロファイラで見つかったホットループの処理を1つ減らす、などです。

コードに手を付ける前に、何を変えたか、なぜそれを選んだか、どの指標がどう改善するはずかを書き残してください（例：「メインスレッド時間を減らす」や「DB時間を半分にする」）。

チームがスナップショットとロールバックをサポートするプラットフォーム（Koder.aiのような）を使っているなら、変更前にスナップショットを取っておくと「小さく元に戻せる」が実際に現実になります。