Handism's Tech Blog
学習ガイド一覧へ戻る

WebパフォーマンスとCore Web Vitals

ブラウザが画面を描画する仕組み（レンダリングパイプライン）と、UX向上のための重要指標である Core Web Vitals の最適化アプローチを図解で学びます。

学習をスタートする

ロードマップ

1

レンダリングパイプラインとCore Web Vitals

Webサイトの表示速度や操作時の応答性は、ユーザーの離脱率や検索エンジンの評価（SEO）に決定的な影響を与えます。 パフォーマンスを最適化するには、ブラウザが裏側でどのようにページを描画しているか（レンダリングパイプライン）を理解することが近道です。 第1章では、ブラウザの描画プロセスと、Googleが提唱するユーザー体験の重要指標 Core Web Vitals（コア・ウェブ・バイタル） の関係を図解します。 1. ブラウザのレンダリングパイプライン（図解） ブラウザがサーバーからHTML、CSS、JavaScriptを受け取り、画面にピクセルとして描画するまでのステップです。 1. DOM / CSSOMの構築: HTMLを解析してドキュメントツリー（DOM）を作り、CSSを解析してスタイルツリー（CSSOM）を作ります。 2. Render Treeの構築: 画面上に表示される要素とスタイルを結合した「レンダーツリー」を作ります（display: none の要素は除外されます）。 3. Layout (レイアウト/リフロー): 各要素が画面のどの位置にどのサイズで配置されるかを計算します。 4. Paint (ペイント): 要素の背景色、テキスト、境界線などのピクセルデータを塗る処理（ラスタライズ）を行います。 5. Composite (コンポジット/レイヤー合成): 要素をレイヤーに分け、GPUを使って重ね合わせて最終的な画面を描画します。 2. Core Web Vitals の3大重要指標 Googleがユーザー体験（UX）を評価するために定めた、特に重要な3つのパフォーマンス指標です。 1. LCP (Largest Contentful Paint) - 最大コンテンツの描画時間 * 意味: ページ内で最も大きいコンテンツ（ヒーロー画像やメインの見出しなど）が表示されるまでの時間。 * 目安: 2.5秒以下 が「良好 (Good)」。 * 改善アプローチ: 画像の最適化、サーバーの応答時間（TTFB）の短縮、レンダリングをブロックするCSS/JSの削減。 2. INP (Interaction to Next Paint) - 次の描画までの応答性 * 意味: ユーザーがクリックやキー入力をした際、ブラウザが次の画面（描画フレーム）を更新するまでの遅延時間。 * 目安: 200ミリ秒以下 が「良好 (Good)」。 * 改善アプローチ: JavaScriptの重い処理の最適化（メインスレッドの占有時間を減らす）、requestIdleCallback の活用、不要なスクリプトの削減。 3. CLS (Cumulative Layout Shift) - 累積レイアウトシフト * 意味: 読み込みの途中で、画像や広告が遅れて表示されることで画面のレイアウトがカクッとズレる視覚的な不安定さ。 * 目安: 0.1以下 が「良好 (Good)」。 * 改善アプローチ: 画像や広告枠にあらかじめ width / height を指定しておく、コンテンツの動的挿入を避ける。 まとめ * ブラウザの描画は DOM/CSSOM構築 → Render Tree構築 → Layout → Paint → Composite というパイプラインを辿る。 * JavaScriptやCSSによるパイプラインの再実行（特に Layout の再計算）を減らすことが高速化に繋がる。 * LCP (表示速度)、INP (応答性)、CLS (視覚的安定性) を最適化することが、優れたUXとSEO評価の両立において重要である。 次の章では、LCPやCLSに最も影響を与える「画像の最適化」について、具体的な実装方法を交えて学びましょう！

2

画像最適化と表示速度向上

