PageSpeed Insights 改善｜表示速度を上げる10の方法【2026年版】

この記事で分かること

• 表示速度を改善すべき3つの理由（SEO・離脱率・売上への影響）
• Core Web Vitals（LCP / INP / CLS）の合格ラインと意味
• ホームページが遅くなる5大原因と、その見抜き方
• 初心者・開発者の2レベルで使える改善方法10選
• WordPress / ノーコードツール別の改善テクニック
• そのまま使える表示速度改善チェックリスト

「ページが重くて、読まれる前に帰られている気がする」「PageSpeed Insightsを回したら赤いスコアが出た」——そんな不安を抱えていませんか。

Webサイトの表示速度は、SEO（検索順位）とCVR（成約率）を同時に左右する、テクニカル施策のなかでもっとも費用対効果が読みやすい領域のひとつです。Googleは表示速度を含むページ体験を検索評価に取り込んでいます。ただしGoogle自身は、ページ体験を順位を決める単一要素としてではなく、体験全体を表す複数シグナルの一つと位置づけており、SEOのためだけに満点を狙うことが必ずしも時間の最善の使い方とは限らないとも述べています（出典: Google検索セントラル「ページ体験を理解する」）。それでも、表示の遅いサイトが検索でも訪問者の満足度でも不利になりやすいという傾向は、前提として押さえておく価値があります。

とはいえ「結局どこから手をつければいいのか」「用語が多くて原因が特定できない」と感じる方は多いはずです。本記事では、低スコアを 計測 → 原因特定 → 弱い指標から改善 → 再計測 という手順で片づけていく道筋を示します。改善策は 初心者向けの5つ と 開発者向けの5つ に分け、合計10の方法として具体的に解説します。最初に共有しておきたいのは、ゴールは「100点満点」そのものではなく「良好圏に入れて訪問者の体験を底上げすること」だという点です。満点の最後の数点を削り出す工数より、良好圏に届かせてコンテンツを磨くほうが、事業としてのリターンは大きくなります。まずは自分のサイトの現状を無料で測り、本記事の内容と突き合わせるところから始めましょう。

なぜホームページの表示速度を改善すべきなのか

表示速度の改善は、SEO評価・訪問者の離脱防止・売上向上の3つに同時に効く投資です。順番に、データを添えて確認していきます。

検索で競合にわずかでも優位に立ち、来てくれた訪問者を逃さず、問い合わせや売上につなげる——表示速度は、この3つにまとめて効くのが特徴です。予算も人手も限られる中小企業にとって、一手で SEO・離脱・売上の三方向に効くため、限られた工数の優先順位づけで最初に検討すべき施策になります。

表示速度はGoogle検索の評価に組み込まれている

Googleは、表示速度を含む「ページ体験」を検索評価の一部として扱っています。その中心にあるのが、後で詳しく見る Core Web Vitals（LCP・INP・CLSの3指標） です。Googleは、中核的なランキングシステムが優れたページ体験を備えたコンテンツを評価する方針だと説明しています（出典: Google検索セントラル「Core Web Vitalsについて」）。

ただし「速ければ1位になれる」という単純な話ではありません。冒頭で触れたとおり、Googleはページ体験を単一のシグナルとしてではなく、体験全体を映す複数シグナルの一つとして扱うと明言しています。裏を返せば、コンテンツの質が伴って初めて、表示速度が競合との差になります。同じテーマを扱うページと内容で拮抗したとき、体験が良く速いほうが選ばれやすい——だからこそ、検索で競合に差をつけたいなら速度改善は避けて通れない一手になります。

この点を取り違えて「スコアさえ上げれば順位が伸びる」と考えると、中身を後回しにして数字だけを追いかけがちです。表示速度は、あくまで質の高いコンテンツを検索エンジンと訪問者へ正しく届けるための土台にすぎません。薄いページをいくら高速化しても上位は難しく、逆に良い記事が遅さのせいで評価されずにいるなら、速度改善は強力なてこになります。自分のサイトがどちらの状態かを見きわめたうえで、コンテンツと速度の両輪で進めるのが正しい順序です。

検索順位の基本から整理したい方は、あわせてホームページのSEO対策入門もご覧ください。表示速度はSEOの一要素なので、全体像のなかに位置づけて取り組むほうが効果を測りやすくなります。

遅いサイトは訪問者を読み始める前に失う

表示が遅いと、本文を一文字も読まれないうちに訪問者は離脱します。Googleは2016年に、モバイルサイトの読み込みに3秒以上かかると訪問の53%が離脱につながりやすいという分析を公表しています（出典: Google「The need for mobile speed」2016年9月）。10年近く前のデータなので数字そのものは参考値として扱うべきですが、「数秒の遅延がまとまった離脱を生む」という方向性は、後で紹介する2020年公開の調査でも、わずかな速度差が成果を左右するという形で示されています。

考えてみれば当たり前で、検索結果に並んだ何件かのうち、タップした先が白い画面のまま数秒待たされれば、多くの人は戻るボタンで次の候補へ移ります。この「戻る」を押された瞬間、そのページがどれだけ良い内容を仕込んでいても勝負になりません。スマートフォン経由のアクセスが多数を占める今、検索結果や広告から来てくれた訪問者を、表示の遅さだけで取りこぼすのは大きな損失です。訪問数を増やす施策の前に、来てくれた人を逃さない土台を整えることには、十分な意味があります。いまのアクセス状況を数字で把握したい方には、集客をGA4で診断する記事も参考になります。

0.1秒の改善が売上・成約に効く

表示速度の改善は、コンバージョン率（CVR）と購入額に測定可能な形で効きます。Googleの依頼でデロイトがまとめた調査「Milliseconds Make Millions」(2020年公開)では、モバイルサイトの主要な速度指標が0.1秒改善するだけで、小売サイトでは購入ファネルの前進率が「商品一覧→商品詳細」で3.2%、「商品詳細→カート追加」で9.1%上向き、平均注文額は9.2%増えたと報告されています（調査はGoogleの委託で、調査会社「55（フィフティーファイブ）」とデロイトが実施し、欧米の主要37ブランドを対象にしたものです）（出典: web.dev「Milliseconds Make Millions」）。

