pagespeed insightsを使ったサイト表示速度を改善する方法

pagespeed insightsを使ったサイト表示速度を改善する方法

PageSpeed Insightsは、Googleが提供する無料のWebサイト分析ツールで、あなたのサイトの表示速度を数値化し、具体的な改善策を提示してくれます。

このツールを活用すれば、画像の最適化、不要なJavaScriptの削除、キャッシュの設定など、実践的な改善ポイントが一目で分かります。

本記事では、PageSpeed Insightsの見方から、スコアを向上させるための具体的な改善手法まで、初心者にも分かりやすく解説していきます。

pagespeed insightsでページを計測をする

まずはPageSpeed Insightsを使って対象となるページの計測から始めましょう。

現状のサイト状況の把握から始めます。

計測の手順等を解説していきます。

※pagespeed insightsから詳しく知りたい方は『pagespeed insightsとは』のページをご覧ください。

計測方法の詳細手順

PageSpeed Insightsでの計測は非常にシンプルですが、正確なデータを取得するためのポイントがあります。

  1. PageSpeed Insightsの公式サイトにアクセスします。
  2. 分析したいページのURLを入力します。
  3. 「分析」ボタンをクリックし、数十秒待ちます。

結果が表示されたら、左上の「携帯電話（モバイル）」と「デスクトップ」のタブを切り替えて両方のスコアを確認します。

現在は「モバイルファーストインデックス」の観点から、モバイルのスコアを優先して改善することが推奨されます。

このページではでスマホのを選択した形で紹介していきます。

フィールドデータとラボデータの違いを把握しておきましょう

PSIには「実際のユーザーの環境で収集されたデータ（フィールドデータ）」と「シミュレーション環境で計測されたデータ（ラボデータ）」の2種類があります。

実際のユーザーの環境（Chrome UX Report）

画像赤枠の「実際のユーザーの環境で評価する」で出てくるデータがフィールドデータになります。

フィールドデータとは、Chromeユーザーエクスペリエンスレポート（CrUX）から収集される、実際のユーザーが体験したウェブページの読み込み速度データです。

  • デバイスやブラウザ環境
  • 回線速度や接続環境
  • 地理条件

などのユーザー環境に依存する条件も加わったデータとなります。

これがCore Web Vitalsの合否判定に使われる真のデータです。

「利用可能なデータがありません」と表示される場合は、アクセス数が少なくデータが蓄積されていない状態です。

パフォーマンスの問題を診断する（Lighthouse）

ラボデータとは、Googleの管理された環境下で人工的に計測されたウェブページのパフォーマンスデータです。

Lighthouseツールを使用し、固定されたネットワーク速度やデバイス設定（通常はモバイル環境をシミュレート）で測定されます。

実際のユーザーデータではなく、再現可能な条件下でのテスト結果のため、問題の特定や改善効果の検証に適しています。

パフォーマンススコア、改善提案、詳細な診断情報が含まれ、開発者が最適化作業を行う際の指針となります。

改善作業の効果を確認する際は、このラボデータの数値変化を指標にします。

どこの数値が悪いか把握し改善の優先度を決める

結果画面には多くの情報が表示されますが、以下の順序で確認することで効率的に問題点を特定できます。

おすすめは、パフォーマンスのインサイト項目・診断項目から着手していくことをお勧めします。

パフォーマンスのインサイト・診断を確認する

まずユーザービリティに大きく影響するパフォーマンス項目から着手していきましょう。

パフォーマンスの表示から下にスクロールすると下記の画像のようにインサイト項目や診断項目が出てきます。

改善の優先順位付け

改善項目（診断・改善できる項目）は、「レンダリングをブロックするリソースの除外」や「使用していないJavaScriptの削減」など多岐にわたります。

優先度は以下の基準で決定します。

  1. 赤色（▲）の項目
  2. Core Web Vitalsに直結する項目（LCP、CLS、INP）
  3. 削減時間や削減サイズが大きいものは優先度高め

特に削減時間や削減サイズが大きいものから着手していくと、数値も大きく改善しやすいものとなります。

pagespeed insightsの項目別の改善方法

インサイトや診断項目で出てくる項目別にそれぞれの改善方法を解説していきます。

特に数値の悪い項目など気になる指標がある場合は、FCP、LCP、TBT、CLSなど関連する項目別に絞り込むこともできます。（下記画像の赤枠部分）

レンダリングをブロックしているリクエスト

「レンダリングをブロックしているリクエスト」の項目の説明に下記が記載されています。

リクエストがページの最初のレンダリングをブロックしているため、LCP が遅れる可能性があります。これらのネットワークリクエストを遅らせるかインライン化すると、クリティカルパスから移動できます。

これは、主にHTMLの解析中にCSSやJavaScriptファーストビュー（最初に見える部分）の表示に不要なリソースが読み込みを妨げていることを意味します。

特に、上記画像の赤枠の削減時間を減らせることを目標としましょう。

黄色枠では各ファイルがどれだけ読み込みに時間がかかっているかがわかるので、時間が大きいものから着手していくとインパクトもでかいです。

青枠では対象のファイルが確認できますので、着手したいファイルをここで確認しましょう。

主にここではCSSやJavaScriptについて、「使用していない部分の削除」「優先度の低いファイルの読み込みを遅らせる」「ファイルを圧縮させる」作業で改善ができます。

方法は下記の見出しで紹介しているものと連動しますので、下記を読み進めてみてください。

使用していないJavaScriptの削減

「使用していないJavaScriptの削減」の項目には下記のような記載があります。

使用していない JavaScript を削除して、必要になるまでスクリプトの読み込みを遅らせると、ネットワークの通信量を減らすことができます。

ここでは使用していないJavaScriptを削除する作業と、使用しているJavaScriptの読み込みを遅らせるという作業が必要となります。

まず対象となるページでDevToolを開き赤枠のカバレッジを開きます。（カバレンジが出てこない場合は3点のところから探しましょう）

画像の黄色枠の箇所で使用されていないJavaScriptは赤く表示されます。

また青枠の対象のファイルをクリックすると、オレンジ枠のところにもファイル内で赤くなっている行が使用されてないことがわかります。

※タイプ列で「JS」と記載されているのがJavaScriptとなります。

対策：Javascriptが使用されていないものは削除かDOM直後に配置

上記で黄色枠にあるバーが全て赤くなっているファイルについて、サイトで使用されてないファイルの場合はソースから削除します。

表示画面で使用されてないだけで、別の箇所で使用されているといった場合は必要なコンテンツのDOMの直後に配置するようにしましょう。

この時のポイントとして、特にカルーセル、スライダー、アコーディオンなどのコンテンツ毎にJavascriptファイルを分けることを推奨します。

例えばカルーセルのJavascriptファイルを別に分けるなど。

