6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tuanphanin株式会社TOMOSIA VIET NAM

[Frontend Performance - Part 20] フロントエンドパフォーマンス改善 完全ロードマップ総まとめ

6
Posted at

📝 注意
この記事はAIによる編集支援を受けています。

📚 目次

0. はじめに：「勘に頼った最適化」から「計測駆動型の改善プロセス」へ

こんな経験はないでしょうか？

  • 何時間もかけてコンポーネントを最適化したのに、ユーザーが本当に速くなったと感じているか分からない
  • 最新版をデプロイして「完璧だ！」と思ったら、ユーザーからは「遅い」と苦情が来る
  • パフォーマンスに関する記事をたくさん読んだけど、何を優先すればいいか明確なロードマップがない

もしあなたが「勘に頼った最適化」の段階にいるなら、この記事は次のような手助けをします。

プロジェクトの開始から本番運用まで、実測データに基づく再現性の高い最適化プロセスを構築する

これはフロントエンドパフォーマンスシリーズ全体の総括記事です。
これまでの記事を読んだ方は、ここで全体像を整理してみてください。
読んでいない方にとっては、自分の現在地を把握するためのガイドになります。

1. 振り返り：5つの基礎パートと8つの知識レベル

元のシリーズは5つの基礎パートで構成されていました。

パート テーマ 該当記事 主な内容
1 ブラウザレンダリング 1–3 パイプライン, リフロー/リペイント, CRP
2 JavaScriptランタイム 4–6 イベントループ, メインスレッド, Long Task
3 Reactパフォーマンス 7–9 再レンダリング, 状態の局所化, メモ化
4 配信最適化 10–12 コード分割, キャッシュ, CDN
5 デバッグと監視 13–15 DevTools, Lighthouse, RUM

これらの基礎パートから、現代のパフォーマンスエンジニアリングをカバーする8つの知識レベルへと拡張しました。

  1. ブラウザレンダリングとクリティカルレンダリングパス
  2. JavaScriptランタイム（イベントループ, Long Task, Web Worker）
  3. Reactレンダリング（再レンダリング, 状態の局所化, メモ化）
  4. 配信とネットワーク（キャッシュ, CDN, HTTP/3, コード分割）
  5. モダンレンダリングアーキテクチャ（SSR, Streaming, RSC, PPR, Hydration）
  6. データレイヤーのパフォーマンス（React Query, リクエスト調整, ページネーション）
  7. 大規模ボトルネック（メモリリーク, 仮想化, CSS, フォント, バンドル管理）
  8. 監視と回帰防止（RUM, CI予算, 自動プロファイリング）

これらのレベルの関係は、理解 → 最適化 → 計測 → 調整という継続的なループです。

2. 3つの柱となる知識の総まとめ

19の記事を経て、パフォーマンス知識は次の3つの柱にまとめられます。

2.1. 柱1：ブラウザレンダリングを理解する

概念 意味 UXへの影響
クリティカルレンダリングパス ブラウザが最初のピクセルを生成する一連のステップ FCP, LCP
リフロー ブラウザがレイアウトを再計算すること TBT, INP
リペイント レイアウト変更なしにピクセルを再描画すること リフローより軽い

実践的な応用：読み書きのバッチ処理, アニメーションにはtransform, 重要なCSSはインライン化。

2.2. 柱2：JavaScriptランタイム（React含む）の最適化

  • タスク分割（setTimeout, scheduler.yield() – ブラウザサポートに注意）
  • Web Worker：DOMを必要としないCPU負荷の高いタスクに使用
  • メモ化（React.memo, useMemo, useCallback）

scheduler.yield()に関する注意：このAPIは新しいため、Safariや一部の古いブラウザではまだ完全にサポートされていません。使用する場合はフォールバック（setTimeout）を用意するか、ブラウザサポートを確認してください。

Reactでの優先順位：

状態の局所化 > childrenパターン > コンポーネント分割 > メモ化

2.3. 柱3：配信とネットワークの最適化

手法 効果
コード分割 初期バンドルを50〜70％削減
HTTPキャッシュ 再読み込みを80〜100％削減
CDN + HTTP/3 TTFBを40〜70％削減

