105. 計測してから直す — 推測でコードをいじらない

パフォーマンス改善の第一歩は、コードを触ることではなく計測です。ChromeのLighthouseを実行すればスコアと改善候補の一覧が手に入り、DevToolsのPerformanceタブで操作を録画すれば、どの処理に時間がかかっているか(長いタスク)が帯グラフで見えます。まず「どこが遅いか」を数字で特定します。

実務の進め方は「計測→修正→再計測」のループです。計測で一番遅い箇所を見つけ、そこだけを直し、もう一度計測して効果を数字で確認する。この繰り返しがすべてで、直した気になって再計測を省くと、効果のない変更がコードに積もっていきます。改善前後の数字はメモやチケットに残しましょう。

最大の落とし穴は、計測せずに「ここが遅いはず」という推測でコードをいじることです。人間の予想は驚くほど外れ、効果ゼロの複雑化や、かえって遅くなる変更を生みます。また ng serve の開発ビルドは本番より遅いので、計測は必ず本番ビルドに対して行うのが鉄則です。

サンプルコード(フレームワーク環境が必要なため表示のみ)

# ── 計測→修正→再計測の基本ループ ──

# 1. 本番ビルドを作ってローカルで配信する
#    (ng serve の開発ビルドは遅いので計測に使わない)
ng build
npx http-server dist/my-app/browser -p 8080

# 2. Chrome で http://localhost:8080 を開き、
#    DevTools の Lighthouse タブで「パフォーマンス」を分析
#    => スコアと「改善できる項目」の一覧が出る

# 3. Performance タブで「記録」を押し、遅い操作を再現して停止
#    => 赤い印が付いた長いタスクが「どこが遅いか」の答え

# 4. 一番遅い箇所を1つだけ直す

# 5. もう一度 1〜3 を実行して、数字が良くなったか確認する
#    (良くなっていなければその変更は戻してよい)

サンプルコードで身につける(5本) →

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

公式ドキュメントで詳しく ↗