たった0.1秒でこれだけの差が出るという点が肝心です。たとえば月100件の問い合わせが入る予約サイトなら、この小売データと同程度の弾力性を仮定した場合、数件規模の機会損失を防げる可能性があります（弾力性は業種・導線で変わるため、幅を持たせた試算としてご覧ください）。年間に均せば数十件規模になり、1件あたりの粗利が大きい業種ほど、この差は無視できない金額になります。表示速度は「技術者の自己満足」ではなく、問い合わせ件数や売上として跳ね返る、投資対効果を数字で確かめやすい領域です。この数値を自社の想定件数と粗利に当てはめてみると、速度改善にどこまで人手や費用をかけるかの目安になります。逆に、この試算をせずに広告費だけを積み増しても、流入した訪問者が読む前に帰ってしまえば、その費用は回収できません。

たとえば画像を1枚軽くするだけで、LCPが縮んで検索評価と噛み合い、初回表示が速くなって離脱が減り、購入や問い合わせの完了率まで押し上がります。この連鎖を最短でつかむには、次に自分のサイトを実際に測ってみるのが早道です。まず土台の速度を整えてから集客へ投資する、という順序が費用対効果の面でも理にかなっています。

状況別の読み分け早見表

自分の状況に合わせて、この記事のどこから読み、次に何をすべきかを一覧で確認できます。頭から通読する必要はありません。当てはまる行から始めてください。

Core Web Vitalsとは｜3つの指標を理解する

Core Web VitalsはLCP・INP・CLSの3指標で、Googleが定めた体感品質の合格基準です。読み込みの速さ・操作の応答性・視覚的な安定性という3つの軸で、サイトの使い心地を数値化します。

現在のCore Web Vitalsで応答性を測る指標は INP（Interaction to Next Paint） です。かつて使われていた旧FID（First Input Delay）に代わって応答性の中核指標となったため、いまだにFIDを目標に改善しようとするのは古い前提に立った作業になってしまいます。現在のCore Web Vitalsは次の3つです。

LCP（Largest Contentful Paint）— 読み込みの速さ

LCPの合格ラインは2.5秒以内で、これはページ内で最大の要素が表示されるまでの時間を測る指標です。訪問者が「ページが見えた」と感じる瞬間の代理指標だと捉えると分かりやすいでしょう。多くの場合、ヒーロー画像や大見出しがこの「最大の要素」に当たります。

良好の目安である2.5秒以内はweb.dev「Largest Contentful Paint (LCP)」が示す基準で、2.5秒を超えると「改善が必要」、4.0秒超で「不良」という3区分はweb.dev「Core Web Vitalsのしきい値の定め方」で定義されています。この2.5秒という値は、後で触れる75パーセンタイル（訪問の75%）で評価される点もあわせて覚えておきましょう。表示速度改善の効果がもっとも大きく表れやすいのがこのLCPで、どこから直すか迷ったら最初の一手に据えるのが得策です。

LCPが悪化する主因は、ページ上部に置かれた巨大画像、読み込みの重いWebフォント、そしてサーバー応答の遅さです。中小企業のコーポレートサイトでよく見かけるのは、トップのヒーロー画像に数MBの写真をそのまま置いているケースで、これだけでLCPが3〜4秒台に膨らむことがあります。逆に言えば、その一枚を適切なサイズにリサイズしてWebPへ変換するだけで、LCPが大きく縮むのも珍しくありません。LCPは「訪問者がページの内容を認識できるまでの時間」に直結するため、離脱率にも成約率にも影響が大きい指標です。

PageSpeed InsightsはLCP要素として、最初の画面内に入る「もっとも大きなテキストブロック、または画像」を自動で選び出し、レポート上でその要素を名指しで教えてくれるので、まず自分のページのどの要素が計測対象になっているかを確認するのが出発点になります。ここでよくある落とし穴が、表示を軽くしようと画面内のヒーロー画像にまで遅延読み込みをかけてしまうケースで、LCP要素そのものの読み込みが後回しになり、かえって数値が悪化してしまう点は覚えておく価値があります。逆に、そのヒーロー画像を優先的に読み込ませたいときは、画像タグに fetchpriority="high" を付けたり、あらかじめ先読み（preload）を指定したりすることで、ブラウザがLCP要素を早い段階で取りにいくようになり、表示までの時間を短縮できます。つまりLCP改善は「大きくしすぎない・後回しにしない・むしろ前倒しする」という三点に整理して手を打てます。

INP（Interaction to Next Paint）— 操作の応答性

INPの合格ラインは200ミリ秒以内で、訪問者がボタンやリンクをタップしてから画面が次の状態を描画するまでの時間を測る指標です。クリック・タップ・キー入力など、滞在中に起きるあらゆる操作が対象になります。旧FIDが「最初の操作の待ち時間」だけを見ていたのに対し、INPは滞在中の応答性を総合的に評価するため、体感により近い指標になっています。

200〜500msは「改善が必要」、500ms超は「不良」となります（出典: web.dev「Interaction to Next Paint (INP)」）。この値も、後述のとおり実ユーザーの75パーセンタイルで評価される点に注意してください。加えて、INPは旧FID（First Input Delay）を置き換えた後継指標です。FIDを目標にした改善はすでに古いので、応答性はINPを基準に見てください。INPが悪いサイトは、重いJavaScriptがメインスレッドを長く占有していることが多く、後で紹介するコード最適化が効きます。

具体的には、大量のプラグインやサードパーティスクリプトが同時にJavaScriptを走らせていると、訪問者がボタンを押しても処理待ちの行列に並ばされ、反応が返るまで数百ミリ秒かかってしまいます。フォームの送信ボタンやメニューの開閉が「もたつく」と感じるサイトは、INPが悪化している可能性が高いです。INPは実際に操作されたときにしか計測されないため、ラボ計測では見えにくく、実ユーザーのフィールドデータで初めて表面化することも多い指標です。改善には、不要なスクリプトの削除、重い処理の分割、そしてページごとに必要なコードだけを配信するコード分割が有効です。