キャッシュ戦略：静的アセット → max-age=31536000, immutable; HTML → no-cache; API → stale-while-revalidate。

3. 実践的な最適化ロードマップ – 6ステップ

B1 – ベースライン計測：Lighthouse, Chrome DevTools Performanceパネル, React DevTools Profiler, RUM（web-vitals）
2026年のGood閾値：LCP < 2.5秒, INP < 200ms, CLS < 0.1, TTFB < 200ms, TBT < 300ms

B2 – ブラウザレンダリング最適化：画像/動画のサイズ指定, font-display: swap, アニメーションにはtransform, DOM読み書きのバッチ処理

B3 – JSランタイム最適化：Long Task（>50ms）の分割, Web Workerの使用, イベントハンドラ内でのレイアウトスラッシング回避

B4 – React最適化：状態の局所化 → childrenパターン → 分割 → メモ化

B5 – 配信最適化：ルートベースのコード分割, HTTPキャッシュ, HTTP/3, LCP画像のプリロード, WebP/AVIF

B6 – 検証と監視：web-vitals + RUMの統合, p75ベースのアラート, デバイス/地域によるセグメント化

4. モダンレンダリングアーキテクチャ：SSR, Streaming, RSC, PPR, Hydration

現代のReactアプリケーション（Next.js App Router, Remix）では、パフォーマンスはクライアントランタイムの最適化だけではありません。

4.1. SSRとStreaming SSR

  • 遠隔地のユーザーのFCP、LCPを改善。
  • React 18+のStreaming SSRはHTMLを部分的に送信し、体感パフォーマンスを向上。

4.2. React Server Components（RSC）

  • サーバーで実行されるコンポーネント。クライアントにJSを送信しない → バンドル削減とハイドレーションコスト低下。
  • インタラクションが必要な場合のみ"use client"を使用。

4.3. ハイドレーションとSelective Hydration

  • ハイドレーションはサーバー生成HTMLにイベントハンドラを付与。メインスレッドをブロックする可能性あり。
  • Selective Hydration（React 18）は各部分を独立してハイドレートし、インタラクション領域を優先。

4.4. Partial Prerendering（PPR） – 2026年のトレンド
Next.jsでは、静的シェルと動的コンテンツを組み合わせるPPR（Partial Prerendering）が注目されています。
ページの大部分は高速に静的配信し、動的領域はストリーミングすることで、TTFBとハイドレーションコストを削減できます。

4.5. Edge Rendering
エッジ（Vercel Edge, Cloudflare Workers）でのレンダリングはTTFBを大幅に削減。データベース負荷の大きくない動的コンテンツに適しています。

4.6. レンダリング戦略の選択

戦略 使用するケース
CSR 内部アプリ, SEO不要
SSR SEOと初期表示速度が必要
SSG 静的コンテンツ
ISR 静的と動的のバランス
Edge SSR ユーザーが世界中に分散、低TTFBを重視
RSC クライアントJSを極限まで減らしたい
PPR 静的シェル＋動的スロットのハイブリッドページ

5. データ・ネットワーク・リソースの最適化

5.1. データレイヤーのパフォーマンス

  • React Query / SWR：サーバー状態の管理、不要なフェッチを防止。
  • staleTimeとgcTimeの適切な設定：プロフィール（30分）, 記事（5分）, リアルタイム（0）。
  • 楽観的更新, リクエスト重複排除, カーソルベースページネーション。
  • 無限スクロールは仮想化と組み合わせる。

5.2. ネットワークウォーターフォールとリクエスト調整

  • 深いリクエストチェーンを避ける。
  • サードパーティオリジンにはpreconnect / dns-prefetchを使用。
  • ユーザーがリンクにホバーしたらルートデータをプリロード。

5.3. サードパーティスクリプト（GTM, アナリティクス, チャット, 広告）

  • 本番環境でのパフォーマンス低下の主要因。
  • 非クリティカルスクリプトは遅延読み込み、async/deferを使用。
  • 可能ならセルフホスト。
  • PerformanceObserverでサードパーティによるLong Taskを監視。