こうすることで、必要な分だけの必要なタイミングでJavascriptを読み込むことができるので無駄な遅延が起きなくなります。

使用していないCSSの削減

「使用していない CSS の削減」の項目には下記のような記載があります。

スタイルシートから使用していないルールを削除して、スクロールせずに見える範囲のコンテンツで使用されていない CSS の読み込みを遅らせると、ネットワークの通信量を減らすことができます。

これもJavascriptと概念は同じで、使用していないファイルやソースを削除するか、読み込みに必要なCSS以外の読み込みを遅らせる作業になります。

対策：内部CSS化の実施と遅延読み込み

ここもJavascriptの削減と同様にDevToolの「カバレッジ」で使用されていないCSSを確認します。

内部CSS化について、まずはファーストビュー表示に必要な最小限のCSSを<style>タグ内に直接記載します。

残りのCSSファイルはrel="preload"で非同期読み込みさせます。

ウェブサイトはhead内を読み込んだ後にbodyを読み込むため、head内にファーストビュー表示に必要な最低限のCSSを記載することで、レンダリングブロックを防ぎます。

具体的なソース例は下記のようになります。

<head>
  <!-- 内部CSS化 -->
  <style>
    body { font-family: Arial; margin: 0; }
    .header { background: #333; height: 60px; }
  </style>
  
  <!-- 非同期CSS読み込み（head内） -->
  <link rel="preload" href="style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

参考記事：rel="preload"とは

参考記事：レンダリングブロックの改善策

CSSの最小化

「CSSの最小化」の項目には下記のような記載があります。

CSS ファイルを最小化すると、ネットワークペイロードのサイズを抑えることができます。

ここでは、CSSファイルを圧縮する作業になります。

※先に「使用していないCSSの削減」を対応してから最後に着手することをお勧めします。

対策としてはCSS圧縮ツールを活用しファイルを圧縮します。

圧縮できると「.min.css」といったファイル名となります。

圧縮することで、ファイルの容量が削減され、読み込みも早くなります。

JavaScriptの最小化

「JavaScriptの最小化」の項目には下記のような記載があります。

JavaScript ファイルを最小化すると、ペイロードサイズとスクリプトの解析時間を抑えることができます。

ここも、CSSの最小化と同様にファイルを圧縮する作業になります。

CSS圧縮時と同様にJavaScriptファイルを圧縮ツールを活用しファイルを圧縮すればOKです。

フォント表示

「フォント表示」の項目には下記のような記載があります。

テキストの表示を統一するため、font-display を swap または optional に設定することを検討してください。swap をさらに最適化して、フォント指標のオーバーライドでレイアウト シフトを軽減できます。

フォント表示に関しては、Webフォント読み込み中にテキストが非表示になる「FOIT（Flash of Invisible Text）」が発生し、ユーザーがコンテンツを読めない時間が発生することを指します。

対策：font-displayを設定する

自社でホスティングしているフォントの場合、font-displayプロパティが欠けているとブラウザはフォントの読み込みが完了するまでテキストを一切表示しません。

対策としてfont-display: swapという一行を追加するだけで問題が解決します。

このプロパティを設定すると、ブラウザは即座にフォールバックフォント（システムフォント）でテキストを表示し、Webフォントのダウンロードが完了した時点でスムーズに切り替えます。

下記のようにfont-displayを「swap」（推奨）で指定してあげることで解決します。

/* styles.css */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom-font.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap; /* 追加：すぐにフォールバックフォントを表示 */
}

googleフォントの場合は下記のようにswapのパラメーターを追加してあげることで対応できます。

<link href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet">

対策：フォント指標のオーバーライドを指定する

また、その際にフォント指標のオーバーライドを指定することも推奨されています。

フォント指標のオーバーライドとは、CSSの @font-face で使える特殊なプロパティを使って、代替フォントの寸法をカスタムWebフォントに近づける技術です。

これによってCLSの数値（レイアウトシフト）の数値を悪化させないための対策です。

下記のソース例を参考にフォントの寸法を調整しましょう。

@font-face {
  font-family: "fallback-inter";
  src: local("Arial");
  
  /* フォント指標をオーバーライド */
  ascent-override: 90.20%;
  descent-override: 22.48%;
  line-gap-override: 0.00%;
  size-adjust: 107.40%;
}

body {
  font-family: Inter, fallback-inter, Arial;
}

このようにArialの寸法をInterに近づけることで、フォント切り替え時のレイアウトのズレを大幅に軽減できます。

画像配信を改善する

「画像配信を改善する」の項目には下記のような記載があります。

画像のダウンロード時間を短縮すると、ページ読み込みの体感時間と LCP を改善できます。

ここでは、主に画像の容量が大きいことが問題とされています。

上記画像の赤枠で削減できる目安が表示されているので、数値が大きい改善余地が大きいことになります。

青枠では対象となる画像と、主に改善できる内容が記載されています。

主に下記のポイントを改善していくことで対策が可能です。

  • 画像サイズを最適なサイズに変更する
  • 画像を圧縮させる
  • 次世代フォーマットを使用する
  • レスポンシブ画像を使用する

具体的な手順はLCP改善の記事の「LCP改善手順②：画像サイズを縮小する」の見出しで詳しく解説しています。

参考記事：次世代フォーマットとは、レスポンシブ画像とは

効率的なキャッシュ保存期間を使用する

「効率的なキャッシュ保存期間を使用する」の項目には下記のような記載があります。

キャッシュの有効期間を長くすると、再訪問したユーザーへのページの読み込み速度を向上できます。

こちらは主に、画像・CSS・JavaScriptなどの静的リソースに対してブラウザキャッシュの有効期限が短い、または設定されていない問題です。

再訪問したユーザーが毎回同じファイルをダウンロードし直すため、ページの読み込みが遅くなります。

青枠にキャッシュ対象となっているファイル、黄色枠の「キャッシュのTTL」で現在のキャッシュされている時間がわかります。

コンテンツの性質に合わせてキャッシュを設定しましょう。

対策：キャッシュの推奨設定

基本はサーバーのコントロールパネルなどで設定をする形でいいかと思います。

下記はあくまで目安となりますが、リソース別のキャッシュ時間の目安となります。

是非参考にしてみてください。

リソースタイプ

推奨期間

Cache-Control設定

静的リソース（バージョン管理あり）
画像、CSS、JS、フォント

1年
31,536,000秒

public, max-age=31536000, immutable

HTML（動的ページ）
トップページ、商品ページ

即座に再検証

max-age=0, must-revalidate, public

中期更新コンテンツ
ニュース、ブログ記事

1日〜1週間
86,400〜604,800秒

public, max-age=86400

キャッシュ不可
ユーザー固有データ、API

キャッシュしない

no-store, no-cache, private