この応答性を左右するのが、ブラウザが一度に処理を抱え込んでしまう「長いタスク」の存在です。たとえば入力チェックの多い大きなフォームの検証処理や、外部の解析ツールが操作のたびに呼び出す重いコールバックが一つ挟まるだけで、その処理が終わるまで画面の描画が止まり、INPがあっという間に200ミリ秒を超えてしまうことがあります。ブラウザの描画を担う中心的な処理の流れ（メインスレッド）は一本しかないため、そこを長時間ふさぐ処理があると、その間の操作はすべて後回しになるからです。ここで効くのが、一つの重い処理を小さなかたまりに分けて合間に描画を挟ませたり、すぐには必要ない集計や送信を操作の直後ではなく手が空いたタイミングまで遅らせたりする工夫で、体感の待ち時間を短くできます。「一度に全部やらせない」という発想でコードを見直すと、INPは着実に縮んでいきます。

CLS（Cumulative Layout Shift）— 視覚的な安定性

CLSの合格ラインは0.1以下で、読み込み中に予期せず要素がズレ動く量をスコア化した指標です。読もうとした見出しが下にズレて別のボタンを誤タップした——そんな不快な体験の起きにくさを示します。

0.1〜0.25は「改善が必要」、0.25超は「不良」と判定されます（出典: web.dev「Cumulative Layout Shift (CLS)」）。画像や広告枠にあらかじめ幅・高さを指定しておくだけで大きく改善できるため、技術的な難度が低く費用対効果の高い改善ポイントです。

CLSが起きる典型は、読み込み後に画像の高さが確定して下のテキストが押し下げられる、広告やバナーが後から挿し込まれて全体がガクッとズレる、Webフォントの切り替わりで行の高さが変わる、といったパターンです。訪問者がリンクを押そうとした瞬間に別の要素が割り込んで誤タップさせる——これはコンバージョンを逃す原因にもなります。CLSは3指標のなかでも難度が低く、画像や動画に width と height を指定する、広告枠の高さを先に確保する、フォント読み込み時のちらつきを抑える、といった対処で数字が目に見えて改善します。総合スコアの25%を占める重い指標でありながら手をつけやすいため、最初に着手する改善として相性の良い項目です。

Core Web Vitals 合格判定の閾値

注意したいのは、これらは 「サイト訪問の75%以上が良好値を達成」 して初めて合格とみなされる点です（出典: web.dev「Defining the Core Web Vitals metrics thresholds」）。評価は75パーセンタイルで行われるため、自分の高速な回線で1回テストして「速かった」だけでは足りません。回線やデバイスの弱い訪問者まで含めた実際の分布で、上位75%が良好圏に入っている必要があります。ここが、後述する「ラボ計測」と「フィールド（実ユーザー）計測」の差を読み解く鍵になります。この判定方法を知っておくと、「自分のスマホでは速いのに評価が上がらない」という食い違いの理由がすっと腑に落ちます。

まず無料で計測する｜スコアの読み方と使うツール

改善の前に、まず計測ツールで現状スコアと弱い指標を把握するのが最短ルートです。原因が分からないまま手を動かしても、効果の薄い作業に時間を使いがちだからです。

進め方はシンプルで、次の順番で回します。最初に測り、いちばん足を引っ張っている指標から直すのが鉄則です。

1. 計測: 品質スコアチェッカーやPageSpeed Insightsで現状スコアと弱い指標を把握する
2. 原因特定: 画像・不要コード・レンダリングブロック・サーバー応答・外部スクリプトのどれが効いているかを切り分ける
3. 弱い指標を選ぶ: LCP・INP・CLSのうち、良好圏から外れている指標を1つ選ぶ
4. 改善: 本記事の10の方法から、その指標に効く手を打つ
5. 再計測: 数値で成果を確かめ、次に弱い指標へ移る

1つ直すたびに再計測して効果を確認すれば、どの作業が効いたのかが数字で見え、次の一手も選びやすくなります。

使う計測ツールを選ぶ

計測ツールにはいくつか選択肢があり、それぞれ得意・不得意が違います。名前と強み・限界・向き不向きを先に押さえておきましょう。

PageSpeed Insights（Google公式の無料ツール）は、現状把握をしたいすべての人に向いています。実ユーザーのフィールドデータとラボ計測を両方出してくれるのが強みです。一方、都度URLを入力して計測する仕組みのため、日々の変化を時系列で追う継続監視の用途には向きません。Lighthouse はChromeの開発者ツールに内蔵され、その場でラボ計測を回せるのが便利で、同じDevToolsの「Coverage（カバレッジ）」パネルを併用すれば未使用コードの割合まで見られます。ただし表示される数値は、あくまで自分の環境（回線速度やPCの性能）での結果です。同じページでもテスト環境によって数字がぶれるため、実ユーザーの体験を代表する値ではない点に注意しましょう。シタミ品質スコアチェッカー はPageSpeed InsightsのAPIを利用してモバイルのスコアを取得しており、速度に加えてSEO・アクセシビリティ・ベストプラクティスまで一括で見たい方に向いています。登録もメールアドレスも不要で、URLを入れるだけで4軸をまとめて確認できるのが利点です。数値はAPI準拠の範囲での提示になります。もっとも、Lighthouse個別監査の生ログを深く掘りたい上級者は、あわせてDevToolsを使うとよいでしょう。まずはこのチェッカーで4軸をまとめて把握するのが、最初の一歩として手早い方法です。速度以外も含めた無料ツールの比較や診断結果の読み方は、サイト診断を無料で行う方法で詳しく整理しています。

スコアの読み方とモバイル優先

公式ツールのPageSpeed Insightsでは、パフォーマンススコアが次のように区分されます。

