「自社のサイトがなんとなく重い気がする」「PageSpeed Insightsで測ったら赤い項目が並んでいて、何から直せばいいのか分からない」。
表示速度の話になると、こうして手が止まってしまう方は少なくありません。
表示速度は、検索順位にも、訪問者がページを離れる割合にも効いてくる大事な要素です。
ただ、改善項目は一度にたくさん出てくるので、優先順位をつけずに片っ端から手を出すと、時間ばかりかかって成果につながりません。
そこでこの記事では、まず自社のサイトが本当に重いのかを数値で判定する方法から始めて、原因の切り分け、優先順位順の改善手順、そして「どこまで自社でやり、どこから業者に頼むか」の線引きまでを、一本の流れとして整理しました。
Webにそれほど詳しくない方でも、今日から自分の手で動けるところまで落とし込んでいます。
要点この記事を読むとできること
自社サイトが重いかどうかを、PageSpeed Insightsの数値で判定できる
赤い項目のうち、どれを先に直せば順位や問い合わせに効くか順位づけできる
今日から自分でできる改善と、業者に頼むべき改善を分けられる
改善したのにスコアが下がった時に、次にどこを点検すべきか分かる
まず「重いかどうか」を感覚でなく数値で判定する(PageSpeed Insightsの使い方)
表示速度の改善は、「今どのくらい遅いのか」を数値で把握することから始まります。
感覚で「重い気がする」と言っているうちは、直しても効果が分からず、そもそも遅くない部分に手をかけてしまいがちです。
使う道具は、Googleが無料で提供しているPageSpeed Insights(ページスピードインサイト)です。
サイトのURLを入れるだけで、表示速度の点数と、どこが足を引っ張っているかを教えてくれます。
URLを入れてモバイルで測る、基本の3ステップ
手順そのものは難しくありません。
大事なのは「どのページを、どの条件で測るか」です。
- 「PageSpeed Insights」で検索し、計測ページを開いてURLを入力する
- トップページだけでなく、問い合わせや売上につながる主力ページ(サービス紹介・商品ページ)も測る
- 結果は「モバイル」と「デスクトップ」を切り替えて、まずモバイルを基準に見る
意外と見落とされがちなのが、トップページだけ測って安心してしまうことです。
実際にお客様が見るのは商品やサービスの個別ページで、そこが重いと問い合わせや購入の直前で離脱されてしまいます。
順位や売上に効かせたいなら、主力ページこそ測ってください。
もう一つの基準が、モバイル優先という考え方。
というのも、Googleの評価もアクセスの中心もスマホ側だからです。
デスクトップが速くてもモバイルが遅ければ、評価も体感も「遅いサイト」のままです。
「実際のデータ」と「測定データ」、スコアの色の見方
結果画面には、大きく2種類のデータが出ます。
この違いを知っておくと、数字に振り回されずに済みます。
一つはフィールドデータ(実際のユーザー環境)で、過去28日間に実際に訪れた人の体感速度の集計です。
もう一つはラボデータ(測定環境)で、Googleが一定の条件でその場で測り直したシミュレーションの結果です。
この2つは数値がずれることがありますが、それは不具合ではなく仕様です。
実ユーザーは様々な端末や回線で見ているのに対し、ラボは固定条件で1回測るだけだからです。
改善作業の手がかりはラボデータ、効いたかの確認はフィールドデータ、と役割を分けて考えると混乱しません。
パフォーマンススコアは何点で合格か
画面上部に出る0〜100点のパフォーマンススコアは、色で大まかな健康度が分かるようになっています。
細かい数値より、まずは色で全体感をつかむのが実務的です。
PageSpeed Insightsスコアの色分けと目安
| スコア | 色 | 状態の目安 |
|---|---|---|
| 90〜100 | 緑 | 良好。実用上は十分 |
| 50〜89 | 橙 | 改善の余地あり |
| 0〜49 | 赤 | 不良。優先的に対処 |
狙うのは緑(90以上)で十分です。
100点満点を追いかけると、費用対効果が一気に悪くなります。
まずは赤を橙に、橙を緑に近づける。この順で考えると、力のかけどころを間違えません。
Core Web Vitalsの3指標と合格ライン(自社はどれが赤か)
スコアの下には、Core Web Vitals(コア ウェブ バイタル)という3つの指標が並びます。
これは「ページの体感品質」をGoogleが3方向から測ったもので、検索順位の評価にも使われる要素です。
名前は英語の略語で取っつきにくいのですが、意味はシンプルです。
「表示の速さ」「反応の速さ」「画面の安定」の3つ、と捉えてください。
LCP・INP・CLSが何を測っているか
LCP(エルシーピー)は、ページで一番大きな画像や文章が表示されるまでの時間です。
言いかえると「メインの中身が見えるまでの待ち時間」で、ここが長いと開いた瞬間に「遅い」と感じられます。
INP(アイエヌピー)は、ボタンやリンクを押してから反応が返るまでの速さです。
クリックしたのにしばらく無反応、という”もたつき”を測る指標だと考えてください。
CLS(シーエルエス)は、読み込み中に画面がガタッとずれる量です。
押そうとしたボタンが急に下にずれて誤タップした、あの不快な動きを数値にしたものです。
メモ以前は反応の速さを「FID」という指標で測っていましたが、2024年3月12日にINPへ置き換わりました。今はFIDではなくINPを見ます。
3指標の合格ライン早見表
各指標には、Googleが定める「良好」の基準値があります。
自社のどの指標が基準を超えているかが分かれば、先に直すべき方向がそのまま決まります。
Core Web Vitals 3指標の良好ライン
| 指標 | 良好 | 不良 |
|---|---|---|
| LCP(表示) | 2.5秒以下 | 4.0秒超 |
| INP(反応) | 200ミリ秒以下 | 500ミリ秒超 |
| CLS(安定) | 0.1未満 | 0.25以上 |
※ ミリ秒は1,000分の1秒です。INPの200ミリ秒は、押してから0.2秒以内に反応が返る状態を指します。
判断の仕方は単純です。
LCPが赤なら画像やサーバーの読み込みを、INPが赤なら動作の重さを、CLSが赤なら画面のずれを疑う。
3つを同時に直そうとせず、赤い指標から1つずつ向き合うのが近道です。