コントロールパネルよりも細かく設定したい場合は.htaccessファイルに設定する方法もあります。

あくまで参考ですが、下記のソースなども参考にご覧ください。

<IfModule mod_headers.c>
  # 静的リソース（画像、CSS、JS、フォント）- 1年間キャッシュ
  <FilesMatch "\.(jpg|jpeg|png|gif|webp|avif|svg|ico|css|js|woff|woff2|ttf|eot|otf)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>

  # HTML - 即座に再検証
  <FilesMatch "\.(html|htm)$">
    Header set Cache-Control "max-age=0, must-revalidate, public"
  </FilesMatch>

  # PDF、動画など - 1週間キャッシュ
  <FilesMatch "\.(pdf|mp4|webm)$">
    Header set Cache-Control "public, max-age=604800"
  </FilesMatch>
</IfModule>

# mod_expiresを使う方法（代替）
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpg "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType application/x-font-woff "access plus 1 year"
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

ネットワークの依存関係ツリー

「ネットワークの依存関係ツリー」はページ表示に必要な重要リソース（CSS/JS/フォント等）が“連鎖”して順番待ちになり、描画までの時間が伸びる問題です。

HTMLの読み込み後にCSSが見つかり、そのCSSからさらにフォントや追加CSS/JSが参照されると、子リクエストが親の完了を待つため遅延が積み上がります。

結果としてFCP/LCPが悪化します。

項目には下記のような記載があります。

チェーンの長さを縮小する、リソースのダウンロード サイズを抑える、不要なリソースのダウンロードを遅らせるなどしてページの読み込み速度を改善し、クリティカル リクエスト チェーンを回避してください。

pagespeed insightsでは画像の青枠ようにツリー上に表記されます。

例えば上記の画像であれば、赤枠のように特に階層が深い構造や、黄色枠のように容量が大きいものに注目しましょう。

対策：@importなどのCSSの連鎖を避ける

CSSファイルに@importがないか確認をします。

特にCSS → CSS → fontといったような連鎖がないか確認します。

下記のような@importがある場合は

/* style.css */
@import "parts.css";

1つのファイルに統合させるか、下記のようにHTMLで複数の<link rel="stylesheet">を使うと、ブラウザは見つけ次第ダウンロードを進めやすくなります（結果として依存関係ツリーが浅くなります）。

<link rel="stylesheet" href="/css/style.css">
<link rel="stylesheet" href="/css/parts.css">

ただし、増えすぎる場合はレンダリングブロックにも影響しますので、上記でも説明している「rel="preload"」などを使ってあげることをお勧めします。

また、JavaScriptファイルに関しては、上記で説明している「使用していないJavaScriptの削減」や「JavaScriptの最小化」の対策を合わせて進めておきましょう。

参考記事：レンダリングブロック

DOM サイズを最適化する

「DOM サイズを最適化する」は、ページ内のHTML要素（DOMノード）が多すぎる／入れ子が深すぎる／1要素の子要素が多すぎることで、HTML解析・スタイル計算・レイアウト計算が重くなり、描画や操作（スクロール・クリック）の反応が遅くなる問題です。

特に複雑なCSSやJS処理と組み合わさると負荷が増え、メモリ使用量も増えてパフォーマンスが悪化します。

下記のように説明されています。

DOM サイズが大きいと、スタイルの計算とレイアウトのリフローに時間がかかり、ページの応答性に影響する可能性があります。DOM サイズが大きいと、メモリ使用量も増加します。

上記画面の説明を簡単にします。

合計要素数＝ページ内のDOMノード（HTMLタグ等）の総数

DOMの深さ＝DOMツリーの 最大の入れ子の深さ

子の最大数＝ある 1つの親要素が直接抱える子要素の最大数

画像の赤枠部分がそれぞれの数となります。

特にDOMが増えてしまう要因としてよくあるのが下記となります。

  • 1ページに要素を詰め込みすぎ（長いLP、一覧を全部出す）
  • 不要なdivの多重ネスト（テーマ由来など）
  • リスト・カード・テーブルの行を大量にDOMとして描画（商品一覧/ログ/コメントなど）
  • JSで動的にノードを大量生成（カルーセル、無限スクロールの実装が雑）

対策：表示していないものをDOMから外す

画面に出ていない要素（下の方の一覧、折りたたみ、タブ未選択、無限スクロールの先、モーダルの中身等）を、最初からDOMに大量に置かないことで、合計要素数/子の最大数を直接減らし、スタイル計算・レイアウト計算の負荷を下げる打ち手です。

例）余りにも数の多い商品一覧や記事一覧

この場合はページを分割（次へなどのリンクで分ける）して初期表示の件数を減らすことで解決できます。

それ以外にも、仮想スクロールで見えてる範囲だけDOMを持つような方法もあります。

対策：不要なラッパー要素を削る

「不要なラッパー要素（divの入れ子）を削る」解決は、要するに 「見た目のためだけに増えた階層（wrapper）を減らし、DOMツリーを浅く・小さくする」ことです。

方法としてはDevToolsの要素を開き「深いdiv入れ子」「同じクラスのwrapperが連続」を探します。

特に<div><div><div>が続いたり、BEM/Utilityで“囲み”が増えているものなどが対象となります。

パターン①：「意味のないwrapper」を削って、CSSを親要素に寄せる

余白・中央寄せ・幅制限・背景・flex/gridなど“見た目目的だけ”の中間divを特定し、その役割のCSSをセクション（親）や実コンテンツ要素へ移してwrapper自体を削除する手法です。

まずDevToolsで入れ子が深い箇所を見つけ、各wrapperの役割を1行で言語化→CSSを移設→1段ずつ削除し、レイアウト崩れとJS依存がないか確認します。

下記のようなケースが多くあるので、こういった場合は削減できないか検討しましょう。

  • コンテナ多重：幅制限・中央寄せのために container > inner > wrap が重なる
  • 装飾の分割：背景/枠線/角丸/影/余白を別divにして積む
  • レイアウト専用ラップ：flex/grid・整列のためだけに row/col/inner を追加
  • カード/一覧の反復で爆増：1カードの入れ子が深い×件数が多い（Childrenも増えやすい）
  • 非表示UIを保持：タブ/アコーディオン/モーダルの中身を閉じてもDOMに残す
  • 自動生成HTMLの過剰：ページビルダー/テーマ/プラグイン由来の多重wrapper（row/column/widget等）

パターン②：「入れ子でしか実現してないレイアウト」を、CSSレイアウトで置き換える

入れ子の主因が「横並び・中央寄せ・高さ揃え」などレイアウト目的の場合、HTMLの“補助div”を減らし、flex/grid/gapなどのCSSに寄せることでDOMを単純化できます。