このスコア帯はChrome公式のドキュメントで定義されています（出典: Chrome Developers「Lighthouse performance scoring」）。注意したいのは、スコアが「モバイル」と「PC」で別々に表示されることです。Googleはモバイルを基準にサイトを評価する方針を取っているため、Google検索の評価では モバイルスコアを優先して考えるのが安全です。PCで90点でもモバイルで30点なら、実際の評価では弱いほうが効いてきます。デザイン確認をPCで行うことが多いと、この差を見落としがちなので、必ずモバイル側のタブでスコアを確かめる習慣をつけましょう。

そして、ここでラボとフィールドの差を理解しておくと迷いません。PageSpeed Insightsのレポート上部に出る実ユーザーのデータ（フィールドデータ）は、Chromeユーザーの過去28日間の実測を集めたChrome UX Report（CrUX）に基づき、75パーセンタイルで評価されます。アクセスが少なくページ単位のデータが足りない場合はサイト（オリジン）全体の値に切り替わり、それも足りなければフィールドデータは表示されません（出典: Google for Developers「About PageSpeed Insights」）。つまり上位75%が良好圏に入っていないと合格にはならず、その下に出るLighthouseのラボスコアが良くても、フィールドデータが不合格ということは珍しくありません。なぜ2つがずれるのかというと、ラボ計測は決まった条件をシミュレーションで再現しているのに対し、フィールドは多様な回線・端末の実訪問を集計しているためです。特にモバイルのラボ計測では、通信を低速側にそろえるスロットリングがかかるため、実機より厳しい数字が出ることもあります（出典: DebugBear「Why is my Lighthouse score different from PageSpeed Insights?」）。改善の成果は、最終的にこのフィールドデータで確認します。

フィールドデータをもう一歩広く見たいときに便利なのが、Search Consoleの「ウェブに関する主な指標」レポートです。このレポートは、PageSpeed Insightsと同じ実ユーザーのフィールドデータをもとに、サイトのページが実際にどう表示されているかを示してくれます（出典: Search Console ヘルプ「Core Web Vitals report」）。個別URLではなくサイト全体を対象に、似た状態のページを「不良」「要改善」「良好」のグループに分けて一覧できるのが強みで、どのページ群を先に直すべきかが一目で分かります。ここで「不良」や「要改善」に入ったURLの傾向をつかんだら、本記事の「5大原因」と「10の方法」のうち該当する改善へ進むのが最短ルートです。

どの指摘から直すか（効果の大きい順）

長い監査リストを前に迷ったら、スコアへの寄与が大きい項目から手をつけます。Lighthouse（v10以降、現行の各バージョンも同様）の総合スコアは、TBT（Total Blocking Time）30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10% の重みで計算されます（出典: Chrome Developers「Lighthouse performance scoring」）。この重み付けの一次情報はChrome公式ドキュメントで、同ドキュメント自身も「重み付けは時代とともに変わってきた」と述べているため、将来の変更もあり得る前提で捉えておくと安全です。

つまり、応答性に効くTBT、読み込みに効くLCP、安定性に効くCLSの3つで総合スコアの約8割を占めます。まずはこの3つに直結する改善から着手するのが、もっとも効率のよい順番です。逆に、Speed IndexやFCPは重みが1割ずつと小さいため、これらだけを細かく詰めても総合スコアはあまり動きません。PageSpeed Insightsのレポートには「診断」として多くの改善候補が並びますが、その各項目の横に「推定される節約」として何ミリ秒短縮できるかが示されます。効果の大きい順に並べ替えて、上位のものから対処するのが実務的なコツです。

なお、満点狙いが最善とは限らないというページ体験の考え方（冒頭で触れたとおり）も踏まえ、目標は満点ではなく、まずモバイルで50点以上、次に良好圏（実ユーザーデータで75%が良好）という二段階で十分です。削り出しの数点に工数を割くより、次に弱い指標へ移るほうが総合スコアは早く伸びます。

ホームページの表示速度が遅い5大原因

低スコアの原因は、画像・不要コード・レンダリングブロック・サーバー応答・外部スクリプトの5つにほぼ集約されます。PageSpeed Insightsの指摘文言から、自分のサイトがどれに当たるかを逆引きできるようにまとめました。なお、2025年10月のLighthouse 13で従来の監査項目は「インサイト」に統合され、名称が変わりました（出典: Chrome for Developers「What's new in Lighthouse 13」）。以下では現在の英語名と、古い解説記事で見かける旧名称を併記します。日本語表記は環境によって多少ばらつきますが、キーワードが分かれば見当がつきます。

原因1: 画像が最適化されていない

ホームページの転送量のなかで、大きな割合を占めやすいのが画像です。スマホ撮影のJPEGをそのまま貼っただけ、5000px以上の巨大画像をCSSで縮めて表示している、といったサイトでは、画像だけで数MBを読み込むことになり、LCPが大きく悪化します。

PageSpeed Insightsで画像配信のインサイト（Image delivery。旧「次世代フォーマットでの画像の配信」「効率的な画像エンコード」「適切なサイズの画像」）が出ているなら、原因はほぼ画像です。対処は後述のWebP変換とリサイズが中心になります。目安として、1ページで読み込む画像の合計が1MBを大きく超えているなら、まず画像から手をつけるのが効率的です。写真素材を多用する飲食店・宿泊・美容などの業種では、この画像対策だけでスコアが10〜20点単位で変わることもあります。トップページのファーストビューにある大きな画像は、それ自体がLCP要素になっていることが多いため、真っ先に見直す価値があります。

原因2: 未使用のCSS・JavaScriptが多い

WordPressのテーマやプラグインを増やすほど、そのページの表示には使わない大量のCSS・JSが読み込まれます。診断結果に 「使用していないCSSの削減」「使用していないJavaScriptの削減」 が出ている場合、これに該当します。

ノーコードツールなら軽量テンプレートへの乗り換えで改善する一方、開発者なら不要なライブラリを外すだけで数百KB単位で軽くなります。TBTの悪化にも直結するため、応答性（INP）にも効いてきます。特に、装飾用のスライダーやアニメーション系ライブラリは、実際にはトップページでしか使っていないのに全ページで読み込まれていることが多く、棚卸しの効果が大きい部分です。

原因3: レンダリングブロックリソース

