サンプルコードで身につける: 計測してから直す — 推測でコードをいじらない

解説で学んだ概念を、5つの具体例で確認します。素朴な例から実務寄りの例へと進みます。

1Lighthouseでスコアと改善候補を出す

改善作業の起点となるLighthouseの実行手順です。スコアそのものより「改善できる項目」の一覧が重要で、ここに並んだ指摘が直す候補になります。必ず本番ビルドに対して実行するのがポイントです。

# 1. 本番ビルドを作る(開発ビルドは最適化されておらず参考にならない)
ng build

# 2. ビルド結果をローカルで配信する
npx http-server dist/my-app/browser -p 8080

# 3. Chrome で http://localhost:8080 を開く
#    (シークレットウィンドウ推奨。拡張機能の影響を避けられる)

# 4. DevTools → Lighthouse タブ → カテゴリ「パフォーマンス」で分析
#
# 読むべきはスコアより下の2つ:
#   ・「改善できる項目」…… 直す候補と、見込める短縮時間
#   ・「診断」        …… 使用していない JavaScript、画像サイズなど

2Performanceタブで長いタスクを見つける

「どの操作のどの処理が遅いか」を特定するDevTools Performanceタブの使い方です。録画結果の帯グラフで赤い印が付いた長いタスクが調査対象になります。関数名まで降りていけるので、遅い箇所を推測ではなく事実で特定できます。

# ── DevTools Performance タブでの録画手順 ──

# 1. DevTools → Performance タブを開く
# 2. 左上の「記録」(●)を押す
# 3. 遅いと感じる操作を実際に行う(一覧の並べ替え、ページ遷移など)
# 4. 「停止」を押すと、時間の帯グラフが表示される
#
# 読み方:
#   ・上段の Main が JavaScript の実行。赤い印付きの長い帯が
#     「長いタスク」(50ms超)で、画面が固まる原因
#   ・長い帯をクリックすると、内訳(どの関数に何ms)が下に出る
#   ・CPUを「4x slowdown」にすると遅い端末を疑似体験できる
#
# ここで特定した箇所だけを直し、同じ操作を再録画して比べる

3開発サーバーで計測してはいけない理由

ng serveの開発ビルドと本番ビルドの違いを対比した例です。開発ビルドは最適化が切られているため、そのまま計測すると実際より悪い数字が出て、存在しない問題を追いかけることになります。計測前のチェックリストとして使えます。

# ── 遅い計測(やってはいけない) ──
ng serve
# http://localhost:4200 を Lighthouse にかける
# => 開発ビルドは圧縮なし・最適化なし・デバッグコード入り。
#    実際より悪いスコアが出て、直す必要のない箇所を疑ってしまう

# ── 正しい計測 ──
ng build
npx http-server dist/my-app/browser -p 8080
# http://localhost:8080 を Lighthouse にかける
# => 圧縮・ツリーシェイキング済みの、利用者が受け取る姿で測れる

# さらに条件を揃えるコツ:
#   ・シークレットウィンドウで開く(拡張機能の影響を排除)
#   ・計測は3回ほど実行し、ばらつきを見てから判断する

4performance.now で特定の処理を測る

怪しい処理をピンポイントで測る最小の方法です。開始と終了で performance.now() の差を取るだけで、その処理の所要時間がミリ秒で分かります。修正の前後で同じ場所を測れば、効果を数字で比較できます。

// 「この関数が遅いのでは?」と思ったら、まず測って確かめる
export function filterProducts(products: Product[], keyword: string) {
  const start = performance.now(); // 開始時刻を記録

  const result = products.filter((p) => p.name.includes(keyword));

  const elapsed = performance.now() - start;
  console.log(`filterProducts: ${elapsed.toFixed(1)}ms`);
  // => 例: filterProducts: 0.3ms
  //    0.3ms なら犯人はここではない。別の場所を測りに行く
  return result;
}

type Product = { id: number; name: string };

// 注意: 計測コードは原因特定のための仮のもの。
// 犯人が見つかったら console.log ごと削除してコミットする

5計測→修正→再計測の記録を残す

改善作業を記録しながら進める運用例です。改善前後の数字をセットで残すと、効果があったかを客観的に判断でき、チームへの報告もそのまま書けます。数字が変わらなければ、その変更を捨てる判断も堂々とできます。

# ── 改善作業の記録テンプレート(チケットやPR説明文に書く) ──
#
# 対象: 商品一覧ページの初期表示
#
# [計測(改善前)]  ※本番ビルド・シークレットウィンドウ・3回の中央値
#   Lighthouse Performance: 58
#   初期バンドル(Initial total): 890 kB
#
# [修正]
#   管理画面ルートを loadComponent で遅延読み込みに変更
#
# [再計測(改善後)]  ※改善前と同じ条件で測る
#   Lighthouse Performance: 71 (+13)
#   初期バンドル(Initial total): 610 kB (-280 kB)
#
# 条件を揃えない計測は比較にならない。
# 「同じビルド方法・同じウィンドウ・複数回」を毎回守る