ページの表示速度が遅いと感じたら、まず全体像を押さえよう
なぜ「ページスピードが遅い」と致命的なのか
ページの表示が遅いと、離脱率の増加、滞在時間の減少、コンバージョン率の低下に直結します。さらに、検索順位にも影響する Core Web Vitals が存在するため、ビジネス指標に直結する重大な問題といえます。
特にモバイルでは「表示に3秒以上かかると約半数が離脱する」「たった1秒遅くなるだけでCVRが平均7%低下する」といったデータもあり、ECサイトやランディングページでは売上に直撃します。Google は Core Web Vitals をランキング要因としており、LCP・INP・CLS の指標が悪いと、コンテンツ自体が良くても検索流入で不利になる可能性があります。
ページスピードが遅くなる主な原因
ページスピード低下の代表的な原因は、次の4つです。
- 画像が重い
- JavaScript / CSS が多く、実行負荷が高い
- サーバー応答が遅い
- 外部スクリプトが表示をブロックしている
まずは、自サイトがこのどれに該当しているかを絞り込みます。多くのサイトでは、全体の転送量の7〜8割を画像が占めていたり、分析タグ・広告タグなどのサードパーティスクリプトが LCP や INP を悪化させているパターンが典型です。
PageSpeed Insights やブラウザの開発者ツールを使い、「どのリソースがどれくらい時間を使っているか」を可視化し、原因ごとに優先順位をつけて対処していくことが基本方針になります。
【第一チェック】画像が重すぎないか確認する
画像サイズ・形式を確認するポイント
まず、ファイルサイズが数百KB〜数MBの画像がないかを確認します。背景画像やアイキャッチ画像は特に要チェックです。表示サイズに対して大きすぎる画像はリサイズが必要です。
PC のフル幅表示であっても、横 2000px を超える画像が本当に必要なケースは多くありません。実際の表示幅に対しておよそ1.5倍程度を目安にリサイズし、サムネイルや一覧用画像は専用サイズを用意するとよいでしょう。
さらに、srcset や sizes 属性を使ってデバイスごとに最適なサイズを配信すると、モバイル回線でのデータ量削減と LCP 改善に直接つながります。
簡単にできる画像圧縮・WebP化の方法
画質を保ちながら圧縮するツール（ImageOptim、Squoosh など）や、ビルド時に自動変換するプラグインを利用し、可能であれば WebP 形式へ変換します。CMS を利用している場合は、プラグインで自動変換・自動配信を行えることも多いです。
JPEG / PNG を WebP に変えるだけで、30〜80% 程度までファイルサイズが小さくなるケースも珍しくありません。WordPress なら画像最適化系プラグイン、Shopify ならテーマやアプリ側の自動圧縮機能を活用し、「アップロードした瞬間に圧縮・変換される」仕組みを整えると、運用負荷を大きく下げられます。
画像点数が多いメディアサイトや EC サイトでは、まずこの画像最適化を徹底するだけで PageSpeed Insights のスコアが大きく改善するケースがよくあります。
Lazy Load はどこまで使うべきか
画面外の画像（オフスクリーン画像）は Lazy Load を使って問題ありませんが、ファーストビューの主要画像を遅延読み込みするのは避けるべきです。使いすぎると LCP やユーザー体験を悪化させます。
loading="lazy" を一律で付与するのではなく、「初期表示領域より下にある画像」や「サムネイルが大量に並ぶ一覧ページの下部画像」などに絞って適用します。逆に、メインビジュアルやファーストビュー直下の重要な画像には preload を設定し、優先的に読み込ませると LCP の改善に効果的です。
Lazy Load の目的は「帯域の節約」と「初期描画の軽量化」であり、ユーザーがすぐに目にする要素まで遅延させないことが重要です。
【第二チェック】JavaScriptとCSSで足を引っ張っていないか
読み込みをブロックしている JavaScript / CSS を見つける
ブラウザの開発者ツールを使い、ネットワークタブとパフォーマンスタブを確認します。長時間実行されているスクリプトや、レンダリングをブロックしている CSS を特定します。
ネットワークタブでは、「各スクリプトの読み込みに何ミリ秒かかっているか」「どのファイルが最初の描画を待たせているか」を確認します。パフォーマンスタブでは、JavaScript の実行時間やレイアウト・ペイントに使われている時間をチェックします。
合わせて、PageSpeed Insights の「レンダリングを妨げるリソースの除外」「未使用の JavaScript の削減」などの診断結果も参考にし、どのファイルを優先的に見直すべきか判断します。
defer・async・CSS の読み込み順で体感速度を上げる
スクリプトは可能な限り defer / async を指定し、クリティカル CSS だけを先に読み込み、残りは遅延ロードすることで初期表示を高速化できます。
特に UI と直接関係しない計測タグやチャットウィジェットなどは、defer や遅延ロード用のスクリプトを利用し、「初期表示後」に実行させる設計が有効です。
CSS については、ファーストビューで必要な最小限のスタイルのみをインライン化または先頭で読み込み、残りのスタイルを分割して遅延読み込みします（必要に応じてメディアクエリ付きで読み込む構成も有効です）。これにより LCP の改善が期待できます。
HTTP/2 環境であれば、CSS や JS を複数ファイルに分割しても同時並行で高速に配信しやすいため、この点も意識して設計するとよいでしょう。
使っていないライブラリ・プラグインを整理する
不要なライブラリやプラグインは削除します。特に外部ウィジェットや解析スクリプトはパフォーマンスへの影響が大きいため、定期的な見直しが必要です。
jQuery に加え、複数の UI ライブラリやアニメーションライブラリが重複して読み込まれていないか、1年以上利用していない計測タグや A/B テストツールが残っていないか、といった観点で棚卸しを行います。
WordPress や Shopify では、利便性を重視して追加したプラグインが、結果として大量の JS / CSS を読み込み、INP や LCP を悪化させているケースがよくあります。「プラグインを一時停止 → 動作確認」を定期的に行い、必要最小限の構成に保つ運用ルールを決めておくことで、長期的なパフォーマンス悪化を防ぎやすくなります。
【第三チェック】サーバーとネットワーク周りを見直す
サーバー応答速度（TTFB）が遅いときの見分け方
PageSpeed Insights やブラウザのネットワークタブで TTFB（Time To First Byte）を確認します。データベースの遅延や PHP の処理負荷が原因となっている場合は、サーバー側でのチューニングが必要です。
TTFB が 1 秒を大きく超えている場合は、アプリケーションの処理時間、データベースクエリ数、キャッシュの有無（OPcache、ページキャッシュなど）を疑うべきです。WordPress などの CMS では、サーバー側キャッシュや静的 HTML 化プラグインを導入することで、TTFB を数百ミリ秒程度まで改善できる場合があります。
インフラレベルでは、HTTP/2 や HTTP/3 への対応、より高速な Web サーバー（Nginx、LiteSpeed など）への移行も検討に値します。
ブラウザキャッシュ設定で「毎回全部読み込む」を防ぐ
静的ファイルに対しては、長めの Cache-Control や Expires を設定し、ファイル名にハッシュ値を付けて更新時のみ再取得させる方式が効果的です。
例えば、Cache-Control: max-age=31536000, immutable を付与したバージョン付きファイル（例：style.abcd1234.css）を配信すれば、ファイルを更新するまではブラウザキャッシュだけで高速に表示できます。これにより、リピーターやサイト内で複数ページを閲覧するユーザーに対して、毎回 CSS・JS・画像を取りに行く無駄を避けられます。
CDN を併用している場合は、オリジンサーバーと CDN の双方でキャッシュポリシーが整合していることも確認が必要です。
CDN を導入すると何が変わるのか（導入の判断基準）
CDN を導入すると、ユーザーに地理的に近いノードからコンテンツを配信できるため、レイテンシが低下します。グローバルユーザーが多いサイトや、大容量の静的ファイルが多いサイトでは導入効果が高くなります。
多くの CDN は HTTP/2 / HTTP/3 への対応だけでなく、画像の自動圧縮・WebP 変換、動的コンテンツのエッジキャッシュなど、パフォーマンス最適化機能を備えています。
国内中心でページ数も少ないサイトでは必須とは限りませんが、次のような条件に当てはまる場合は導入を検討する価値があります。
- 海外からのアクセスが多い
- 画像・動画・JavaScript が重く、転送量が大きい
- オリジンサーバーの負荷を下げたい
このようなケースでは、Cloudflare や AWS CloudFront などの CDN を利用することで、TTFB と LCP の両方をまとめて改善できる可能性があります。
【Core Web Vitals視点】どの指標がボトルネックかを知る
LCP：一番大きなコンテンツの表示が遅いときの対策
LCP（Largest Contentful Paint）の改善には、ファーストビュー画像の優先読み込み、サーバーの高速化、クリティカル CSS の抽出と最適化が有効です。LCP の目標値は 2.5 秒以内とされており、まずは LCP 要素（もっとも大きな画像やテキストブロック）が何かを特定し、その要素の読み込みフローを集中的にチューニングします。
例えば、ヒーロー画像が LCP 要素となっている場合は、
<link rel="preload">で優先読み込みする- 画像フォーマットを WebP / AVIF に変える
- 実サイズに合わせてリサイズし、無駄なピクセルを削減する
- CSS のブロッキングを減らし、描画開始を早める
といった対策が効果を発揮します。テキストブロックが LCP 要素であれば、Web フォント読み込みを最適化し、FOIT（文字がしばらく表示されない状態）を避ける設計も重要です。
INP：操作してから反応するまでが重いときの対策
INP（Interaction to Next Paint）は、クリックやタップ、キーボード入力などに対する反応速度を評価する指標です。目標は 200ms 以下とされており、JavaScript の実行負荷が大きなボトルネックになりがちです。
改善のポイントとしては、
- 長時間ブロックする重い処理を Web Worker などにオフロードする
- 不要なイベントリスナーやスクロールイベントの処理を削減する
- React / Vue などのフレームワークでは、不要な再レンダリングを抑える
- サードパーティスクリプト（タグマネージャー、チャット、広告など）の影響を計測し、遅延ロードや削除を検討する
特に SPA やリッチな UI を持つ管理画面・会員制サイトでは、INP が悪化しやすいため、パフォーマンスタブでユーザー操作時のフレーム落ちを重点的に確認します。
CLS：レイアウトシフトでイライラさせないための対策
CLS（Cumulative Layout Shift）は、ページ読み込み中にコンテンツがガタガタと動く現象（レイアウトシフト）の度合いを表します。CLS が悪いと、ユーザーがボタンを押そうとした瞬間に位置がズレるなど、ストレスの大きな体験につながります。
主な対策は次のとおりです。
- 画像・広告枠・埋め込みコンテンツなどにあらかじめ幅・高さを指定し、表示前からレイアウトを確保する
- Web フォントの読み込みでテキスト幅が変わる問題に対して、フォールバックフォントや
font-displayを適切に設定する - 上部に挿入されるバナーやモーダル（クッキーバナーなど）は、レイアウトを押し下げない実装にする
CLS はユーザー体験に直結するため、特にモバイル環境でのスクロール中に意図しないシフトが発生していないか、実機やエミュレータでの確認が重要です。
まとめ：計測と優先順位付けで「遅い」を着実に解消する
ページの表示速度は、ユーザー体験と検索流入のどちらにも直結する基礎体力のような要素です。なんとなく「遅い気がする」と感じた段階で放置せず、今回挙げたチェックポイントを順番に洗い出していくことで、原因をかなりのところまで切り分けられます。
まずは、画像のサイズ・形式・点数を見直し、必要に応じてリサイズ・圧縮・WebP 化と Lazy Load の整理から手を付けるのがおすすめです。そのうえで、JavaScript / CSS の読み込み順や遅延読み込み、不要なライブラリ・プラグインの削除といったフロントエンド側の整理を進めます。さらに、TTFB・キャッシュ設定・CDN などサーバーとネットワーク周りを確認すると、土台そのものの性能を底上げしやすくなります。
最終的には、Core Web Vitals（LCP・INP・CLS）を指標として、「どこがボトルネックになっているのか」を計測しながら対策を継続的に回していくことが重要です。一度きりのチューニングで終わらせず、サイトの更新や機能追加に合わせて定期的に見直すことで、長期的に安定したページスピードを維持できます。