HTML読み込みの途中でCSSやJSが挟まると、ブラウザは描画を中断してそれらを読みに行きます。これが レンダリングをブロックするリクエスト（Render blocking requests。旧「レンダリングを妨げるリソースの除外」） という指摘の正体です。

特に外部から読み込むWebフォントや、<head> に置かれた解析タグなどが原因になりがちです。重要でないスクリプトの読み込みを後回しにするだけでも、初回描画が目に見えて速くなります。方向性としては、見た目に必要な最小限のCSSだけを先に読み込ませ、残りは後回しにする、JavaScriptには読み込みを遅らせる属性を付ける、といった調整が中心になります。CMSによってはこれをプラグインの設定画面から数クリックで実現できるため、開発知識がなくても着手できる場合があります。

原因4: サーバーの応答が遅い

PageSpeed Insightsで サーバーの応答（TTFB）が遅い という指摘が出る場合、それはホスティング環境そのものが弱いか、データベース処理が重いことを意味します。激安レンタルサーバー、海外サーバー、リアルタイム処理の多いCMSなどで起こりがちです。

TTFBの目安は 0.8秒（800ミリ秒）以下とされ、1.8秒を超えると「不良」と判定されます（出典: web.dev「Time to First Byte (TTFB)」）。ここで大切なのは、TTFB自体はCore Web Vitalsではないという点です。あくまでLCPを悪化させる手前の診断指標として使います。とはいえ800msを超えると、どれだけフロント側を最適化しても表示速度の上限が決まってしまいます。自分のTTFBが800msを超えているなら、画像やコードの調整より先に、サーバーやホスティングの見直しから動くのが正しい順序です。ここを飛ばして画像だけ軽くしても、待ち時間の底が抜けたまま作業に終わってしまいます。

TTFBの数値は、PageSpeed Insightsのレポート上部の実ユーザーデータ（データが十分ある場合）と、ラボ計測のインサイト「Document request latency」（旧「サーバーの初期応答時間を短縮してください」）で確認できるので、まずそこを開いて自分のサイトが何ミリ秒かかっているかを見ておきましょう。この値を押し上げるのは、アクセスが集中して余力の乏しくなった共有サーバー、毎回作り直しているキャッシュの効かないデータベース問い合わせ、そして動的に組み立てるタイプのCMSでページの結果を保存する仕組みを入れていないこと、といった要因です。応答の遅い大もとのサーバーを一気に速い機材へ載せ替えるのは大掛かりになりがちですが、その手前に配信の中継役となるCDNや、組み上げたページを一定時間保存して使い回すページキャッシュを置くだけでも、実際に返ってくるまでの待ち時間を大きく縮められます。まずは中継とキャッシュで底上げし、それでも足りなければ大もとの見直しに進む、という段取りが現実的です。

原因5: サードパーティスクリプトの読み過ぎ

アクセス解析、広告タグ、チャットツール、フォーム埋め込み、SNSウィジェット——これらはすべて「サードパーティスクリプト」です。便利な反面、1つあたり数百KBの追加読み込みになることもあり、入れ過ぎると一気に重くなります。

PageSpeed Insights の サードパーティのインサイト（Third parties。旧「サードパーティ コードの影響を抑えてください」） で重いスクリプトが挙がっていたら、本当に必要なものだけに絞り込みましょう。使っていないタグや、キャンペーン終了後に残ったままの計測タグが、体感速度を静かに奪っていることは非常に多いです。とりわけチャットツールやSNSの埋め込みウィジェットは、それ単体で数百KBのJavaScriptを追加し、INP（応答性）にも悪影響を与えます。効果を実感できているものだけを残し、なんとなく入れてある機能は思い切って外すのが、もっとも手早く効く対処です。

ここまでの5つを見渡すと、実は多くが「画像を軽くする」「不要なものを外す」という、専門知識がなくても取り組める作業に収束することが分かります。まずは自分のサイトがどの原因に当てはまるのかを、下のツールで診断してから改善に入りましょう。

表示速度を改善する10の方法【初心者・開発者の2レベル】

改善策は初心者向け5つと開発者向け5つに分け、弱い指標に効くものから取り組むのが効率的です。すべてをやる必要はありません。LCP・INP・CLSのどこが弱いかを確認したうえで、効果の大きいものから順に進めてください。

【初心者向け】今すぐできる5つの改善策

方法1: 画像をWebP形式に変換する

WebPは、同じ画質でファイルサイズを大きく削減できる画像フォーマットです。可逆圧縮ではPNGと比べて約26%小さく、非可逆圧縮では同等画質のJPEGと比べて25〜34%小さくなります（出典: Google for Developers「WebP」）。画像はページの転送量の大きな割合を占めやすいため、他のどの施策より先に着手する価値があります。この一手だけで、読み込みが目に見えて軽くなります。

無料のWeb変換ツール「Squoosh」（Googleが公開するブラウザ内画像変換ツール）を使えば、ドラッグ&ドロップで一括変換できます。向いている人は、手元の画像をまとめて変換したい人です。WordPressユーザーなら「EWWW Image Optimizer」「Converter for Media」「ShortPixel」などのプラグインで、既存画像を自動でWebP化できます。これらのプラグインは、すでにアップロード済みの大量の画像を一括変換できるのが強みで、記事数の多いブログやギャラリーのあるサイトほど効果が大きくなります。向いていない・注意が必要なのは、対応の古い一部環境ですが、いまのブラウザはほぼWebPに対応しているため実務上の問題は小さくなっています。念のため、変換前の元画像は残しておくと、あとで別サイズが必要になったときに再加工しやすく安心です。WebPへの変換とリサイズはセットで行うと効果が最大化するので、この方法1と次の方法2はまとめて取り組むのがおすすめです。

方法2: 画像のサイズを表示サイズに合わせる

スマホで撮影した写真（例: 4032×3024px、機種により異なります）を、サイト上は600px幅で表示している——というケースは非常に多く見られます。ブラウザは元画像のフルサイズをダウンロードしてから縮小表示するため、あらかじめ表示サイズに合った大きさへリサイズしておくべきです。