サイトが重くなる5大原因と、自社の主因の切り分け方
表示が遅くなる原因は、突き詰めると5つのどれかに当てはまります。
原因を絞らずに改善策を全部試すと疲れてしまうので、まず自社はどれが効いているかを見極めましょう。
重さを生む5つの原因
1つ目は画像。
撮ったままの大きな写真をそのまま載せていると、これだけで表示が一気に重くなります。最も多く、最も効果が出やすい原因です。
2つ目はサーバーの応答時間(TTFB)です。
TTFBとは、ブラウザがサーバーに頼んでから最初の返事が返るまでの待ち時間のこと。
ここが遅いと、何を表示する前の段階で時間を取られます。
3つ目はJavaScriptとCSS、つまりサイトを動かしたり装飾したりするプログラム部分です。
これが整理されていないと、本文の表示をブロックして待たせる原因になります。
4つ目はキャッシュ未活用です。
キャッシュとは、一度読み込んだ内容を一時保存して2回目以降を速くする仕組みで、使っていないと毎回ゼロから読み込むことになります。
5つ目は外部タグの入れすぎ。
アクセス解析・広告・チャット・ヒートマップなど、後から足したタグが積み重なると、その読み込みがそのまま重さに変わります。
表示崩れと合わせて点検したい場合は、クロスブラウザ対応の解説記事も判断の材料になります。

