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検索セントラル「ページ体験を理解する」）。

しかし「結局どこから改善すればいいのか」「専門用語が多くて何が原因か分からない」と感じる方も多いはずです。本記事では、PageSpeed Insightsの低スコアを 計測 → 原因特定 → 弱い指標から改善 → 再計測 という手順で直していく道筋を示します。改善策は 初心者向けの5つ と 開発者向けの5つ に分け、合計10の方法として具体的に解説します。まずは自分のサイトの現状を無料で診断し、本記事の内容と突き合わせていきましょう。

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

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

ホームページの表示速度を改善する目的は、大きく3つあります。検索でわずかでも有利になること、来てくれた訪問者を逃さないこと、そして問い合わせ・売上につなげることです。どれか一つのためではなく、この3つが同じ一本の改善作業でまとめて動くのが、表示速度という指標の特徴です。

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

Googleは、表示速度を含む「ページ体験」を検索評価の一部として扱っています。中心にあるのが後述する Core Web Vitals（LCP・INP・CLSの3指標） で、Googleはこれらの体験品質について「私たちの中核的なランキングシステムが評価しようとするものと一致する」と説明しています（出典: Google検索セントラル「Core Web Vitalsについて」）。

ただし「表示速度が速ければ検索1位になれる」という単純な話ではありません。Googleは「単一のシグナルではなく、ページ体験全体に一致する多様なシグナルを見ている」と明言しています（出典: Google検索セントラル「ページ体験を理解する」）。つまり、コンテンツの質が伴っていて初めて、表示速度が競合との差になります。同じトピックを扱う競合と内容で互角になったとき、体験の良いほう・速いほうが選ばれやすい——SEOで競合と差をつけたいなら、表示速度の改善は避けて通れない一手です。

この点を誤解して「スコアさえ上げれば順位が上がる」と考えると、コンテンツを疎かにして数字の追求だけに時間を使ってしまいがちです。表示速度はあくまで、質の高いコンテンツを検索エンジンと訪問者に正しく届けるための土台です。中身が薄いページをいくら高速化しても上位表示は難しく、逆に良いコンテンツが遅さのせいで評価されずにいるなら、速度改善は大きなてこになります。自分のサイトがどちらの状態にあるかを見極めたうえで、コンテンツと速度の両輪で取り組むのが正しい順序です。

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

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

表示が遅いと、コンテンツを1文字も読まれないまま訪問者が離脱してしまいます。モバイルサイトの読み込みに3秒以上かかると訪問者の約53%が離脱する、という数値が業界で長く引用されてきました（2017年のGoogle/SOASTA調査として広く引用される数値・最新は要確認）。この数字自体は古く、元の公開ページも現在は取得しづらくなっているため参考値として扱うべきですが、「数秒の遅延がまとまった離脱を生む」という傾向自体は、後述するより新しい調査でも繰り返し確認されています。

スマートフォン経由のアクセスが大半を占める現在、検索結果や広告から来てくれた訪問者を、表示の遅さだけで取りこぼすのは大きな損失です。訪問数を増やす施策の前に、来てくれた人を逃さない土台を整えることには十分な意味があります。アクセスの現状を数字で把握したい方は、集客をGA4で診断する記事も参考になります。

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

表示速度の改善は、コンバージョン率（CVR）と購入額に測定可能な形で効きます。デロイトの調査「Milliseconds Make Millions」(2020)では、モバイルサイトの読み込みが0.1秒速くなるだけで、小売サイトのコンバージョン率が約8.4%改善し、消費額が約9.2%増加したという結果が示されています（出典: web.dev「Milliseconds Make Millions」）。

わずか0.1秒という改善幅でこの差が出る点が重要です。たとえば月100件の問い合わせが入る予約サイトであれば、この小売データと同水準の弾力性を仮定した場合、数件単位の機会損失を回避できる可能性があります（業種や導線によって効果は変わるため、あくまで試算としてご覧ください）。年間に直せば数十件規模になり、1件あたりの粗利が大きい業種ほど、この差は無視できない金額になります。表示速度は「技術者の自己満足」ではなく、問い合わせ件数や売上として跳ね返ってくる、投資対効果を数値で確認しやすい領域です。この数値を自社の想定件数と粗利に当てはめてみると、速度改善に人手や費用をかけるかどうかを判断する目安になります。