入れ子で実現していた「横並び・中央寄せ・高さ揃え」は、flex/grid/gapなどのCSSに置き換えてDOMを浅くします。

まずDevToolsでrow/col/inner等の“レイアウト専用wrapper”連鎖を見つけ、各wrapperの役割（横並び/余白/中央寄せ/高さ揃え）を1つに特定。

次に「並べたい要素の直親」にdisplay:flexまたはgridを付与し、余白はgapへ集約、幅制限は親へmax-width+margin:autoで寄せて中間divを1段ずつ削除します。

パターン③：フレームワーク/テンプレ由来のwrapperを減らす（React/Vue等）

コンポーネントが「とりあえず1つの親要素を返す」都合で増えたdivを減らし、DOMの合計要素数や深さを下げる手順です。

React/Vueなどで増えがちなwrapperは、コンポーネントが「1つの親要素を返す」都合で“囲むだけのdiv”が積み上がるのが原因です。

DevToolsで入れ子や反復（カード一覧など）を生むコンポーネントを特定し、ReactはFragment（<>...</>や<React.Fragment key=...>）で追加DOMを作らず複数要素を返して不要divを削減します。

React Fragments Vue3はFragments（複数ルート）を公式サポートするため、Vue2時代の最上位<div>を外しつつ、$attrsの付け先を明示します。

Vue Fragments 仕上げにPSI/LighthouseでNodes/Depth/Childrenの改善を確認します。

それぞれ実行後は、最後にPageSpeed InsightsでNodes/Depth/Childrenが下がったか再計測してみましょう。

サードパーティ

「サードパーティ」の問題については、自サイト以外（計測URLと異なるドメイン）から読み込む解析・広告・SNS埋め込み等のスクリプトが、ネットワーク転送やJS解析/実行でメインスレッドを長時間占有し、描画や操作可能になるまでを遅らせる問題のことを指します。

PageSpeed Insightsでは下記のように説明があります。

サードパーティのコードによって、読み込み速度が著しく低下する可能性があります。ページのコンテンツを優先させるには、サードパーティのコードの読み込みを減らして遅らせます。

画像の青枠にサードパーティの対象ファイル、赤枠がそれぞれのファイルサイズが表示されています。

対策：不要なタグは削除する

まず優先すべきは、使用していない不要なタグがないか？重複などで削除してもいいタグがないか？を確認しましょう。

特に広告タグや計測タグなど重複していたり、使用したいない場合はどんどん削除していきましょう。

また、そのページだけ必要なタグの場合は、全ページから外すなど細かくチェックしていくことをお勧めします。

削除してもいいタグがあれば削除していきます。

対策：読み込みタイミングを遅らせる（defer/async）

全てには当てはまりませんが、表示を遅らせても問題ないコンテンツやタグの場合は（defer/async）などの属性を使い、読み込みタイミングを遅らせることも検討してください。

async属性はHTMLのダウンロードが完了次第実行するという指示で、defer属性はHTML解析完了後に実行するという指示になります。

ソース例は下記を参考にしてみてください。

<!-- async: 並行ダウンロード、完了次第実行 -->
<script src="script.js" async></script>

<!-- defer: 並行ダウンロード、HTML解析完了後に実行 -->
<script src="script.js" defer></script>

対策：接続待ちを減らす（preconnectの活用）

preconnectは、外部ドメインのリソースを取りに行く前に、DNS解決→TCP接続→TLSハンドシェイク等の“接続準備”を先に済ませ、後続のCSS/フォント/JS取得を速める仕組みです。

初期描画に必要な外部配信（Google Fonts・計測タグ・CDN等）で効果が出やすい一方、接続を張りすぎるとCPUや回線・ソケットを消費し逆効果になるため、重要な数件（目安4）に絞ります。

設置の方法としてはheadに下記のようにpreconnectを挿入します。

<link rel="preconnect" href="https://example.com">

過大なネットワーク ペイロードの回避

※LCPなど

LCPリクエストの検出

LCPリクエストの検出は、ページのLCP要素が画像の場合に、その画像の取得リクエストをブラウザが初期HTMLからすぐ発見し、優先度高く開始できているかを評価する診断です。

ここの解説には下記のように書かれています。

LCP 画像を HTML からすぐに検出できるようにし、遅延読み込みを回避して、LCP を最適化します

LCPリクエストの検出では青枠で記載のある下記の3点に対応しましょう。

対象となるLCPは赤枠の部分で確認ができます。

  • 遅延読み込みが適用されていません
  • 「fetchpriority=high」が適用されました
  • リクエストは最初のドキュメントで検出可能です

について対策しているかどうかを確認しましょう。

遅延読み込みが適用されていません

これはLCPの対象となる画像が遅延読み込み「loading="lazy"」されていなければOKです。

誤って遅延読み込みしてしまうと、読み込みが遅れてしまうため、LCP対象の画像に関しては「loading="lazy"」を外しておきましょう。

「fetchpriority=”high”」が適用されました

LCP画像に「fetchpriority=”high”」が適用されているかの確認となります。

まだ追加されていない場合は、LCP画像に「fetchpriority=”high”」を追加してあげることで適用となります。

リクエストは最初のドキュメントで検出可能です

これは、初回HTMLに<img>タグを入れて、直に見えるようになっていればOKです。

ブラウザは初回HTMLを読みながら重要リソースを早期に発見できるようになります。

逆に「JSで後からDOMに追加」や「srcをdata-srcに隠す」などは発見が遅れるため、もしこのような設定をしている場合は改善しましょう。

LCPの内訳

「LCPの内訳」は、LCPを次の4区間に分けて「どこが詰まっているか」を示します。

どこの要素に時間がかかっているかを判断するためにチェックする項目となります。

各サブパートには、それに適した改善戦略があります。理想的なのは、LCP 時間のほとんどがリソースの読み込みに使われ、遅延に費やされないことです。

確認方法としては、画像赤枠部分をみます。

それぞれどの要素に時間がっかってるかを発見するために役立てる項目となります。

Time to First Byte（TTFB）

ブラウザがページ（HTML等）を要求してから、サーバーから最初のデータ1バイトが返ってくるまでの時間です。

DNS/接続/SSLといった通信確立、サーバー側の処理時間、バックエンドやDB待ち、CDN有無などの影響を受けます。

TTFBが大きいと後続の取得や描画が連鎖的に遅れ、体感速度を悪化させます。

リソース読み込みの遅延

CSS・JavaScript・フォント・画像などの「ダウンロードそのもの」ではなく、取得を“開始できるまで”に発生する待ち時間です。

レンダリングを止めるCSS/JS、優先度の低い設定、HTML解析の進み待ち、事前接続不足（preconnect等）などが原因になります。

開始が遅いほど重要要素の表示も後ろ倒しになりやすい指標です。

リソースの読み込み時間