Webサイトの総ファイル容量のうち、大半を占めるのが「画像データ」です。画像を適切に最適化することは、表示速度（LCP）の向上や、レイアウトシフト（CLS）の防止において最も効果的な手段の1つです。 第2章では、モダンな画像形式の選定方法、CLSを防ぐコーディング、そして表示速度を高めるリソース読み込み制御のテクニックについて図解します。 1. モダンな画像フォーマットの選定 従来の JPEG や PNG と比較して、画質をほとんど落とさずにファイル容量を大幅に削減できる次世代の画像フォーマット（WebP、AVIF）の採用が推奨されます。 フォーマット 特徴 圧縮率（JPEG比） 透過・アニメーション 推奨用途 WebP 現在の標準的な次世代フォーマット。ほぼすべての主要ブラウザで対応。 約 30% 削減 対応 一般的な写真やイラスト AVIF WebPよりさらに圧縮率が高い新世代フォーマット。 約 50% 削減 対応 高解像度の写真やグラフィカルな画像 SVG ベクター形式。解像度に依存しない。 極めて軽量（コード） 対応 ロゴ、アイコン、単純なイラスト 2. CLS（レイアウトシフト）を防ぐ width と height 画像が読み込まれる前に、ブラウザはその画像が表示される領域の大きさを把握できません。そのため、画像が後から読み込まれた瞬間に周囲のコンテンツが押し下げられ、レイアウトシフト（CLS）が発生します。 これを防ぐには、HTMLの img タグに width と height 属性を必ず指定 します。 CSSの aspect-ratio との併用 HTMLに width と height を設定しておくと、ブラウザは自動的にアスペクト比を計算し、CSSでレスポンシブ対応（width: 100%; height: auto;）にしても、読み込み前の領域確保が維持されます。 3. リソース読み込みの優先度制御（図解） すべての画像を一度に読み込むと、ブラウザの通信帯域が圧迫され、ページの初期表示（LCP）が遅れてしまいます。表示位置に合わせて読み込みの優先度を適切に割り振る必要があります。 ファーストビュー（画面内）の画像：優先度を上げる ファーストビューにある画像（特にLCPの対象となるヒーロー画像）には、loading="lazy" を指定してはいけません。むしろ、最優先で読み込むようにブラウザに指示を出します。 スクロールしないと見えない画像：遅延読み込み（Lazy Loading） 画面外にある画像は、ユーザーがスクロールしてその領域に近づくまで読み込みを遅らせることで、無駄な通信とCPU消費をカットします。 まとめ * 画像ファイルは WebP や AVIF などの次世代フォーマットに変換して使用する。 * width と height を指定することで、ブラウザがアスペクト比を計算し、レイアウトシフト（CLS） を100%防ぐことができる。 * ファーストビューの重要画像には fetchpriority="high" を付与し、それ以外の画像は loading="lazy" で遅延読み込みさせることで、初期表示速度（LCP）を最大化できる。

3

Core Web Vitals の理解と改善手法