目安として、全画面に近いヒーロー画像でも幅1600〜2000pxあれば十分です。高精細ディスプレイを意識しても、表示幅の2倍までにとどめましょう。ここを整えるだけで、原因1で見た画像配信の指摘のうち、サイズに関するものの多くは解消します。サムネイルやアイコンのような小さな画像を、元の高解像度のまま並べているケースも要注意です。一覧ページに数十枚のサムネイルがあれば、それぞれが数百KBあるだけで合計は数MBに達します。表示する大きさに合わせて事前に縮小しておけば、こうしたページの読み込みは劇的に軽くなります。無料の画像変換ツール「Squoosh」ならリサイズと形式変換を同じ画面で行えるため、まとめて処理するのに便利です。

方法3: 不要なプラグイン・ウィジェットを削除する

WordPressのプラグインは1つ増えるごとにJSとCSSが追加されるため、使っていないプラグインは無効化ではなく削除が原則です。ノーコードツールでも、使っていないSNS埋め込みやチャットウィジェットは即座に外しましょう。

「念のため残している」プラグインは、ほぼ確実に体感速度を奪っています。これは原因2（未使用コード）と原因5（サードパーティ）の両方に効く、費用ゼロの改善です。整理するときは、半年以上使っていないもの、機能が重複しているもの、開発が止まって更新されていないものを候補に挙げるとよいでしょう。削除する前に念のためバックアップを取り、1つ外すごとに表示崩れがないか確認してから次へ進むと安全です。ノーコードツールでも考え方は同じで、テスト目的で入れたまま放置している埋め込みや、効果を測っていない外部連携は、思い切って外すほど身軽になります。

方法4: ブラウザキャッシュを有効化する

リピート訪問者に対して、画像・CSS・JSをブラウザに保存させる設定です。WordPressなら「WP Rocket」「W3 Total Cache」「LiteSpeed Cache」などのキャッシュプラグインで、ボタン操作から有効化できます。向き不向きでいうと、WP Rocketは有料ながら設定が簡単で高機能、W3 Total Cacheは無料で細かく設定でき、LiteSpeed CacheはLiteSpeedサーバー上でこそ真価を発揮するサーバー依存型です。使っているサーバー環境に合わせて選びましょう。

これだけで2回目以降のページ表示が体感で数倍速くなります。注意点として、キャッシュを有効にした直後はサイトの見た目が更新されにくくなることがあります。デザインやコンテンツを変えたのに反映されない場合は、キャッシュを一度削除（クリア）してから確認してください。また、複数のキャッシュ系プラグインを同時に有効化すると競合して表示が崩れることがあるため、キャッシュプラグインは1つに絞るのが安全です。

方法5: 軽量なテーマ・テンプレートに切り替える

WordPressであれば、GeneratePress / Astra / Kadence など、最初から軽量設計されたテーマに切り替えるだけで、スコアが大きく改善することがあります。向いている人は、手早く土台を軽くしたい人です。向いていない・慎重に判断すべきなのは、すでに大規模なカスタムテーマへ投資済みで、移行のデザイン調整コストが高いサイトです。この場合は無理に乗り換えず、他の方法から着手するほうが現実的です。

見た目を派手にするためにアニメーションや動画背景を多用したテーマは、根本的に重くなりがちです。リッチに見せたい場合も、軽量テーマをベースに必要な装飾だけ足すほうが、結果的に有利になります。テーマを乗り換えるときは、本番サイトをいきなり切り替えるのではなく、複製した検証用の環境で表示崩れがないか確認してから反映すると、公開中のサイトを止めずに済みます。

【開発者向け】さらに効果が大きい5つの改善策

方法6: 遅延読み込み（lazy loading）を実装する

ファーストビュー外の画像・iframeは、初回ロードで読み込む必要がありません。HTMLで loading="lazy" 属性を付けるだけで、モダンブラウザでは遅延読み込みが有効になります。

<img src="/images/photo.jpg" loading="lazy" alt="..." width="800" height="600" />

width と height を必ず指定することで、後述するCLS対策（要素のズレ防止）にもなります。ただしファーストビュー内のLCP画像には lazy を付けないよう注意してください。付けると逆にLCPが遅くなります。ファーストビューに入る画像は最優先で読み込ませ、スクロールしないと見えない画像だけを遅延させる——この線引きが、LCPとデータ転送量の両立につながります。

方法7: 未使用のCSS・JSを削除（コード分割）

Chrome DevToolsの「Coverage（カバレッジ）」パネルで、各CSS・JSファイルのうち実際に使われたコードの割合を確認できます。使用率が低いファイル（目安として30%未満）は、削除・分割の候補です。TBTとINPの改善に直結します。

モダンなフレームワーク（Next.js、Astro、SvelteKit など）であれば、コード分割（code splitting）が標準で有効になっており、ページごとに必要なJSだけが配信されます。古いSPA構成ですべてを1つのbundleにまとめている場合は、ルーティング単位での分割を検討しましょう。トップページを見るだけの訪問者に、問い合わせフォームやマイページ用のコードまで読み込ませているとしたら、それは無駄な待ち時間です。使う画面でだけそのコードを読み込むよう分割すれば、初回に実行するJavaScriptが減り、メインスレッドの占有が短くなってINPが改善し、初回描画が早まってLCPにも効きます。WordPressの場合は、テーマやプラグインが吐き出す不要なCSS・JSを条件付きで読み込ませるプラグインや設定でも、同様の効果が得られます。

方法8: CDN（コンテンツ配信ネットワーク）を導入する

CDNは、世界中のエッジサーバーにコンテンツをキャッシュし、訪問者に地理的に近いサーバーから配信する仕組みです。これによりTTFBが改善し、その分だけ最初の描画が早まってLCPの短縮にもつながり、離れた地域からのアクセスも速くなります。それぞれ向き不向きがあります。

• Cloudflare: 無料プランあり。CMSを問わず導入しやすく、まず試す先として有力
• Vercel / Netlify: Next.jsなどモダンなフロントエンド向けのホスティング兼CDN
• CloudFront: AWS環境で構築しているサイト向け