ここで押さえておきたいのは、表示速度の改善が「一度やれば終わり」ではなく、SEO・離脱防止・売上という3つの効果が同じ作業から同時に生まれる点です。たとえば画像を軽くする作業ひとつを取っても、それによってLCPが縮んで検索評価に整合し、初回表示が速くなって離脱が減り、結果として問い合わせや購入の完了率が上がります。個別の施策として別々に予算を組む必要がなく、一本の改善で三方向に効く——だからこそ、限られたリソースの中小企業にとって優先度の高い投資になります。逆に言えば、ここを放置したまま広告費だけを増やしても、来てくれた人が読む前に帰ってしまえば費用は無駄になりがちです。まずは土台の速度を整えてから集客に投資する、という順序が費用対効果の面でも理にかなっています。

状況別の読み分け早見表

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

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

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

2024年3月、Googleは応答性の指標を旧FID（First Input Delay）から INP（Interaction to Next Paint） へ正式に置き換えました（出典: web.dev「Interaction to Next Paint (INP)」）。そのため、いまでもFIDを目標に改善しようとするのは古い情報に基づく作業になってしまいます。現在のCore Web Vitalsは以下の3つです。

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

LCPは、ページ内でいちばん大きな要素（多くはヒーロー画像や大見出し）が表示されるまでの時間を測ります。ユーザーが「ページが見えた」と感じるタイミングの代理指標です。

合格ラインは 2.5秒以内。これを超えると「改善が必要」、4.0秒超で「不良」と判定されます（出典: web.dev「Largest Contentful Paint (LCP)」）。この2.5秒という値は、後述する75パーセンタイル（訪問の75%）で評価される点も押さえておきましょう。表示速度改善の効果がもっとも大きく表れやすいのがこのLCPです。どこから直すか迷ったら、投じた労力あたりの効果が大きいLCPを最初の一手にするのが得策です。

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

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

INPは、ユーザーがボタンやリンクをタップしてから、画面が次の状態を描画するまでの時間を測ります。クリック・タップ・キー入力など、ページ滞在中に発生するすべての操作が対象です。旧FIDが「最初の操作の待ち時間」だけを見ていたのに対し、INPはページ滞在中の応答性を総合的に評価するため、より実感に近い指標になっています。

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

具体的には、大量のプラグインやサードパーティスクリプトが同時にJavaScriptを実行していると、ユーザーがボタンを押しても処理待ちの行列に並ばされ、反応が返ってくるまで数百ミリ秒かかってしまいます。フォームの送信ボタンやメニューの開閉が「もたつく」と感じるサイトは、INPが悪化している可能性が高いです。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%が良好圏に入っている必要があります。ここが、後述する「ラボ計測」と「フィールド（実ユーザー）計測」の差を理解する鍵になります。

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

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

進め方はシンプルです。下の図のとおり、計測 → 原因特定 → 弱い指標を選ぶ → 改善 → 再計測 の順で回します。最初に測り、いちばん足を引っ張っている指標から直すのが鉄則です。

使う計測ツールを選ぶ

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

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

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

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

注意したいのは、スコアが「モバイル」と「PC」で別々に表示されることです。Googleはモバイルを基準にサイトを評価する方針を取っているため、Google検索の評価では モバイルスコアを優先して考えるのが安全です。PCで90点でもモバイルで30点なら、実際の評価では弱いほうが効いてきます。

そして、ここでラボとフィールドの差を理解しておくと迷いません。PageSpeed Insightsの下部に出る実ユーザーのデータは75パーセンタイルで評価されるため、上位75%が良好圏に入っていないと合格になりません（出典: web.dev「Defining the Core Web Vitals metrics thresholds」）。上部のラボスコアが良くても、フィールドデータが不合格ということは珍しくありません。改善の成果は、最終的にこのフィールドデータで確認します。

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