5.4. モダンな画像最適化

  • レスポンシブ画像：srcset, sizes, <picture>。
  • LCP画像にはloading="eager" + fetchpriority="high"。
  • Next.js：next/image + priority。

5.5. CPUスロットリングと低スペックデバイス

  • 常に**CPUスロットリング（4倍遅延）**とネットワークスロットリングでテスト。
  • RUMでデバイスタイプ別、特に“低スペックモバイル”を監視。

6. 大規模フロントエンドのボトルネック：メモリ, CSS, フォント, 仮想化, バンドル管理

6.1. メモリリークとDetached DOM

  • 原因：未削除のイベントリスナ, 未クリアのinterval, DOMを保持するクロージャ。
  • 発見：Chrome DevTools → Memory → Heap snapshot → “Detached DOM tree”を検索。
  • 修正：useEffectでのクリーンアップ, AbortControllerの使用。

6.2. CSSパフォーマンス（大規模）

  • セレクタの複雑さ：深すぎるセレクタ（.a .b .c .d）はスタイル再計算を増加させるので避ける。
  • ランタイムCSS-in-JS（styled-components, Emotion）は再レンダリング時にオーバーヘッドが発生する可能性。コンパイル時CSS-in-JS（Vanilla Extract, Panda CSS）やAtomic CSS（Tailwind）を検討。
  • 未使用CSS：PurgeCSSまたはDevToolsのCoverageタブを使用。
  • スタイル再計算コスト：Performanceパネル（紫色のタイムライン）で監視。

6.3. フォント最適化の詳細

  • font-display: swapはFOITを防ぐが、CLSを引き起こす可能性あり。
  • 重要なフォントのプリロード：<link rel="preload" as="font" href="/font.woff2" crossorigin>。
  • サブセットフォント：一部の文字セットのみ使用する場合。
  • 可変フォント：フォントファイル数を削減。
  • unicode-range：ブラウザが必要なグリフのみを読み込むようにする。
  • モバイル/低スペック向けにシステムフォントフォールバックを検討。

6.4. 仮想化（ウィンドウイング）

  • 長いリスト（>500項目）→ ビューポート内の項目のみレンダリング。
  • @tanstack/react-virtualまたはreact-windowを使用。

6.5. バンドル管理と依存関係監査

  • バンドル分析：vite-bundle-visualizer, webpack-bundle-analyzer。
  • 依存関係監査：moment.jsをdayjsに、lodashフルインポートをメソッド単位のインポートに置き換え。
  • CIでの予算設定：低スペックモバイル向けメインバンドルは200KB（圧縮後）未満が推奨。ただし実際の数値はドメイン依存（内部ダッシュボードは500KBでも可、eコマースは150KB未満が望ましい）。重要なのは予算を設定し、回帰を監視すること。

6.6. パフォーマンス回帰の防止

  • CIでの回帰チェック：Lighthouse CI, bundle diff。
  • PRパフォーマンス予算：バンドルサイズ変更を自動コメント。
  • 自動プロファイリング：定期的にWebPageTestを実行。

7. 2026年と未来：React Compiler, AI, WebAssembly, 体感パフォーマンス

7.1. React Compiler（React 19）
ビルド時に自動メモ化を行い、手動メモ化の必要性を削減。ただしアーキテクチャ最適化の代わりにはならない。「状態は正しい場所にあるか？」「contextは乱用されていないか？」という問いは依然として重要。

7.2. AIによるパフォーマンス最適化支援

  • プロップドリリングの発見、状態の局所化の提案。
  • コード分割の分割ポイントを提案。
  • バンドルを分析し、重い依存関係の代替案を提案。
  • 限界：ビジネスドメインを理解しておらず、アーキテクチャの決定は依然として人間が行う。

7.3. WebAssembly（Wasm）
すべてのアプリに必要なわけではないが、純粋な計算負荷の高いタスク（画像処理、動画、CAD、暗号化、AI推論）がある場合、WasmはJSより優れている。Web Workerやタスク分割では不十分な場合に検討する。

7.4. 体感パフォーマンス – 数字だけではないUX