向いていない条件もあります。国内単一リージョンで完結し、海外からの流入がほぼ無い小規模サイトでは、CDN導入の効果は限定的です。その場合はまずサーバー選定や画像最適化を優先しましょう。とはいえCloudflareは無料プランでも導入でき、静的ファイルのキャッシュや通信の保護といった副次的なメリットもあるため、迷ったらまず無料枠で試し、体感と再計測の結果で判断するのが安全です。全国から幅広くアクセスがあるサイトや、画像・動画を多く配信するサイトほど、CDNの効果は大きく出ます。

方法9: フォント最適化（preload + font-display: swap）

Webフォントは1ファイルで100KB以上あることも多く、LCPに大きな影響を与えます。次の2つを実装しましょう。

<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "MainFont";
  src: url("/fonts/main.woff2") format("woff2");
  font-display: swap;
}

preload で読み込みを前倒しし、font-display: swap でフォント読み込み中もシステムフォントで先に描画させることで、フォントの読み込み待ちで文字が消えたまま、という状態を防ぎ、テキストがLCP要素のページではLCPの短縮につながります。ただし swap はフォントが差し替わる瞬間に行の高さや文字幅が変わってレイアウトのズレ（CLS）を生むことがあるため、preload で差し替えを早めに済ませる、代替フォントとの大きさの差を小さくする、といった対策とセットで使いましょう。さらに踏み込むなら、日本語のWebフォントはファイルサイズが特に大きくなりがちなので、実際に使う文字だけに絞るサブセット化や、装飾用フォントを本文には使わないといった判断も効果的です。装飾のこだわりよりも、まず本文が素早く読める状態を優先すると、体感速度は大きく変わります。読み込むフォントの種類（ウェイト）を必要最小限に絞るだけでも、転送量を減らせます。

方法10: SSG / SSR / ISR でレンダリング最適化

クライアントサイドレンダリング（CSR）一辺倒のSPAは、初回表示でJSをすべてダウンロード・実行してから描画が始まるため、LCPが構造的に遅くなります。

• SSG（静的サイト生成）: ビルド時にHTMLを生成。最速
• SSR（サーバーサイドレンダリング）: リクエスト時にHTMLを生成。動的データに対応
• ISR（増分静的再生成）: SSGとSSRの利点を両立。Next.jsなどで利用可能

ブログ・コーポレートサイト・LPなど、ほとんどの用途ではSSGかISRが最適解です。ページの内容がそれほど頻繁に変わらないサイトなら、あらかじめHTMLを生成しておくことで、訪問者が来た瞬間には完成したページを返せます。これがLCPを短縮する、もっとも根本的な手段です。ただしこの方法は既存サイトの根本構成に関わるため、いま使っているプラットフォームでは実現できないこともあります。その場合は無理に構成を変えるより、次のプラットフォーム別の項を読んで、いまの土台で打てる手と、作り直すべきかの判断をあわせて検討してください。

WordPress / ノーコードツール別の改善テクニック

使っているプラットフォームごとに、効果の出やすい改善手段と限界は異なります。自分の環境に当てはまるところから読んでください。

WordPress の改善ポイント

WordPressは内部に手を入れやすく、打てる手が多いのが強みです。

• キャッシュプラグイン: WP Rocket（有料・高機能）、W3 Total Cache（無料）、LiteSpeed Cache（サーバー依存）を環境に合わせて導入
• 画像最適化プラグイン: EWWW Image Optimizer、Converter for Media、ShortPixel で自動WebP化
• 軽量テーマへの切り替え: GeneratePress / Astra / Kadence
• プラグインの棚卸し: 半年使っていないプラグインは削除
• ホスティングのアップグレード: 共有サーバーからVPSやWordPress特化型へ移行し、TTFBを改善

WordPressで改善を進めるコツは、いきなり多くのプラグインを入れないことです。キャッシュと画像最適化は役割が重なりやすく、複数入れると競合して表示が崩れることがあります。まずは1つずつ導入し、そのつどPageSpeed Insightsで再計測して効果を確認しながら進めましょう。また、テーマやプラグインの更新を長く放置していると、それ自体が速度と安全性の足を引っ張ります。定番プラグインを最新に保つだけでも、無駄な処理が減って軽くなることがあります。ホスティングについては、月額数百円の激安共有サーバーを使っている場合、サーバー応答（TTFB）が構造的に遅く、フロント側をどれだけ整えても頭打ちになりがちです。アクセスが増えてきたサイトほど、ホスティングの見直しが効きます。

キャッシュやCDNを入れたときは、本当に効いているのかを思い込みで判断せず、確かめておくと安心できます。手軽なのは、返ってくる通信の付帯情報（レスポンスヘッダー）を見て、保存済みのデータが使われたことを示す印（キャッシュがヒットした旨の表示）が付いているかを確認する方法で、これが出ていれば中継やキャッシュがきちんと働いていると判断できます。もう一つは、導入の前後で、あえて自分の地域から離れた場所を想定した計測を行い、サーバー応答の待ち時間が実際に短くなったかを見比べる方法で、数値の変化として効果を確認できます。こうして「入れたつもり」で終わらせず結果を突き合わせておくと、次にどこへ手を入れるべきかの判断も的確になります。

ノーコード（Wix・Squarespace・ペライチ・Jimdo等）の改善ポイント

Wix / Squarespace / ペライチ / Jimdo といったノーコードツールは、内部の実装に手を入れにくいため、改善余地は限定的です。それでも、設定と運用でできることはあります。

• アニメーション・動画背景を減らす
• 画像はアップロード前にWebP化 & リサイズしておく
• 不要なSNS連携・チャットウィジェットを外す
• テンプレートを軽量なものに変更（途中変更が可能なツールに限る）

ノーコードツールが遅くなりやすいのは、便利さと引き換えに、内部で汎用的なコードやアニメーションを多く読み込む作りになっているためです。利用者が触れるのは見た目の設定だけで、その裏側の配信方法やコード量には手を入れられません。だからこそ、利用者側でできる対策は「読み込む素材を軽くする」「不要な機能を減らす」に集約されます。逆に言えば、これらを尽くしても目標に届かない場合は、ノーコードの構造的な限界に達している可能性が高いです。