リソースの取得を開始してから、ダウンロード完了するまでの所要時間です。

ファイルサイズ、圧縮（画像最適化/JS圧縮）、キャッシュ、サーバー転送速度、CDN、回線品質、同時接続数の制限などが支配的です。

ここが長いと、CSS適用やJS実行、画像表示が揃わず描画が遅延し、LCPなど主要指標にも影響します。

要素のレンダリングの遅延

必要なリソースが揃っていても、画面上の特定要素（主コンテンツやボタン等）が実際に“描ける状態になるまで”の遅れです。

JSの長時間実行、メインスレッドの混雑、レイアウト計算や再計算（リフロー）、複雑なDOM/CSS、サードパーティの処理などが原因になりがちです。

ダウンロード以外のCPU起因の遅さを捉えます。

強制リフロー

強制リフロー（Forced Reflow）は、JavaScriptがDOM要素のサイズや位置を取得する際に、ブラウザがレイアウト計算を強制的に実行させられる問題です。

通常、ブラウザは複数のDOM変更をまとめて処理しますが、offsetWidthやgetBoundingClientRect()などの幾何情報を参照すると、即座にレイアウト再計算が発生します。

これが繰り返されると「レイアウトスラッシング」となり、JavaScript実行が中断され、ページの動作が著しく遅延します。

「強制リフロー」の項目には下記のような記載があります。

強制リフローは、DOM の状態の変更によってスタイルが無効化された後に JavaScript が幾何学的プロパティ（offsetWidth など）をクエリしたときに発生します。これにより、パフォーマンスが低下する可能性があります。

確認方法として上記の画像を参考にしてもいいですが、DevToolsのパフォーマンスのinsight（オレンジ枠）の箇所で確認することもできます。

青い枠にある赤線はどこの部分で強制リフローが発生しているタイミングとなります。

対策：「read（計測）」と「write（変更）」を分離する（レイアウトスラッシング回避）

read（計測）とwrite（変更）を交互に行うと、次の計測のたびにブラウザがレイアウト再計算（強制リフロー）を挟み、処理が詰まってカクつきます。

改善は「計測を先にまとめて取得→結果を変数に保持→DOM更新を後でまとめて実行」の順に分離し、ループ内のread→write→readを避けます。

必要ならrequestAnimationFrameで1フレームに集約します。

対策：DOM操作回数を減らす（構造変更をまとめる）

DOM操作（要素の追加・削除・属性変更・style変更など）を細かく何度も行うと、その都度ブラウザがレイアウト計算（リフロー）や再描画を挟みやすく、処理時間が積み上がって表示がカクつきます。

改善は、変更をループで逐次反映せず、いったんまとめて組み立ててから一括でDOMに反映し、更新回数自体を減らすことです。

対策：変更対象のレイアウト影響を小さくする

ここでは変更がページ全体の再配置（Layout）に波及しないように設計することです。

width/height/top/leftなどレイアウトを直接変える更新はリフローを起こしやすく、変更範囲が広いほど計算が重くなります。

改善は、頻繁に動かす要素はtransform/opacity中心にし、レイアウト変更が必要でも影響する要素数・入れ子・複雑な配置を減らして、再計算の対象を局所化します。

対策：連続処理はスケジューリングする

連続処理（スクロール/リサイズ/入力など高頻度イベント）をそのまま毎回実行すると、1秒間に何十〜何百回もDOM計測や更新が走り、メインスレッドが詰まって描画遅延や強制リフローを招きます。改善は、処理を「次の描画タイミング」に寄せてまとめることです。具体的にはrequestAnimationFrameで1フレームに1回だけ更新し、さらに重い処理はthrottle/debounceで間引きます。スクロール系ではpassive指定も有効です。

対策後はpagespeed insightsで再度計測して確認を行いましょう。

レイアウトシフトの原因

ページ表示中に画像・広告・埋め込み・フォントなどのサイズが後から確定し、要素が押し下げ／押し上げされて画面がガクッと動く現象です。

読んでいた位置を見失ったり誤タップが起き、体験が悪化します。

レイアウト シフトは、ユーザーの操作なしで要素が移動する場合に発生します。レイアウト シフトの原因を調査してください。たとえば、ページの読み込み時に要素が追加、削除される、フォントが変更されるなどの原因が考えられます。

ここでは、原因となる要素が「レイアウトシフトの原因」として示されます。

レイアウトシフトが起きている原因はここで確認しましょう。

画像要素で width と height が明示的に指定されていない

画像要素にwidth/heightが明示されていないと、読み込み後に画像の表示サイズが確定してレイアウトが押し広げられ、CLS（表示のガタつき）が発生します。

結果としてユーザー体験が低下し、PSIのパフォーマンス評価も悪化します。

特にファーストビュー内の画像や遅延読込時に影響が大きいです。

画像要素で幅と高さを明示的に設定すると、レイアウト シフトを減らして、CLS を改善できます。

上記画像の赤枠で対象の画像やソースが確認できます。

対策は簡単で、上記の画像ソースにwidth/heightを指定してあげることで対応できます。

ソース例

<img src="/images/hero.jpg" width="1200" height="675">

優先順として下記の順番に対策をしてあげましょう。

  1. LCP候補（ヒーロー画像等）
  2. ファーストビュー内の画像
  3. 遅延読み込み画像（スクロール後でもCLSが出る場合あり）
  4. 背景画像やスライダー内画像

合成されていないアニメーションは使用しないでください

transform/opacity以外（top/left/width等）を動かすアニメは合成（コンポジタ）で処理できず、毎フレームLayout/Paintが走りメインスレッド負荷が増えます。

その結果、低速端末でカクつき（jank）が出たり、要素の移動がCLS悪化要因になり、操作感と指標が悪化します。

pagespeed insightsでは下記のように記載があります。

合成されていないアニメーションは動きが不自然になり、CLS が大きくなることがあります

pagespeed insightsの診断「合成されていないアニメーション…」に表示される要素（DOM）を確認し、どのCSSプロパティをアニメーションしているかを洗い出します。

対策：“LayoutやPaintを起こすプロパティ”をやめる（置き換え）

まずはtop/left/width/height/margin等、Layout/Paintを発生させるアニメ箇所を特定した後に、同じ見た目の動きをtransform: translate/scaleとopacityの変化に置換します。

必要ならwill-change: transform, opacityを短時間だけ付与→影・ぼかし等の重い効果は固定/簡略化→再度PSIで診断が解消したか確認。

よくNGになりやすい例（置き換え前 → 後）

  • top/left で移動 → transform: translate(...) で移動
  • width/height で伸縮 → transform: scale(...)（見た目の拡縮で代替できる場合）
  • margin/padding で押し出し → transform で移動（レイアウトを変えない）
  • box-shadow や重い filter の連続変化 → 可能なら表現を簡略化（静的にする/疑似要素で工夫）