Webサイトの表示速度やユーザー体験（UX）を定量的に測定するため、Googleが提唱している重要指標のセットが Web Vitals（ウェブバイタル） です。本章では、その中でも特に重要な Core Web Vitals（コアウェブバイタル） の3つの指標の概念と、それぞれの具体的な改善アプローチについて解説します。 1. Core Web Vitals の3大指標 Core Web Vitals は、Webページの「読み込み速度」「インタラクティブ性（反応速度）」「視覚的安定性」を測定します。 指標 意味 良好(Good)の目安 主な測定内容 LCP (Largest Contentful Paint) 読み込みパフォーマンス 2.5秒以下 ページ内で最も大きいメイン要素（画像や見出し）が表示されるまでの時間 INP (Interaction to Next Paint) インタラクティブ性 200ミリ秒以下 ユーザーのクリックやキー入力などの操作に対して、画面に描画の変更が反映されるまでの遅延時間 (※FIDに代わる新指標) CLS (Cumulative Layout Shift) 視覚的安定性 0.1以下 読み込み中にコンテンツが突然ズレて動く「レイアウトシフト」の累積スコア 2. 各指標の発生原因と具体的な改善策 LCP (最大視覚コンテンツの表示時間) * 主な低下原因: サーバーの応答遅延、レンダリングをブロックする JavaScript/CSS、容量の大きな画像。 * 改善アプローチ: 1. 画像の最適化: メインビジュアル画像を次世代フォーマット（WebP/AVIF）へ変換し、適切なサイズで配信する。 2. fetchpriority="high" の付与: LCP対象となる画像タグに優先度高の設定を追加し、ブラウザに早期に読み込ませる。 3. サーバー応答時間の改善: SSR (Server-Side Rendering) のキャッシュ最適化や、CDN (Content Delivery Network) の活用。 INP (インタラクションから次の描画までの時間) * 主な低下原因: メインスレッドを長時間占有する（Long Task）重い JavaScript の実行。 * 改善アプローチ: 1. JavaScript のコード分割: dynamic import を使い、不要なJSを初期読み込みから除外する。 2. 処理の遅延実行: 重い処理は requestIdleCallback や setTimeout を使用してメインスレッドを解放し、ユーザー操作への応答を優先する。 CLS (レイアウトシフトの累積スコア) * 主な低下原因: サイズ（width / height）が指定されていない画像、動的に挿入される広告やウィジェット、Webフォントの読み込み遅延。 * 改善アプローチ: 1. 画像アスペクト比の確保: すべての画像要素に width と height 属性を明示的に指定するか、CSSで aspect-ratio を設定し、読み込み前に描画領域を確保する。 2. プレースホルダーの設置: 動的コンテンツが挿入される領域に、あらかじめスケルトンスクリーン（グレーの仮枠）を置いておく。 3. Next.js での Web Vitals の計測 Next.js (App Router) では、内蔵の useReportWebVitals フックを使用して、本番環境のリアルなユーザー環境における Web Vitals データを簡単にキャッチして解析ツールへ送信できます。 これを app/layout.tsx などに配置することで、Webサイト全体のUX品質を監視し続けることができます。 まとめ * LCP は最大のメインコンテンツが表示されるまでの時間（改善策：画像の優先読込、CDN活用）。 * INP は操作に対する応答の速さ（改善策：重いJavaScriptの分割・遅延実行）。 * CLS は画面のブレのなさ（改善策：画像への width/height/aspect-ratio 指定）。

4

JavaScriptバンドル最適化と配信

モダンなWebフロントエンド開発では、リッチなUIを実現するために多くのライブラリ（npmパッケージ）を導入しがちです。しかし、それに伴ってJavaScript（JS）のファイルサイズが膨れ上がると、ブラウザでのダウンロードと解析・実行に時間がかかり、ページ読み込み（LCP）やインタラクション性（INP）が著しく悪化します。 第4章では、不要なJSコードを削り、配信を最適化するための主要なアプローチを学びます。 1. Tree Shaking（デッドコード排除） Tree Shaking（ツリーシェイキング） とは、利用していない不要なコード（デッドコード）をビルド結果から自動で除外する技術です。 Tree Shakingを有効にする条件 Tree Shakingは、JavaScriptのモジュールシステムが ESModules (import / export) である必要があります。CommonJS（require / module.exports）は動的に読み込むことができるため、ビルドツールが「本当に使われていないか」を事前に静的解析できず、Tree Shakingが機能しません。 2. Code Splitting と Lazy Loading ユーザーが最初のページを開いた際、すべてのページのJSコードが詰まった巨大な単一ファイルをダウンロードするのは非効率です。これを解決するのが Code Splitting（コード分割） です。 必要になるまでそのコードをロードしない Lazy Loading（遅延読み込み） を組み合わせます。 実装例（動的インポート） Reactなどのコンポーネントや、特定の大きなヘルパーライブラリ（例: グラフ描画用の Chart.js など）は、動的インポート（Dynamic Import）を使って別ファイルに切り出します。 Reactでは React.lazy と Suspense を使用して、ページ（ルーター）単位で簡単にコードを分割できます。 3. バンドルサイズの可視化 最適化を行うための第一歩は、「どのライブラリがバンドルの大部分を占めているか」を可視化することです。 * Webpack Bundle Analyzer / Vite Bundle Visualizer * ビルドされた結果に含まれる全ファイルをモザイク状の面積グラフとしてWebブラウザ上で確認できます。 これらを用いて、例えば「日付操作のためだけに巨大な moment.js をバンドルしていたため、軽量な dayjs に置き換える」「lodash から全関数ではなく特定の関数だけをインポートする」といった具体的な軽量化の判断（リファクタリング）を下すことができます。