その場合は、より自由度の高いプラットフォームへの作り直しが現実的な選択肢になります。ノーコードで手軽に立ち上げた初期段階を過ぎ、集客や成約を本格的に伸ばす段階に入ったサイトほど、この判断が必要になります。判断の進め方や費用感はリニューアルの進め方にまとめているので、作り直しを迷っている方はあわせてご覧ください。

プラットフォーム別 速度改善の自由度

評価軸は「内部実装にどの程度手を入れられるか」です（運用の手間ではありません）。

この表からわかるのは、いま使っている土台次第で「打てる手の上限」が決まるということです。フレームワークやWordPressは設計や設定に踏み込めるため改善の余地が広い一方、ノーコードツールは手軽さと引き換えに触れる範囲が狭くなります。TTFBの底上げのようにサーバー側へ踏み込む対処は、自由度の高い土台でなければ選べません（出典: web.dev「Time to First Byte (TTFB)」）。自由度の低いプラットフォームで頭打ちになっているなら、改善作業に時間をかけ続けるより、最適化済みの土台へ載せ替えたほうが結果的に早く、費用対効果も高いことがあります。まずは自分のサイトが表のどこに当たるかを確認し、そのうえで「いまの土台で詰められるところまで詰める」のか「作り直しを検討する」のかを判断してください。この見極めを早い段階でしておくと、無駄な作業に時間を費やさずに済みます。

シタミなら表示速度の最適化が組み込まれている

シタミで生成するホームページは、表示速度の最適化を前提とした設計方針で作られており、改善作業そのものに時間を取られにくいのが特徴です。画像の最適化やモダンな配信の仕組みを土台に組み込む方針のため、公開後に速度チューニングへ追われる負担を減らせます。

「改善方法は分かったが、自分で実装する自信がない」「専門知識を持つ担当者がいない」という方は、最初から最適化を意識した土台を選ぶことで、手間の多くを省けます。ここまで読んでお分かりのとおり、表示速度の改善は個別テクニックの寄せ集めではなく、画像の扱い方・コードの配信方法・サーバーの応答性といった「作りの土台」に大きく左右されます。古い構成のまま部分的にプラグインで手当てを続けると、いたちごっこになりがちです。

これは、日々の運用に割ける人手が限られる中小企業ほど効いてきます。担当者が本業の合間にPageSpeed Insightsのレポートと格闘するより、最初から整った土台に載せて、コンテンツや集客といった本来注力すべき部分に時間を使うほうが、事業としての成果は出やすくなります。シタミでは、購入前に完成品のホームページを実際に見て確かめられるため、速度を含む仕上がりを自分の目で確認してから判断できます。まずは自分のサイトの現状スコアを、下のチェッカーに公開URLを入れて確認してみてください。速度以外の品質（SEO・アクセシビリティ・ベストプラクティス）もまとめて把握でき、いま自分のサイトがどのくらいの位置にいるのかが一目で分かります。

作り直しやリニューアルを見据えている場合は、リニューアルAI SEO診断チェックリストで、速度を含む改善観点を事前に洗い出しておくと判断がスムーズです。完成したホームページを見てから判断したい方は、この記事末尾の完成品プレビュー導線からどうぞ。

表示速度改善チェックリスト

測定・画像・コード・配信の4カテゴリで、自分の取り組み状況を一気に確認できます。上から順に埋めていけば、抜け漏れなく進められます。

測定

• 品質スコアチェッカーで現状スコアを把握済み
• PageSpeed Insightsで モバイル スコアを確認済み
• Core Web Vitalsの3指標（LCP / INP / CLS）の現在値を把握済み
• 実ユーザーのフィールドデータ（75パーセンタイル）で合格圏かを確認済み

画像最適化

• WebP形式に変換済み（PNG比約26%・JPEG比25〜34%の削減が目安）
• 表示サイズに合わせてリサイズ済み
• ファーストビュー外の画像に loading="lazy" を設定済み
• width と height 属性を必ず指定

コード最適化

• 不要なプラグイン・ウィジェットを削除済み
• 未使用のCSS・JavaScriptを削減済み（使用率30%未満は候補）
• ブラウザキャッシュを有効化済み
• サードパーティスクリプトを必要最小限に絞っている

配信最適化

• CDNを導入済み（海外・遠隔地の流入があるサイト）
• フォントの preload と font-display: swap を設定済み
• サーバー応答（TTFB）が0.8秒以下に収まっている

すべてに一気にチェックを入れる必要はありません。スコアの足を引っ張っている指標から優先的に取り組み、1周してもう直すところがなくなったら、それが良好圏に入れる目安になります。

よくある質問（FAQ）

まずは無料の計測から始めるのが、遠回りに見えて最短の道です。スコアと弱い指標さえ分かれば、本記事の「5大原因」と「10の方法」のどれが自分に該当するかが見えてきます。1ヶ所ずつ着実に直し、再計測で成果を確認していけば、体感で別物のように速いサイトへ近づけます。

今すぐ動いたほうがよいのは、自力での実装が難しい方、社内に対応できる担当者がいない方、そもそも作り直し（リニューアル）を前提に考えている方です。この場合は、完成品のホームページを見てから判断できるので、いきなり大きな決断をせずに済みます。逆に、まだ急がなくてよいのは、計測してみて画像のリサイズやプラグイン整理など軽微な改善で足りそうな方です。この場合はまずチェックリストを自分で進めてみてください。料金の目安は料金プランのページで確認できます（プランはライト・スタンダード・プレミアムの3種で、いずれもリリース記念として構築費が無料になる案内が出ています。2026年9月時点、最新は同ページをご覧ください）。

本記事の数値は、本文中にリンクした Google 検索セントラル・web.dev・Chrome 公式ドキュメント、および調査会社55とデロイトの調査に基づきます。モバイル離脱の53%（2016年）は年数が経った傾向値で、各しきい値は将来更新されることがあります。最終更新は2026年9月です。