「可能な限り opacity と transform に制限する」が基本方針です。

対策：CSS Transition/Keyframes を compositor 寄りに書き直す

CSS Transition/Keyframesをcompositor寄りにするとは、top/left/width等でレイアウト再計算・再描画を発生させず、transformとopacity中心に書き換えて合成処理だけで動かすことです。

これによりメインスレッド負荷やカクつきを抑え、PSIの指摘を減らします。

transition/keyframesで動かしている箇所を特定し、top/left/width/height/marginなどLayout/Paintを起こす指定があれば、移動はtransform: translate()、拡縮はtransform: scale()、表示切替はopacityに置換して書き直します。

必要に応じてwill-change: transform, opacityを短時間だけ付け、再計測で「合成されていない」が消えたか確認します。

対策：必要に応じてレイヤー化を事前に促す（やりすぎ注意）

will-change や transform: translateZ(0) などで事前に合成レイヤー化を促すと、アニメ対象がコンポジタ側で処理されやすくなり、スクロール中や負荷時のカクつきを減らせる場合があります。

一方でレイヤーを増やしすぎるとGPUメモリ消費が増え、逆に性能低下するため、動く要素だけ・必要な時間だけに限定します。

アニメーションさせる要素を特定し、まずDevToolsでその要素が合成レイヤーとして扱われているかを確認します。

カクつきが出る場合のみ、対象要素にwill-change: transform, opacity（またはtransform: translateZ(0)等）を付けて事前にレイヤー化を促し、アニメが終わったらクラスを外して指定も解除します。

常時付けっぱなしにするとレイヤー増加でGPUメモリを消費し逆効果になり得るため、必要最小限に留めます。

対策：代替不能なアニメは頻度・範囲を減らす

代替不能なアニメ（例：アコーディオンの高さ変化など、heightやwidth等のLayout/Paintが避けられない動き）は、毎フレーム再計算が走って負荷やカクつきの原因になるため、表現を維持したまま「回数」と「影響範囲」を最小化するのが方針です。

該当アニメを特定し、代替できない（height/widthなど）場合は発火回数を減らします（自動再生・スクロール連動・無限ループを停止/間引き）。

次に影響範囲を縮小するため対象要素数を減らし、アニメ時間・移動量を短くします。

重い影/ぼかし等は簡略化し、必要ならフェード（opacity）に寄せて負荷を抑え、対策を行いましょう。

メインスレッドでタスクが長時間実行されないようにしてください

PageSpeed Insightsで言う「メインスレッド」とは、画面描画・入力処理・JavaScript実行を担うブラウザの主作業場です。

ここで長時間タスクが走ると描画やクリック反応が止まり、INP悪化・体感遅延・スクロールのカクつきが起きます。

原因は重いJS、同期処理、過剰なDOM操作などです。

メインスレッドで長時間実行されているタスクを表示します。入力の遅延に最も影響しているタスクを特定する際に役立ちます。

上記の赤枠のところでメインスレッドのロングタスクの要因となるソースが確認できます。

詳しく見たい場合は、DevToolsのパフォーマンスの録画を実施した後に、メインの箇所で赤い三角マークがあるか確認します。

上記の画像のように赤い三角マークがあればロングタスクがあると判断できます。

ネットワークの欄と一緒に見ると下記のようにロングタスクではないが、レンダリングブロックになっているタイミングなどの詳細も確認できます。

対策：JavaScriptの実行量を減らす（最優先）

ここでは「使用していないJavaScriptの削減」で説明している内容と同様に不要なJavaScriptを削除と優先度の低いJavaScriptはDOM直後に配置するところから始めます。

それ以外にもコード分割（lazy load）で、初期表示に不要な機能（管理UI、重いエディタ、解析モジュール等）を画面表示後やユーザー操作後に読み込み、初回の解析・実行を減らします。

次に初期化処理を見直し、起動時に全機能を一括初期化せず、表示・クリック・スクロールなど「必要になったタイミング」で段階的に初期化へ変更し、メインスレッドの長時間占有を防ぎます。

対策：「長い1本」を「短い複数」に分割する（メインスレッド占有を避ける）

「長い1本」の処理（重いループ、巨大なJSON整形、連続DOM更新など）を、そのままメインスレッドで走らせると50ms超のLong Taskになり、描画や入力応答が止まります。

そこで処理を小さな単位に分け、各ステップの間にブラウザへ制御を返すようにします。

例えば配列処理は数百件ずつに分割し、requestAnimationFrameやsetTimeout(0)で次バッチを実行します。

これにより1回あたりの実行時間を短く保ち、スクロールやクリックの引っかかり（INP悪化）を防げます。

対策：重い処理をメインスレッド外へ逃がす

重い処理をメインスレッド外へ逃がすには、UI描画や入力処理と切り離し、計算・解析・変換などCPU負荷の高い作業をWeb Workerへ移します。

例えば大きなJSONのパース、集計、暗号化、画像処理、全文検索インデックス作成などはWorkerで実行し、メインスレッドはDOM更新とイベント応答に専念させます。

実装は「メイン→Workerへデータ送信→Workerで処理→結果だけ返す」という流れにし、返却後に最小限の描画更新を行います。

これによりLong Taskを減らし、クリックやスクロールの引っかかり（INP悪化）を抑えられます。

対策：DOM操作・レイアウト（Layout thrash）を減らす

DOM操作・レイアウト（Layout thrash）を減らすには、ブラウザのレイアウト計算を何度も発生させる「読み取り→書き込み→読み取り…」の往復を避けます。

具体的には、要素サイズ取得（offsetHeight等）などの読み取りを先にまとめ、style変更やclass付け替えなどの書き込みは後でまとめて行い、DOM更新回数を削減します。

さらに大量要素の追加はDocumentFragmentで一括挿入、アニメーションはtop/leftではなくtransform/opacity中心にし、不要な強制同期レイアウトを防ぎます。

結果として描画の詰まりやスクロールのカクつきが減り、メインスレッド負荷が下がります。

対策：サードパーティ（広告・タグ・計測）を整理する

サードパーティ（広告・タグ・計測）を整理するには、まず「本当に必要なタグだけ」に棚卸しし、不要・重複・効果不明のタグを削除します。

次に、広告やヒートマップ等の非必須スクリプトは初期表示後や同意取得後、ユーザー操作後に遅延読み込みして、メインスレッドの占有を避けます。

さらにasync/deferの適用、Tag Managerの発火条件（タイマー・スクロール等）の調整、読み込み先ドメインの接続最適化（preconnect）も検討します。

これによりPSIの「サードパーティコードの影響を軽減」やLong Task/TBTの改善につながります。

上記まで対策できたら、最後にPageSpeed Insightsで再度確認を行いましょう。