ユーザーはミリ秒を計測しない。彼らが感じるのは：

  • 即時のフィードバック（楽観的UI, スケルトン）
  • 滑らかなアニメーション（60fps, カクつきなし）
  • 重要なコンテンツの早期表示（LCP, プログレッシブローディング）

LCPが2.2秒でもスクロール時にカクつくアプリは、LCPが2.8秒でも滑らかなアプリより遅いと評価される。常にメトリクスとUXテストを組み合わせること。

7.5. アクセシビリティ vs パフォーマンス – 知っておくべきトレードオフ

  • 過剰なスケルトンはスクリーンリーダーで混乱を招く（aria-labelまたはaria-hiddenを付けること）。
  • 強いアニメーション（パララックス、動き）は不快感を与える可能性あり；prefers-reduced-motionを尊重する。
  • 誤った遅延読み込み（例：ファーストビューのメインコンテンツを遅延させる）は支援技術のコンテキストを失わせる。
  • 無限スクロールに「もっと読み込む」ボタンがないと、キーボード/フォーカス管理が困難になる。

パフォーマンス最適化後は常にキーボード＋スクリーンリーダーでテストすること。

8. アーキテクトのための総合チェックリスト

設計フェーズ

  • 状態の分類：UI / Server / Client global
  • 状態の局所化を明確に
  • ドメインに応じたパフォーマンス予算（LCP, INP, CLS）の閾値を決定
  • ユーザーが世界中に分散している場合はCDNを選択
  • レンダリング戦略（CSR, SSR, SSG, ISR, Edge, RSC, PPR）を選択

開発フェーズ

  • ルートベースのコード分割
  • 30KBを超える重いコンポーネントはReact.lazy + Suspense
  • ビューポート内に表示されるコンポーネントの遅延読み込みは避ける
  • DOM読み書きのバッチ処理
  • 緊急でない更新にはuseTransition / useDeferredValue
  • 静的アセットのHTTPキャッシュ（max-age=31536000, immutable）
  • WebP/AVIF + srcset/sizes + LCP画像のプリロード
  • 500項目以上の長いリストは仮想化
  • React Query / SWRと適切なstaleTime
  • サードパーティスクリプトは遅延、async/deferを使用
  • フォント最適化：プリロード, サブセット, 可変フォント
  • 深すぎるCSSセレクタを避け、コンパイル時CSS-in-JSを検討

テスト・最適化フェーズ

  • Lighthouse/PageSpeed Insights（点数にこだわらず、問題発見として）
  • INPデバッグのためのフレームグラフ + Interactionsトラック
  • React DevTools Profiler
  • バンドルアナライザ + 依存関係監査
  • CDNのキャッシュヒット率 >90%
  • メモリリーク（ヒープスナップショット, Detached DOM）
  • ハイドレーションコスト（DevTools → Performance）
  • 低スペックデバイス向けCPUスロットリングテスト
  • キーボード＋スクリーンリーダーでのテスト

運用フェーズ

  • RUM（web-vitals + バックエンド）＋サンプリング
  • LCP/INP/CLSのp75ベースのアラート
  • デバイス、ブラウザ、地域、接続種別によるデータセグメント化
  • CrUX / Search ConsoleでCore Web Vitalsを監視
  • bfcache互換性の確認（unloadやno-storeを避ける）

9. おわりに：パフォーマンスは旅であり、ゴールではない

20記事の旅を通して、8つの知識レベルを巡りました。

  1. ブラウザレンダリング
  2. JavaScriptランタイム
  3. Reactレンダリング
  4. 配信とネットワーク
  5. モダンレンダリングアーキテクチャ（SSR, Streaming, RSC, PPR, Hydration）
  6. データレイヤー
  7. 大規模ボトルネック（メモリ, CSS, フォント, 仮想化, バンドル）
  8. 監視と回帰防止

最後のメッセージ：

パフォーマンス最適化とは、
ブラウザに不必要な処理をさせない仕組みを設計し、
実ユーザーのデータを継続的に観測しながら、
UX・アクセシビリティ・ビジネス要件のバランスを継続的に調整していくことです。

👉 シリーズ完結。 ここまでお付き合いいただきありがとうございました。

6
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?