PageSpeed Insightsの「改善できる項目」で主因を絞る
自社の主因を当てるのに、推測は要りません。
PageSpeed Insightsの結果の下にある「改善できる項目」が、短縮できる秒数の大きい順に並んでいるからです。
ここを上から読めば、自社で一番効く対策が見えてきます。
下の対応表で、よく出る項目がどの原因にひもづくかを確認してください。
改善項目の文言と、対応する原因
| 項目の文言 | 原因 | 主な対処 |
|---|---|---|
| 次世代フォーマットでの画像の配信/適切なサイズの画像 | 画像 | WebP化・リサイズ |
| サーバー応答時間の短縮 | サーバー | キャッシュ・乗り換え検討 |
| レンダリングを妨げるリソース/未使用のJS・CSS | JS/CSS | 遅延読込・整理 |
| 効率的なキャッシュポリシー | キャッシュ | キャッシュ有効化 |
| 大きなレイアウトシフトを避ける | 画面のずれ | 画像に幅高さ指定 |
注意全部を一度に直そうとしない
改善項目は10個以上ずらっと並ぶこともあります。
上位3つに絞って着手するのが現実的です。下のほうの項目は効果が小さく、手間の割に点数が動きません。
表示速度の改善方法10選(優先順位順)
ここからは具体的な改善方法を、効果が出やすい順に10個並べます。
上から順に試せば、少ない手間で点数とビジネス指標の両方が動きやすくなります。
なお、以下の操作例はWordPressの人気テーマ「SWELL」を使う場合のものですが、画像の軽量化やキャッシュといった考え方は、Shopify・Wix・自作サイトなど、どのサイトでも共通です。お使いのツールの管理画面で同じ役割の機能を探してください。