ビューポートをモバイル向けに最適化する

こちらはスマホ表示時にページがPC幅（例：980px）として扱われ、文字や画像が極小になったり、横スクロールが発生したりする問題です。

原因は<meta name="viewport">が未設定、またはwidth=device-widthやinitial-scale=1が不足していること。

結果として読みづらさ・操作性低下を招きます。

ビューポートがモバイル向けに最適化されていない場合、タップ操作が最大 300 ミリ秒遅延する可能性があります。

まずは、PageSpeed Insightsで対象URLを計測し、該当項目のエラー文言を確認しましょう。

（例：width または initial-scale を指定した <meta name="viewport"> がありません）など

対策：HTMLの<head>にviewportメタを1つだけ正しく設定

<head>にviewportメタを「1つだけ」正しく入れるのは、スマホでページ幅と拡大率を端末に合わせ、文字が小さすぎたり横スクロールが出たりする不具合を防ぐためです。

まずは全ページ共通のテンプレート（HTML/WordPressテーマ等）の<head>を開き、<meta name="viewport">が複数ないか検索します。

重複があれば削除して1つに統一してください。

逆に、不足している場合は<meta name="viewport" content="width=device-width, initial-scale=1">を追加（既存がある場合はこの形に修正）

反映後は、PageSpeed Insightsで再計測して改善を確認します。

対策：viewportの「重複」を排除（重要）

viewportの「重複」を排除するのは、スマホ表示の幅や拡大率の解釈が不安定になり、意図しないズーム・レイアウト崩れ・PSIの指摘につながるのを防ぐためです。

全ページ共通の<head>（テンプレート/テーマ）でname="viewport"を検索します。

複数ある場合は、採用したい設定を1つに決めて残し他は削除します。

残す1行は基本形<meta name="viewport" content="width=device-width, initial-scale=1">に統一してください。

JSやCMSプラグインが追加していないかも確認しましょう。

対策：モバイル表示崩れ（横スクロール等）も併発していればCSS側も点検

モバイルで横スクロールやはみ出しが起きる場合、viewport設定だけでなくCSSが「画面幅より大きい要素」を作っている可能性が高いです。

固定幅（例：width: 1200px）、大きすぎる画像、vwの使い方、余白込みの計算などが原因で、端末幅を超えてレイアウトが崩れます。

DevToolsのデバイスモードで崩れる幅を再現

はみ出している要素を特定（要素検証で横方向に飛び出すボックスを探す）③固定px幅はmax-width: 100%やwidth: 100%、flex/grid等に置換④画像はimg{max-width:100%; display:block;}等で親要素内に収める⑤必要に応じてメディアクエリでモバイル用レイアウトに調整し、再確認します。

ドキュメントリクエストのレイテンシ

ページ読み込みの最初のHTML（ドキュメント）取得に時間がかかり、他のCSS/JS/画像など後続リソースの読み込み開始が遅れる問題です。

主因はリダイレクト、サーバー応答遅延（TTFB悪化）、HTML転送量過多や未圧縮などで、初動が遅れて体感速度を下げます。

pagespeed insightsでは下記のように記載があります。

最初のネットワーク リクエストは最も重要です。リダイレクトを回避し、サーバー応答を高速に保ち、テキスト圧縮を有効にして、レイテンシを削減します。

まは下記のいずれかで原因があるかを確認します。

上記画像の緑のチェックマークがついてるものは問題ありません。

  1. リダイレクト（最初のHTML取得前に301/302が発生）
  2. サーバー応答遅延（TTFBが長い）
  3. テキスト圧縮なし（gzip/Brotli未使用で転送が重い）

赤いチェックが出た場合は下記の対策を検討しましょう。

対策：リダイレクトをなくす（最優先で効くことが多い）

リダイレクトは、最初のHTML取得（Document）で 301/302 により別URLへ転送され、余分な往復通信（DNS/TCP/TLS/HTTP）が増えてドキュメント取得開始が遅れる状態です。

対策は「最初から最終URLに到達させる」ことになります。

よくある項目として、http→https、www有無、末尾スラッシュ、言語/地域振り分け等の転送を洗い出し、リダイレクトチェーンを解消しておきます。

次に内部リンク・canonical・OGP・サイトマップ・広告URLを最終URLへ統一もしておきましょう。

可能ならサーバ設定で一段に集約し、不要な判定転送を避けます。

対策：サーバー応答（TTFB）を短縮する（バックエンド最適化）

TTFB（Time to First Byte）は、ブラウザが最初のHTML（Document）を要求してから最初の1バイトを受け取るまでの時間で、サーバー側処理やネットワーク遅延が長いとドキュメント取得開始が遅れ、後続のCSS/JS/画像読み込みも連鎖的に遅くなります。

Server-TimingやAPMでTTFB内訳（DB、SSR、外部API、認証）を計測しボトルネック特定します。

DBはN+1解消・インデックス・クエリ削減、外部APIはタイムアウト短縮/並列化/キャッシュを行います。

HTML生成は不要処理を削り、フルページ/フラグメントキャッシュを導入しましょう。

CDNでHTMLもキャッシュし、オリジン到達を減らします。

CPU/メモリ不足やコールドスタートはスケール・常駐化で解消、リージョンも最適化させます。

対策：HTMLの転送を軽くする（圧縮＋サイズ削減）

HTMLの転送が重い状態は、サーバー応答（TTFB）の後に「HTMLをダウンロードし切るまで」の時間が長くなり、初期描画や後続リソース取得開始を遅らせます。

対策としては、圧縮（gzip/Brotli等）を有効化して同じHTMLでも転送バイト数を減らすのと、HTMLサイズ削減（初期HTMLに埋め込む巨大JSON/不要なインラインJS・CSS・Base64画像・タグ過多などを減らし“送るコード”自体を小さくする）を行います。

PSI/DevToolsではAccept-EncodingとContent-Encoding、および転送量（転送サイズと実サイズの差）で効果確認します。

重複するJavaScript

重複するJavaScriptは、同じ処理や同等のコードが複数箇所に散在し、修正時に全箇所の追従が必要になる状態です。

結果としてバグ混入、保守コスト増、読みづらさ、ファイル肥大化、読み込み遅延、依存関係の衝突や挙動差が起き、品質と開発速度を落とします。

重複する大きい JavaScript モジュールをバンドルから削除すると、ネットワーク アクティビティで不必要に消費されるデータ量を減らすことができます。

対策として、重複コードをまず棚卸しして「完全一致／一部違い／目的が同じ」のどれかに分類し、影響の小さい箇所から優先度を付けます。

次に共通化の単位（関数・ユーティリティ・モジュール・コンポーネント等）を決め、処理の“正”を1か所に集約し、差分は引数やオプションで吸収します。

