ホームページの
表示速度を改善する方法
ホームページが遅いと感じたときは、手当たり次第に設定を変えるのではなく、 どのページで、どの要素が、どの場面を遅くしているかを確認することが大切です。 本記事では、小規模事業者のホームページを想定し、画像、WordPressプラグイン、 外部サービス、キャッシュ、サーバーなどの代表的な原因と、 初心者でも進めやすい改善手順を解説します。
測定して切り分ける
トップページだけで判断せず、サービスページや記事、問い合わせページもモバイルで確認します。
先に減らす
ファーストビュー画像、スライダー、プラグイン、動画・地図など、負荷の大きい要素から見直します。
実際の操作も確認する
点数だけでなく、文字や画像の表示、ボタン操作、フォーム送信に不具合がないか確認します。
表示速度は点数だけを追わず 影響の大きい原因から改善する
100点を目標にするより、利用者が待たされる場所と操作しにくい場所を減らすことが大切です。
順番に直す
ホームページの表示速度は、画像容量、HTML・CSS・JavaScript、WordPressのテーマやプラグイン、 サーバーの応答、外部サービスの読み込みなど、複数の要素によって決まります。 そのため「高速化プラグインを入れれば解決する」とは限りません。
まずPageSpeed Insightsなどで、モバイルとパソコン、代表的な複数ページを測定します。 実際の利用者データが表示される場合はその状況を確認し、診断結果から改善候補を探します。 そのうえで、画像や不要な外部読み込みなど、効果が大きく安全に見直しやすい項目から進めます。
Googleも、Core Web Vitalsを含むページ体験を全体として改善することを案内しており、 SEOだけを理由に診断ツールの満点を追うことは推奨していません。 読み込みの速さだけでなく、モバイル表示、操作性、コンテンツの見やすさも合わせて確認しましょう。
改善前に現在の速度を測り 比較できる状態を残す
測定条件をそろえて記録しておくと、変更が本当に効果を出したか判断しやすくなります。
PageSpeed Insightsで利用可能な場合は、実際のChrome利用者から集計されたデータを確認できます。 端末や通信環境が異なる利用者の体験を把握するために役立ちます。
データ量が少ないサイトや新しいページでは、URL単位の実測データが表示されない場合があります。Lighthouseによるラボデータは、制御された条件でページを読み込み、 大きな画像、不要なJavaScript、キャッシュなどの改善候補を表示します。
1回の点数は変動するため、同じページ・同じ端末区分で複数回確認します。スマートフォンでページを開き、最初の画像や文字が出るまでの時間、 メニュー、予約ボタン、フォームなどの反応を実際に確認します。
管理者としてログイン中の表示や高速な社内Wi-Fiだけで判断しないようにします。ホームページが遅くなる原因を 4つの領域に分けて確認する
原因は1つとは限りません。負荷の大きい要素と、全ページに共通する処理を優先して探します。
高解像度の写真をそのまま掲載したり、ファーストビューで大きな画像やスライダーを複数読み込んだりすると、 最初の表示に時間がかかりやすくなります。
同じ機能の重複、使っていないプラグイン、複雑なアニメーションなどは、 通信量だけでなく端末側の処理時間も増やす可能性があります。
サーバーがページ生成に時間を要する場合や、画像・CSS・JavaScriptが毎回再取得される状態では、 ページを開くたびに待ち時間が発生しやすくなります。
地図、動画、SNS投稿、チャット、広告、アクセス解析、外部フォントなどは、 複数の外部サーバーへの接続と追加処理を発生させます。
多機能なテーマ、ページビルダー、複数のスライダーやポップアップなどが重なると、 表示に必要なCSSやスクリプトが増えることがあります。
古い機能、不要なタグ、重複した計測コード、使用していない画像やCSSなどが残り、 サイト全体の負荷を増やしている場合があります。
画像は表示場所に合うサイズへ整え 読み込み順も見直す
画像はページ容量の大部分を占めやすく、改善効果を得やすい項目です。
幅600px程度で表示する画像に、数千pxの元写真をそのまま使わないようにします。 PCとスマートフォンで必要な大きさを考え、WordPressの生成サイズやレスポンシブ画像を活用します。
写真や画像を書き出す際に圧縮し、用途に応じてJPEG、WebP、AVIF、PNG、SVGなどを選びます。 新しい形式へ変換するだけでなく、見た目と対応環境も確認します。
ページ下部にある画像は遅延読み込みを使うことで、最初に必要な通信を減らせます。 WordPressやブラウザの標準機能で対応している場合は、重複する遅延処理を避けます。
ファーストビューのメイン画像やLCP対象となる画像まで遅延読み込みすると、 かえって表示が遅くなることがあります。重要画像はHTMLから早く発見できる状態にします。
画像の表示領域をあらかじめ確保すると、読み込み後に文章やボタンが大きく移動する現象を防ぎやすくなります。 画像比率を保ったままレスポンシブ表示を確認します。
プラグインと外部機能は 数ではなく負荷と必要性で判断する
少数でも重い機能はあり、多数でも影響が小さい場合があります。実際の読み込み内容を確認します。
使っていないプラグインや、キャッシュ・SEO・画像圧縮など同じ役割の機能が重複していないか確認します。 停止後の表示と管理画面を確認してから削除します。
診断ツールや検証環境を使い、特定のプラグインやスクリプトを停止したときに速度が変わるか確認します。 本番サイトで突然停止しないようにします。
YouTube動画やGoogleマップなど、最初の画面に不要な埋め込みは、サムネイル表示や遅延読み込みを検討します。 ただし操作性を損なわない形にします。
アクセス解析、広告、ヒートマップ、チャットなどのコードが重複していないか確認します。 利用目的と管理者が分からないタグは、削除前に関係者へ確認します。
読み込み時の演出、背景動画、追従要素、スライダーを増やしすぎると、 端末側の処理や操作の反応へ影響する場合があります。
古いプラグインやテーマは、性能だけでなくセキュリティや互換性の問題も抱える可能性があります。 バックアップ後に更新し、主要機能を確認します。
画像を直しても遅い場合は 配信環境と共通資源を確認する
全ページが遅い、初回応答が遅い、再訪時にも同じ資源を取得している場合は配信側も確認します。
安全性と効果を確認しながら 1項目ずつ改善する
一度に多くの設定を変更すると、改善した原因や不具合の原因が分からなくなります。
トップ、主要サービス、記事、問い合わせなどを測り、数値と診断項目を記録します。
ファイルとデータベースを保存し、不具合時に戻せる状態を作ります。 可能であればステージング環境で先に試します。
ファーストビューとアクセスの多いページから、寸法、圧縮、形式、遅延読み込みを確認します。
役割が重複する機能、使用していないタグ、重い埋め込みを1つずつ見直します。
全ページに共通する遅さや応答時間を確認し、利用環境に合う設定を選びます。
数値の変化に加え、画像、メニュー、フォーム、予約、決済など主要機能を確認します。
画像追加、プラグイン更新、タグ導入などで速度は変化します。変更後に確認する運用ルールを作ります。
指標・画像・プラグインを 原因別に詳しく確認する
診断結果に合わせて、該当する項目から詳しい改善方法を確認しましょう。
原因に合う関連記事を読む
- LCP・INP・CLSの意味と目安
- PageSpeed Insightsの結果の見方
- 画像の容量と表示寸法の整理
- alt属性と画像SEOの基本
- 遅延読み込みと重要画像の扱い
- プラグインの機能重複の確認
- 不要な外部処理の見直し
- 改善後の再測定と継続確認
※表示速度やCore Web Vitalsの改善によって、検索順位、アクセス数、問い合わせ件数が保証されるものではありません。 コンテンツの品質、検索意図、競合状況、サイト全体の使いやすさも合わせて改善する必要があります。
Core Web Vitalsの基本を見る →安全に改善しよう
表示速度は、複数の小さな負荷が重なって低下することがあります。 代表ページを測定し、画像、プラグイン、外部機能、配信環境の順に確認して、 変更後の数値と操作性を比較しましょう。
本記事は、2026年7月時点で公開されているGoogle検索セントラル、Google for Developers、 Chrome for Developers、web.devの公式情報を参考に作成しています。 指標、ツール、ブラウザ、WordPress、サーバーなどの仕様は変更される場合があります。 設定変更の前にはバックアップを行い、利用中のテーマ・プラグイン・契約環境に合う方法を確認してください。
- Google for Developers：PageSpeed Insightsについて
- Google検索セントラル：Core Web VitalsとGoogle検索の検索結果について
- Google検索セントラル：ページエクスペリエンスとGoogle検索結果への影響
- web.dev：Googleのツールを使ったCore Web Vitals改善ワークフロー
- web.dev：ブラウザレベルの画像遅延読み込み
- web.dev：端末に合ったレスポンシブ画像の配信
- web.dev：サードパーティJavaScriptのパフォーマンス
- web.dev：HTTPキャッシュによる不要なネットワークリクエストの削減
- web.dev：ウェブフォントのベストプラクティス