前半の1〜5は自社の担当者が管理画面だけで完結できるもの、後半の6〜10は設定や判断にやや知識が要るものです。
1〜5:今日から自分でできる改善
(1)画像を軽くする
表示サイズより大きい写真は、アップロード前に縮小し、WebP(ウェッブピー)という軽い画像形式に変換します。
WebPは見た目の画質を保ったままファイルを小さくできる形式で、無料ツールのSquoosh(スクーシュ)などで変換できます。画像対策は最優先と覚えてください。
(2)既存画像を一括圧縮する
すでにたくさんの画像を載せている場合は、画像最適化の機能でまとめて処理します(WordPressなら圧縮プラグイン、ShopifyやWixなら画像最適化アプリや標準機能)。
1枚ずつ差し替えるより手間がかからず、過去記事の重さもまとめて軽くできます。
(3)遅延読み込みを有効にする
遅延読み込みとは、画面に映っていない下のほうの画像を後回しで読み込む仕組みです。
多くのCMSやテーマに遅延読み込みの機能があります。
WordPressのSWELLをお使いなら「SWELL設定 > 高速化」で画像のLazy Load(遅延読み込み)を有効にできます。
(4)キャッシュ機能を有効にする
キャッシュはサーバーやCMSの機能、または専用ツールで有効にできます。
WordPressのSWELLなら「SWELL設定 > 高速化」のキャッシュ機能にチェックを入れるだけで、2回目以降の表示が速くなります。
クリック数回で終わるのに、効果が分かりやすい設定でしょう。
(5)ページ遷移高速化を有効にする
次に開きそうなページを先読みして、体感を軽くする仕組みを備えたツールもあります。
WordPressのSWELLなら、その役割を担うのが「ページ遷移高速化(Prefetch)」の設定です。
これを有効にすると、リンクをたどる時の体感がなめらかになります。
手順WordPress(SWELL)をお使いなら、まず触る場所
SWELL設定 > 高速化
キャッシュ機能・コンテンツの遅延読み込み・ページ遷移高速化(Prefetch)を有効化
画像はアップ前にひと手間
表示サイズへ縮小してからWebPに変換して登録
6〜10:知識が要る・効果の大きい改善
(6)使っていないJavaScript・CSSを整理する
不要な機能や拡張機能(プラグイン等)が読み込むプログラムを減らすと、本文の表示を妨げる待ち時間が短くなります。
ただし削除の判断には知識が要るので、後述の外注ラインも参考にしてください。
(7)不要なプラグイン・アプリを精査する
WordPressのプラグインやECサイトのアプリなど、使っていない拡張機能は表示を重くする一因です。
ただし一括削除は厳禁で、1つずつ無効化して動作を確かめながら進めます。
(8)テキスト圧縮を有効にする
サーバー側でファイルを圧縮して送る設定(gzip等)を有効にすると、転送量が減って速くなります。
レンタルサーバーによっては標準で有効なこともあるので、管理画面を確認します。
(9)CDNを導入する
CDN(シーディーエヌ)とは、画像などのデータを利用者の近くのサーバーから配る仕組みです。
画像や静的ファイルが多いサイトで効果が出やすい一方、小規模なサイトでは効果が限定的なこともあります。
(10)サーバーの見直しを検討する
PageSpeed Insightsで「サーバー応答時間の短縮(TTFB)」が繰り返し指摘される場合に限り、サーバーの乗り換えが選択肢になります。
原因が画像やプログラムなら、サーバーを変えてもほとんど変わりません。
回避やりがちな失敗
速くなると聞いてプラグインを大量に追加する
キャッシュ系を複数入れると競合して、かえって表示崩れや更新の遅れが起きます。キャッシュは1つに統一が原則です。
着手前のチェックリスト
- 設定を変える前にバックアップを取った
- 改善前のスコアとLCP・INP・CLSをスクショで記録した
- 変更は1つずつ行い、その都度PageSpeed Insightsで測り直す段取りにした
- キャッシュ機能とキャッシュ系プラグインが二重になっていないか確認した
モバイルだけ遅い・改善したのにスコアが下がった時の点検
手を入れたあとに「モバイルだけ遅い」「むしろ点数が下がった」という相談はよくあります。
ここで慌てて元に戻すのではなく、原因を順番に潰すのが大事です。
モバイルだけ遅い時に疑う場所
モバイルが遅い原因の多くは、画像・フォント・外部タグ・回線に集約されます。
スマホは画面が小さいぶん、PCサイズの大きな画像を読み込むのは純粋な無駄です。
まずはスマホ表示で大きすぎる画像が出ていないかを確認し、次にチャットや広告などの外部タグを見直します。
PCでは気にならない読み込みも、モバイル回線では体感に響きます。
改善後にスコアが落ちた時の再点検チェックリスト
警告スコアが下がったら、最後に変えた1箇所を疑う
複数を同時に変えていると原因が特定できません。
1つずつ戻して測り直すと、どの変更が悪かったかが分かります。
- キャッシュ系の設定やプラグインが二重になっていないか
- 一番上に出るメイン画像まで遅延読み込みにして、表示が遅れていないか
- 直前に追加したプラグインや外部タグが重さを生んでいないか
- フィールドデータは直近28日間の平均で毎日更新される(約2日遅れ)ため、改善が完全に反映されるには日数がかかる点を踏まえて評価できているか
とくにファーストビューのメイン画像まで遅延読み込みにすると、かえってLCPが悪化します。
一番上の大きな画像だけは遅延の対象から外す、と覚えておくと事故を防げます。
自社でやるか、制作会社・サーバー会社に頼むかの判断基準
表示速度の改善は、全部を自社で抱える必要も、全部を外注する必要もありません。
失敗するとサイト全体が表示できなくなる作業かどうかで、線を引くのが現実的です。
自社対応で十分な範囲と、外注すべき範囲
自社対応と外注の線引き
| 作業 | 担当の目安 |
|---|---|
| 画像の圧縮・WebP化 | 自社 |
| 高速化・キャッシュの設定 | 自社 |
| 不要プラグインの精査 | 自社 |
| サーバー移行・CDN設定 | 外注 |
| テーマのコード改修・htaccess編集 | 外注 |
判断の軸はシンプルです。
管理画面のチェックや画像の差し替えで終わる作業は自社、プログラムやサーバーの根幹をいじる作業は外注と分けます。
とくにサーバーの移行やコードの書き換えは、失敗すると一時的にサイトが開かなくなります。
ここは無理をせず、保守を任せている会社や制作会社に相談したほうが安全です。
そもそも今の保守費が妥当かを点検したい方は、HP保守費用の相場と内訳の記事もあわせてご覧ください。
要点外注に出す前にやっておくこと
自社でできる画像・キャッシュ・プラグインまでは先に片づける
そのうえで残った課題を依頼すれば、見積もりも作業範囲も明確になり、費用の無駄が出にくくなります。
古くて重いサイトを部分的に直し続けるより、作り直したほうが結果的に早いケースもあります。
判断に迷う場合は、リニューアル時期の判断記事が目安になります。
スコアより大事なこと:速度改善を売上・問い合わせにつなげる
表示速度を上げる目的は、点数を稼ぐことではなく、離脱を減らして問い合わせや購入につなげることです。
ここを取り違えると、緑のスコアを眺めて満足して終わってしまいます。
表示が遅いほど訪問者は途中で離れます。
2017年のGoogleの調査でも、モバイルで表示に3秒以上かかると、約53%が離脱する傾向が報告されていました。
少し古いデータなので数値は目安ですが、「遅い=機会損失」という関係は今も変わりません。
だからこそ、改善後は点数だけでなく実際の数字も見ます。
アクセス解析で直帰率(来てすぐ離れる割合)や問い合わせ数が、1〜2週間でどう動いたかを確認してください。
メモ速くしたのに問い合わせが伸びない時は、原因が速度ではないサインです。
導線・訴求・スマホでの見やすさを次に疑ってください。
速度はあくまで土台で、その上で「何を伝え、どこに問い合わせボタンを置くか」が成果を左右します。
速くしても伸び悩むなら、サイトの作りそのものを見直す段階かもしれません。
よくある質問(FAQ)
Qページの表示速度は何秒以内なら合格ですか?
A指標で見ます。LCP(表示)は2.5秒以下、INP(反応)は200ミリ秒以下、CLS(安定)は0.1未満が良好の基準です。PageSpeed Insightsのスコアなら90以上(緑)が目安です。
QPageSpeed Insightsのスコアは何点あればいいですか?
A90〜100が緑(良好)、50〜89が橙(要改善)、0〜49が赤(不良)です。実務上は90以上で十分で、満点を目指す必要はありません。
Qサイトが重い原因は何ですか?
Aサイトが重い主な原因は5つです。大きな画像・サーバー応答時間(TTFB)・JavaScriptやCSSの未整理・キャッシュ未活用・外部タグの入れすぎです。PageSpeed Insightsの「改善できる項目」で自社の主因を特定できます。
Q表示速度はSEO(検索順位)に影響しますか?
A表示速度はSEOに影響します。Core Web Vitalsは検索順位の評価要素の一つです。ただし速度だけで順位は決まらず、コンテンツの中身が主軸で、速度はその上での加点や減点の要因です。
QFIDとINPは何が違いますか?
A2024年3月12日に、最初の操作だけを測るFIDが廃止され、ページ上のすべての操作の反応を測るINPに置き換わりました。今はINPを確認します。
QWordPress(SWELL)で表示速度を上げるには?
A「SWELL設定 > 高速化」でキャッシュ機能・コンテンツの遅延読み込み・ページ遷移高速化(Prefetch)を有効にします。加えて画像のWebP化とリサイズが効果的です。
Q速度改善は自分でできますか、業者に頼むべきですか?
A画像圧縮・キャッシュや高速化の設定・プラグイン整理は自社で可能です。サーバー移行・テーマのコード改修・CDN設定・htaccess編集は失敗するとサイトが表示できなくなるため、制作会社やサーバー会社への依頼が安全です。
まずは画像の軽量化から、1つ動かしてみてください
表示速度の改善は、判定 → 原因の切り分け → 優先順位順の手当て → 改善後の確認という流れで進めると、迷わず前に進めます。
難しそうに見えても、効くのは画像とキャッシュという地味な部分です。
まずは主力ページをPageSpeed Insightsで測り、画像を1枚軽くする。
WordPressのSWELLをお使いなら、あわせて高速化設定をオンにする。
この最初の一歩だけで、数字も体感も動き始めます。
そのうえで、コードやサーバーに踏み込む段階になったら、無理せず専門家に任せるのが安全です。
依頼先を見極めたい時に役立つのが、良いWeb制作会社を見分ける質問集です。
表示速度や保守でお困りであれば、ノーサイドでも遠慮なくご相談ください。
出典: web.dev Largest Contentful Paint (LCP)・Google公式
出典: PageSpeed Insightsについて・Google Developers公式