その後、呼び出し側を段階的に置換し、置換ごとにテスト・動作確認で回帰を防ぎます。最後にレビュー観点・規約・Lint等を整備し、再発を防止します。

以前のJavaScript

「以前のJavaScript」は、古いブラウザ互換のためのトランスパイルやポリフィルが同梱され、現行ブラウザでは不要なコードまで配信されている状態を指します。

結果としてJS転送量と解析・実行コストが増え、表示体験（LCP/FCP）を悪化させます。

ポリフィルと変換を使用すると、従来のブラウザで新しい JavaScript 機能を使用できるようになります。ただし、その機能の多くは最新ブラウザでは必要ありません。従来のブラウザをサポートする必要がある場合を除き、Baseline の機能をトランスパイルしないように JavaScript ビルドプロセスを変更することを検討してください。

上記画像の赤枠部分のファイルを確認しましょう。

改善策は、まずPSIが指摘している対象ファイル（例：/js/scroll-hint.js?ver=...）が「手書きのJS」なのか「Babel等で生成されたビルド成果物」なのかを確認し、どの工程で古いブラウザ互換コード（例：クラス変換や Object.assign のポリフィル）が混入しているかを特定するところから始めます。

次に、ビルドしている場合は browserslist と Babel（preset-env）やTypeScriptのターゲット設定を見直し、実際にサポートが必要なブラウザ範囲に合わせて“必要な変換だけ”が走るように調整します。

これにより、現行ブラウザで不要なトランスパイル（例：@babel/plugin-transform-classes 相当の変換）を減らし、配信するJavaScriptの量と解析コストを下げられます。

あわせて、Object.assign などのポリフィルは「常に同梱」ではなく、そもそもモダンターゲットなら同梱しない、レガシー対応が要るなら機能検出で必要時のみ読み込む、といった方針に切り替えます。

さらに確実性を上げるため、モダン向け（ESM）とレガシー向け（nomodule）で成果物を分け、現行ブラウザには軽量なモダン版だけを配信する二系統ビルドを採用します。

もし原因が自前コードではなくライブラリ同梱であれば、ESM版・modern buildの提供有無を確認して差し替え、依存の取り込み方も最小化します。

最後に、PSI/Lighthouseで再計測し、「以前のJavaScript」の推定削減サイズが下がっていること、あわせてLCP/FCPやTBTなどの体感指標が改善していることを確認して完了、という流れで実務的に進めます。

メインスレッド処理の最小化

メインスレッド処理の最小化とは、UI描画や入力処理を担うメインスレッドに重い処理（計算・I/O・大きなDOM操作など）が集中し、フリーズやカクつき、タップ遅延が起きる問題を減らすこと。

応答性（体感速度）と安定性が悪化し、離脱や評価低下につながります。

JavaScript の解析、コンパイル、実行にかかる時間を短縮することをご検討ください。JavaScript ペイロードのサイズを抑えるなどの方法があります。

まずはpagespeed insightsの赤枠部分でかかった時間が大きいカテゴリを把握しておきましょう。

DevToolを使ってさらに詳細を確認します。

パフォーマンスのところから録画ボタンを押して計測した後にメインを開きます。

ここのロングタスクになっている箇所をクリックし、下部にあるボトムアップ、呼び出しツリー、イベントログなどで大きいタスクを確認します。

JSの解析・コンパイルが重い場合

ブラウザがダウンロードしたJavaScriptを「文字列→構文解析→バイトコード/最適化→実行可能」に変換する前処理に時間を取られ、初期表示や操作応答が遅くなる問題です。

特に巨大なbundle、古い構文向けトランスパイル（不要なpolyfill含む）、依存ライブラリ過多、サードパーティタグが多いと悪化します。

JSの解析・コンパイルが重い場合の対策は、「ブラウザに最初に渡すJS量」と「初期にパースさせる範囲」を減らすことです。

まず不要な依存・未使用コードを削り、コード分割（route/画面単位のlazy load）で初期表示に不要なbundleを後回しにします。

次にモダン配信（ESM優先、不要polyfill削減）で古い変換コストを抑えます。

サードパーティは棚卸しし、同意後/表示後に遅延読み込み。最後にSource MapやDevToolsで再計測し、Parsing/Compilation比率が下がったか確認します。

それ以外の対策

「メインスレッドでタスクが長時間実行されないようにしてください」の見出しで説明した

  • 「JavaScriptの実行量を減らす（最優先）」
  • 「DOM操作・レイアウト（Layout thrash）を減らす」
  • 「サードパーティ（広告・タグ・計測）を整理する」
  • 「重い処理をメインスレッド外へ逃がす」

の項目と

「強制リフロー」の見出しで説明した

  • レイアウトスラッシング回避
  • DOM操作回数を減らす（構造変更をまとめる）
  • 変更対象のレイアウト影響を小さくする

の項目を修正しましょう。

カスタム速度の記録と計測

「カスタム速度の記録と計測」は、サイト固有の重要処理（例：検索結果表示、API応答、画面遷移）の所要時間を自前で計測・記録していない状態を示します。

標準指標（LCP等）だけでは遅い原因箇所を特定できず、改善が勘や推測になって効果検証も困難になります。

LCPなど計測できる指標以外に個別に速度を計測することもできます。

INPの内訳

INPの内訳は、ユーザー操作（タップ/クリック/キー入力）から画面が次に描画されるまでの遅延を「入力遅延」「処理時間」「表示遅延」に分解し、どこがボトルネックか特定する指標です。

長いJavaScript処理やメインスレッドの混雑で反応が遅れ、操作しても画面が変わらず“固まった”体験になります。

最も長いサブパートから調査を開始します。遅延を最小限に抑えることができます。処理期間を削減するには、メインスレッドのコスト（通常は JS）を最適化します。

Input delay（入力遅延）、Processing duration（処理時間）、 Source Presentation delay（表示遅延）の項目に分けて原因を確認することができます。

原因確認をするためにチェックできる項目となります。

pagespeed insightsの表示速度改善する方法まとめ

PageSpeed Insights（PageSpeed Insights）で表示速度を改善するコツは、「点数を追う」より「体験（Core Web Vitals）を分解して潰す」ことです。

まずはフィールドデータ（実ユーザー）とラボデータ（計測環境）を見分け、LCP/INP/CLS/TTFBのどれが足を引っ張っているか特定します。

改善は王道からで、画像は次世代形式・適正サイズ・優先読み込み、CSS/JSは最小化と遅延読込、不要コード削減。

INPは“入力遅延/処理/描画”のどこが重いかを見て、長いタスクを分割しメインスレッドを空けるのが近道です。

CLSはサイズ確保とレイアウト変化の抑制。小さく直して再計測、を回せば確実に前進します。

これから一緒に積み上げていきましょう。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る