長い監査リストを前に迷ったら、スコアへの寄与が大きい項目から手をつけます。Lighthouse（v10以降、現行v12も同じ）の総合スコアは、TBT（Total Blocking Time）30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10% の重みで計算されます（出典: Chrome Developers「Lighthouse performance scoring」）。この重み付けの一次情報はChrome公式ドキュメントです。なお、同じページでもツールやバージョンによってスコアが変わる理由は、第三者の分析でも整理されています（出典: DebugBear「Why is my Lighthouse score different from PageSpeed Insights?」）。

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

なお、Google自身が「SEOのためだけに完璧なスコアを狙うのが時間の最良の使い方とは限らない」と述べている点も忘れずに（出典: Google検索セントラル「ページ体験を理解する」）。100点満点そのものより、良好圏に入れて訪問者の体験を底上げすることを目標にしましょう。スコアの最後の数点を詰めるために膨大な工数をかけるより、その時間をコンテンツの改善や別ページの底上げに回したほうが、事業としての成果は大きくなることが多いです。目安としては、まずモバイルで50点以上、次に良好圏（実ユーザーデータで75%が良好）を狙う、という二段階で考えると迷いません。

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

低スコアの原因は、画像・不要コード・レンダリングブロック・サーバー応答・外部スクリプトの5つに集約されます。PageSpeed Insightsの指摘文言から、自分のサイトがどれに当たるかを逆引きできるようにまとめました。

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

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

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

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

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

ノーコードツールでは軽量テンプレートへの乗り換えで改善する一方、開発者なら不要なライブラリを外すだけで数百KB単位で軽くなります。TBTの悪化にも直結するため、応答性（INP）にも効きます。

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

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

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

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

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

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

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

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

PageSpeed Insights の 「サードパーティ コードの影響を抑えてください」 という警告が出たら、本当に必要なものだけに絞り込みましょう。使っていないタグや、キャンペーン終了後に残ったままの計測タグが、体感速度を静かに奪っていることは非常に多いです。特にチャットツールや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が遅くなります。

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

Lighthouseの「カバレッジ」レポートで、各ファイルの使用率を確認できます。使用率が30%未満のファイルは、削除・分割の候補です。TBTとINPの改善に直結します。

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

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

CDNは、世界中のエッジサーバーにコンテンツをキャッシュし、ユーザーに地理的に近いサーバーから配信する仕組みです。これによりTTFBが改善し、離れた地域からのアクセスも速くなります。それぞれ向き不向きがあります。

• 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とCLSの両方を改善できます。フォントの読み込み待ちで文字が消えたまま、という状態を防げます。さらに踏み込むなら、日本語の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）が構造的に遅く、フロント側をどれだけ整えても頭打ちになりがちです。アクセスが増えてきたサイトほど、ホスティングの見直しが効果的です。

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

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

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

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

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

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

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

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

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

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

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

これは、日々の運用に割ける人手が限られる中小企業ほど効いてきます。担当者が本業の合間に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秒以下に収まっている

すべてに一気にチェックを入れる必要はありません。スコアの足を引っ張っている指標から優先的に取り組むのが鉄則です。まず測り、弱い指標から直し、再計測で成果を確認しましょう。

よくある質問（FAQ）

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

今すぐ相談したほうがよいのは、自力での実装が難しい方、社内に対応できる担当者がいない方、そもそも作り直し（リニューアル）を前提に考えている方です。逆に、まだ相談しなくてよいのは、計測してみて画像のリサイズやプラグイン整理など軽微な改善で足りそうな方。この場合はまずチェックリストを自分で進めてみてください。料金の目安を知りたい方は料金プランのページもあわせてご確認いただけます。

本記事の情報について: 最終更新は2026年8月です。本文の数値・基準は、Google 検索セントラル・web.dev・Chrome公式ドキュメント、およびデロイトの調査など一次情報に基づいており、これらの公開情報を確認して更新しています。各数値（Core Web Vitalsの合格ライン、Lighthouseの重み付け、WebPの削減率、売上インパクトなど）は、本文中にリンクした各出典の公式ページで読者ご自身が確認できます。なお、モバイルの離脱に関する古い業界数値（2017年のGoogle/SOASTA調査として広く引用される値）は元ページが取得しづらくなっているため参考値として扱い、公式リンクは付していません。基準や仕様は更新されることがあるため、最新は各公式ページでご確認ください。