5

各種レンダリング戦略のパフォーマンス特性

Webアプリケーションのパフォーマンスは、「どのタイミングで、どこでHTMLを組み立ててブラウザに表示するか」 というレンダリング戦略に大きく依存します。それぞれの戦略には、表示速度、SEO（検索エンジン最適化）、開発コスト、データのリアルタイム性において異なるトレードオフが存在します。 第5章では、現代の主要な4つのレンダリング戦略（CSR, SSR, SSG, ISR）のパフォーマンス特性と選定基準について学びます。 1. 4つの主要なレンダリング戦略 CSR (Client-Side Rendering) 空のHTMLを受け取った後、ブラウザ上でJavaScriptを実行してDOMを組み立てて画面を描画します。 * メリット: ページ遷移がスムーズ（SPA）、サーバー側の負荷が極めて低い。 * デメリット: 初期表示（FCP/LCP）が遅い。JSの解析が終わるまで真っ白な画面が続く。 * 適したユースケース: 管理画面（ダッシュボード）、ログイン必須のマイページ。 SSR (Server-Side Rendering) ユーザーがアクセスした瞬間に、サーバー上でデータベースからデータを取得してHTMLを組み立て、完成したHTMLをブラウザに返します。 * メリット: 初期表示が速い。クローラーがHTMLを直接読み込めるためSEOに有利。 * デメリット: アクセスが集中するとサーバー（CPU）の負荷が高まる。TTFB（最初の1バイトを受け取るまでの時間）が延びる。 * 適したユースケース: リアルタイムな株価やユーザー毎のタイムライン表示が必要なサイト。 SSG (Static Site Generation) ビルド時にあらかじめ全ページのデータを収集し、静的なHTMLファイルをディスクに出力しておきます。アクセス時はCDN経由でファイルを高速返却するだけです。 * メリット: パフォーマンスが最高（LCPが極めて良好）。サーバー維持費が非常に安い。 * デメリット: データが変わるたびにサイト全体を再ビルドする必要がある。 * 適したユースケース: ブログ、製品紹介サイト、ドキュメントサイト。 ISR (Incremental Static Regeneration) SSGのように静的ページを即座に返しつつ、指定した有効期限（Revalidate期間）が過ぎたあとのリクエストをトリガーに、バックグラウンドで特定のページだけをサーバーサイドで静的再生成します。 * メリット: ビルド時間が長くならず、古いデータが表示され続ける問題も解決できる。 * デメリット: 有効期限直後のユーザーには一世代古いキャッシュが表示される（裏で再生成は走る）。 * 適したユースケース: ECサイトの製品一覧、ニュースメディア。 2. パフォーマンス特性とトレードオフ 各戦略のパフォーマンス指標（Core Web Vitalsなど）に対する影響は以下の通りです。 指標/特性 CSR SSR SSG ISR 初期表示速度 (LCP) ⚠️ 遅い (JSロード待ち) ◯ 速い 🚀 最速 (CDN配信) 🚀 最速 (CDN配信) 応答開始時間 (TTFB) 🚀 最速 (空HTML) ⚠️ 遅い (サーバー処理) 🚀 最速 (静的ファイル) 🚀 最速 (静的ファイル) SEOの強さ ⚠️ 弱い (一部クローラー非対応) 🚀 強い 🚀 強い 🚀 強い リアルタイム性 ◯ 高い 🚀 非常に高い ❌ 低い ◯ 中程度 サーバー負荷 🚀 極小 ⚠️ 高い 🚀 極小 ◯ 低い 一つのWebアプリにおいてどれか一つの戦略に絞る必要はありません。Next.jsなどのモダンフレームワークでは、ダッシュボードは CSR、静的な利用規約は SSG、頻繁に変わる商品詳細は ISR のように、ページ単位で最適なレンダリング戦略を選択・ブレンドする設計がベストプラクティスとされています。