「Webサイトの表示速度が遅い」と感じつつ、何から改善すればいいのか分からず悩んでいませんか？
表示速度はSEOの検索順位だけでなく、離脱率やコンバージョン率にも直結する重要指標です。
この記事では、表示速度が遅くなる原因とPageSpeed Insightsでの測定方法、難易度別の改善方法12選を解説します。
読み終える頃には、自社サイトで何から着手すべきかが明確になり、改善の実行（または外注の判断）に進める状態になります。
- 戦略設計・SEO対策・AIO対策・コンテンツ制作・運用サポートまで、Webマーケティングを一貫支援
- 相談料無料！現状の課題や要望を丁寧にヒアリングし、最適な施策をご提案
- 施策実行後のアフタフォローも提供！改善要求にも柔軟に対応
Webサイトの表示速度は、SEOだけでなくユーザー体験やコンバージョンにも関わる重要な要素です。ページの読み込みに時間がかかると、検索順位への影響だけでなく、閲覧途中での離脱や問い合わせ・購入機会の損失にもつながります。
ここでは、Webサイトの表示速度を改善することで得られる主なメリットを3つ解説します。
表示速度はGoogleの検索ランキング要素になる
Googleは、ユーザーが快適にWebページを利用できるかを評価する指標として「Core Web Vitals」を導入しています。LCP（最大コンテンツの描画時間）やINP（操作への応答性）などが代表的な指標です。
表示速度そのものだけで検索順位が決まるわけではありませんが、ページの読み込みや操作性を改善し、ユーザー体験を高めることはSEOにも関係します。コンテンツの品質や検索意図への適合など、ほかのSEO要素とあわせて改善することが重要です。
表示が遅いとユーザーの離脱率が上がる
ページの表示に時間がかかると、ユーザーが内容を確認する前に離脱する可能性が高まります。特にスマートフォンでは、通信環境や端末性能によって表示速度に差が出やすいため注意が必要です。
たとえば、広告からLPへ誘導している場合、広告自体のクリック率が高くてもページの読み込みが遅ければ、十分な情報を見てもらえません。集客後の機会損失を防ぐためにも、ページをすぐに閲覧できる状態に整えることが大切です。
表示速度の改善はCVR・売上の向上に直結する
表示速度の改善は、問い合わせや購入などのコンバージョンにも影響します。ページが素早く表示されれば、ユーザーが商品情報や料金、導入事例などを確認しやすくなり、フォームや購入ページまで進みやすくなります。
特にECサイトや広告用LPでは、表示速度の改善によって離脱を抑え、CVRの向上につながる可能性があります。改善前後でページの表示速度だけでなく、離脱率やCVRなども確認すると、施策による変化を把握しやすくなります。
Webサイトの表示速度が遅くなる主な原因5つ
Webサイトの表示速度が遅くなる原因は、画像や動画などのコンテンツだけではありません。HTML・CSS・JavaScriptの構成やサーバー、外部ツール、装飾など、複数の要素が影響します。
主な原因を把握しておくと、速度改善の優先順位をつけやすくなります。ここでは、代表的な5つの原因を解説します。
画像・動画のデータ容量が大きい
高解像度の画像や長時間の動画をそのまま掲載すると、ページの読み込みに時間がかかります。とくにファーストビューに容量の大きな画像や動画を配置している場合、初期表示の速度に影響しやすくなります。
画像はWebPやAVIFなどの次世代フォーマットへの変換、適切なサイズへのリサイズ、圧縮などで容量を抑えられます。動画についても、必要以上に高画質なファイルを直接読み込ませないなどの工夫が必要です。
HTML・CSS・JavaScriptが肥大化している
HTMLやCSS、JavaScriptのファイルが大きくなると、ブラウザがデータを読み込んで処理する負担が増えます。不要なコードや重複した記述、使用していないライブラリなどが蓄積しているケースもあります。
不要なコードを削除したり、CSS・JavaScriptを圧縮したりすることで、読み込みや処理にかかる負荷を抑えられます。サイトを長期間運用している場合は、不要なコードが残っていないか確認しましょう。
サーバーのスペック・応答速度が不足している
ユーザーがページを開いた際、サーバーからデータが返ってくるまでに時間がかかると、コンテンツの表示も遅れます。アクセスが集中している場合や、サーバーの処理能力がサイト規模に合っていない場合は、応答速度が低下することがあります。
サーバーの性能だけでなく、データベースの処理やキャッシュ設定なども確認が必要です。画像やコードを軽量化しても改善しない場合は、サーバー側の状況を調べると原因を特定しやすくなります。
計測タグ・外部ファイル・プラグインが多すぎる
アクセス解析や広告計測、チャット、SNS連携などの外部ツールを追加すると、そのたびに関連するファイルやスクリプトの読み込みが発生します。
WordPressなどのCMSでは、プラグインを多数導入することで処理が重くなる場合もあります。現在使用していないプラグインや外部ツールを整理し、必要性の低いものを削除することで、読み込み負荷を減らせます。
Webフォント・アニメーションなど装飾が重い
Webフォントや複雑なアニメーション、背景動画などの装飾も、表示速度に影響することがあります。複数のフォントファイルを読み込んだり、JavaScriptで複雑なアニメーションを動かしたりすると、ブラウザ側の処理負荷が増えます。
デザイン性だけを優先せず、ユーザーが情報を確認するうえで本当に必要な装飾かを見直すことが大切です。特にファーストビューでは、視覚的な演出と表示速度のバランスを考えて設計しましょう。
表示速度の測定ツールとPageSpeed Insightsの使い方
Webサイトの表示速度を改善する際は、まず現状を測定し、どの部分がボトルネックになっているかを把握することが重要です。感覚だけで改善を進めるのではなく、測定結果をもとに優先順位を決めることで、必要な箇所から効率よく対策できます。
・PageSpeed Insightsの使い方と結果の見方（フィールドデータ・ラボデータ）
・押さえておきたいCore Web Vitalsの3指標（LCP・INP・CLS）
・その他の測定ツール（Lighthouse・Search Console・GTmetrixなど）
PageSpeed Insightsの使い方と結果の見方（フィールドデータ・ラボデータ）
PageSpeed Insights（PSI）はGoogleが提供する無料の表示速度測定ツールです。
使い方は、以下の4ステップです。
①対象ページのURLを入力
②「分析」ボタンをクリック
③モバイル/PCのタブを切り替えて結果を確認
④「改善できる項目」を確認
| データの種類 | 内容 | 判断での活用方法 |
| フィールドデータ（実際のユーザーデータ） | 過去28日間に実際のユーザーがサイトを訪問した際のCore Web Vitalsの測定値（データが少ない場合は表示されない） | 実際のユーザー体験を評価する最重要データ。訪問者数が少ないサイトでは表示されない場合がある |
| ラボデータ（シミュレーション測定） | Lighthouseによる仮想環境でのシミュレーション測定値（毎回一定条件での測定） | 原因特定・改善効果の確認に使用。「改善できる項目」の詳細がここに含まれる |
PSIの結果で最初に確認すべきは「モバイルのCore Web Vitals」のフィールドデータです。多くのサイトではモバイルの方がスコアが低く、かつGoogleがモバイルファーストインデックスを採用しているため、モバイルの改善が優先事項になります。
押さえておきたいCore Web Vitalsの3指標（LCP・INP・CLS）
| 指標 | 正式名称 | 意味 | 良好の基準値 |
| LCP | Largest Contentful Paint | ページの主要なコンテンツ（最大の画像またはテキストブロック）が画面に表示されるまでの時間 | 2.5秒以内 |
| INP | Interaction to Next Paint | ユーザーがページ上で操作（クリック・タップ・キー入力）をしてから次のフレームが描画されるまでの応答時間 | 200ミリ秒以内 |
| CLS | Cumulative Layout Shift | ページ読み込み中にレイアウトがどの程度ずれるかを示す視覚的安定性の指標 | 0.1以下 |
LCPはページの「見え始める速さ」に最も直結する指標で、改善効果が体感しやすいです。INPはユーザーがボタンをクリックした際の応答性を示し、JavaScriptの最適化が主な改善手段です。
CLSは「読んでいたら文字やボタンが突然動く」というストレスな体験を数値化したもので、広告・画像の幅高さ未指定が主な原因です。
目指すべきスコアの目安と「点数にこだわりすぎない」考え方
PageSpeed Insightsのスコア（0〜100点）の一般的な評価基準はGoogleが以下を示しています。「90〜100点：良好（Fast）」「50〜89点：要改善（Needs Improvement）」「0〜49点：低速（Slow）」。一般的に「90点以上」を目標とすることが多いですが、業種・サイトの機能複雑度によって現実的な目標は異なります。
重要なのは「スコアの点数より・実際のビジネス指標（離脱率・CVR）が改善しているか」という判断です。例えばECサイトや機能が複雑なWebアプリでは90点の達成が難しい場合もあります。「現在50点のサイトを70点に改善し、離脱率が改善した」という実績を積み上げることの方が、スコア90点を完璧に達成することより現実的なアプローチです。
その他の測定ツール（Lighthouse・Search Console・GTmetrixなど）
| ツール名 | 利用形式 | 主な用途 | 向いているユーザー |
| PageSpeed Insights | Web（https://pagespeed.web.dev/） | 単一ページのフィールドデータ+ラボデータ分析 | Web担当者・非エンジニア向け（まず最初に使う） |
| Lighthouse | Chrome DevTools内・CLIツール | 開発環境での詳細なパフォーマンス診断 | エンジニア・開発者向け（本番前の検証に） |
| Search Console | Google Search Console | サイト全体のCore Web Vitalsの状況を継続監視（ウェブに関する主な指標レポート） | Web担当者・SEO担当者（継続監視に） |
| GTmetrix | Web（https://gtmetrix.com/） | 詳細なウォーターフォール分析・経時変化の記録 | エンジニア・上級者向け（詳細診断に） |
| WebPageTest | Web（https://www.webpagetest.org/） | 地域・デバイス・接続速度を指定した詳細測定 | エンジニア向け（特定条件での検証に） |
非エンジニアのWeb担当者は「PageSpeed Insights（現状把握）→Search Console（継続監視）」の2ツールから始めることを推奨します。Search ConsoleのWebに関する主な指標レポートでは、サイト全体のCore Web Vitalsの状況がURLグループ別に確認できます。
Webサイトの表示速度改善方法12選
Webサイトの表示速度を改善するには、原因に応じて画像・コード・サーバーなど複数の要素を見直す必要があります。まずは非エンジニアでも対応しやすい施策から着手し、改善が難しい部分はエンジニアや制作会社に依頼すると進めやすくなります。
自社で対応できる範囲と専門知識が必要な施策を確認しながら、優先順位をつけて取り組みましょう。
| 施策名 | 難易度 | 自社対応 | 主な効果 | |
| ① | 画像の圧縮・リサイズ | 低 | ○（管理画面でも可） | LCP改善・ファイルサイズ削減 |
| ② | 次世代フォーマット（WebP/AVIF）変換 | 低〜中 | ○（プラグインで可） | LCP改善・ファイルサイズ大幅削減 |
| ③ | 動画の埋め込み方式の見直し | 低 | ○ | 初期読み込み速度改善 |
| ④ | 不要プラグイン・計測タグの整理 | 低 | ○（管理画面でも可） | リクエスト数削減・INP改善 |
| ⑤ | ソースコードの軽量化（minify） | 中 | △（エンジニア推奨） | ファイルサイズ削減・読み込み高速化 |
| ⑥ | 画像の遅延読み込み（Lazy Load） | 低〜中 | ○（属性追加のみ） | 初期読み込み速度改善 |
| ⑦ | レンダリングブロックの解消（defer/async） | 中〜高 | ✕（エンジニア依頼） | FCP・LCP改善 |
| ⑧ | ブラウザキャッシュの有効化 | 中 | △（.htaccessまたはプラグイン） | 再訪問ユーザーの読み込み高速化 |
| ⑨ | テキストファイル圧縮（gzip/Brotli） | 高 | ✕（サーバー設定） | ファイル転送サイズ削減 |
| ⑩ | Webフォントの最適化 | 中 | △（CSS設定変更） | CLS・LCP改善 |
| ⑪ | サーバーの増強・移行（TTFB改善） | 高 | ✕（ホスティング変更） | TTFB改善・全体的な速度向上 |
| ⑫ | CDNの導入 | 高 | ✕（インフラ設定） | 地理的距離による遅延解消 |
①画像を圧縮・リサイズして最適化する
最も即効性が高く・非エンジニアでも実施しやすい施策です。
具体的な手順は、以下のとおりです。
①表示サイズに合わせてリサイズする（例：横幅1,200px以上の画像を表示幅に合わせて800px以内に縮小）
②圧縮ツールで画質を下げずにファイルサイズを削減する
代表的な圧縮ツールとしては、以下が挙げられます。
・TinyPNG
・Squoosh
・WordPressプラグイン
目安として、Web掲載用の画像は100〜300KB以下を目指すことを推奨します。
②画像をWebP・AVIFなど次世代フォーマットに変換する
WebP（Google開発）は従来のJPEGやPNGと比べてほぼ同等の画質を保ちながら、ファイルサイズを25〜35%程度削減できる次世代画像フォーマットです。
AVIF（AV1 Image File Format）はさらに圧縮効率が高いですが対応ブラウザがまだ限られています（2026年時点では主要ブラウザが対応中）。
WordPressサイトではEWWW Image Optimizer・ShortPixel等のプラグインで自動WebP変換が可能です。既存サイトへの対応は「新規アップロード画像からWebPに切り替える」方法が現実的です。
③動画の埋め込み方式を見直す（外部ホスティング・クリック再生）
動画ファイルを自社サーバーに直接アップロードしてvideoタグで埋め込む方式は、ページ読み込み時に大容量ファイルのダウンロードが始まるため速度に大きく影響します。
推奨の改善方法は、以下の2つです。
①YouTube・Vimeo等の外部ホスティングサービスに動画をアップロードしiframeで埋め込む（動画データはYouTube側のサーバーから配信される）
②動画を即時自動再生せず・サムネイル画像を表示してクリック時に動画を読み込む設計にする（Lazy Embed）
特にファーストビューに動画が設置されているページは、この施策でLCPが大幅に改善するケースがあります。
④WordPressの不要なプラグイン・計測タグを整理する
WordPressサイトを管理している場合、プラグインは「現在実際に使用しているもの以外はすべて無効化・削除する」という整理が基本です。有効化したまま使っていないプラグインは読み込み処理が発生するため速度低下の原因になります。
プラグインの棚卸し手順は、以下のとおりです。
①全プラグインの一覧を確認
②各プラグインの用途と現在の使用状況を確認
③使用していないものを無効化
④無効化後に問題なければ削除
計測タグ（広告タグ・アクセス解析）はGoogleタグマネージャー（GTM）に集約して管理することでパフォーマンスへの影響を最小化できます。
⑤HTML・CSS・JavaScriptのソースコードを軽量化する
ミニファイ（Minify）とは、コード内の空白・改行・コメントを削除してファイルサイズを削減する処理です。
たとえば10KBのJavaScriptファイルがミニファイによって7〜8KBになるケースがあります。WordPressではLiteSpeed Cache・W3 Total Cache等のキャッシュプラグインのCSS・JS最適化機能でミニファイを実施できます。
ただし「一部のプラグインとの競合でサイトが壊れる」というリスクがあるため、適用後は全ページの表示確認が必要です。未使用のCSSやJavaScriptの削除はエンジニアによるコードレビューが必要な場合が多いため、エンジニアへの依頼が現実的です。
⑥画像の遅延読み込み（Lazy Load）を設定する
遅延読み込み（Lazy Load）とは「ページ全体の画像を一度に読み込むのではなく・スクロールして画面に近づいたタイミングで読み込む」という設計です。
特に、縦に長いページや大量の画像が掲載されているページで初期読み込み速度の改善に効果があります。HTML5以降はimgタグにloading属性を追加するだけでブラウザネイティブの遅延読み込みが実装できます（loading="lazy"）。
ただし、ファーストビューの画像（最初から見える画像）には設定しないことが重要です。ファーストビューの画像にLazy Loadを設定するとLCPが悪化する原因になります。
⑦レンダリングをブロックするJavaScript・CSSを見直す
ブラウザはHTMLを上から読み込む際にscriptタグやlinkタグ（CSS）に遭遇すると、そのファイルの読み込みが完了するまで後続の描画処理を停止します。これが「レンダリングブロック」です。
改善方法は「JavaScriptのscriptタグにdefer属性（HTMLの解析完了後に実行）またはasync属性（非同期で実行）を追加する」「重要でないCSSを非同期で読み込む（クリティカルCSSの分離）」です。
defer/async属性の追加は技術的な理解が必要なため、エンジニアまたは制作会社への依頼を推奨します。PSIで「レンダーブロック リソースの除外」という指摘がある場合はこの施策が該当します。
⑧ブラウザキャッシュを有効にする
ブラウザキャッシュとは「一度サイトを訪問したユーザーのデバイスに画像・CSS・JavaScriptを保存し、次回訪問時にサーバーから再ダウンロードせずローカルから読み込む」という仕組みです。再訪問ユーザーの読み込み速度が大幅に向上します。
Apacheサーバーの場合は.htaccessファイルにCache-Controlヘッダーを設定します。WordPressではキャッシュプラグイン（W3 Total Cache・LiteSpeed Cache等）のブラウザキャッシュ機能を有効化することで設定できます。
設定する有効期限は「変更頻度が低いファイル（画像・フォント）：1年以上」「変更頻度が高いファイル（JS・CSS）：1週間〜1ヶ月」が一般的な目安です。
⑨gzip・Brotliでテキストファイルを圧縮する
gzipおよびBrotliはサーバーからブラウザにHTML・CSS・JavaScriptなどのテキストファイルを送信する際に圧縮することで、データ転送量を削減する技術です。
gzipで60〜80%、Brotliでさらに効率よく圧縮できる場合があります。設定はサーバー側で行うためエンジニア・ホスティング会社への依頼が必要です。多くの主要レンタルサーバー・マネージドWordPressホスティングではすでにgzipが有効化されているため、PSIで「テキスト圧縮を有効にする」という指摘がない場合は対応済みと判断できます。
Brotliはgzipより効率が高いですが、サーバーの対応状況の確認が必要です。
⑩Webフォントの使用を最適化する
Webフォントの最適化方法は主に3つです。
①表示制御の設定（font-display:swap）：フォントの読み込み中もシステムフォントでテキストを表示し、フォント読み込み完了後に切り替える設定です。「フォントが読み込まれるまでテキストが表示されない（FOIT）」という問題を解消します。
②サブセット化：日本語フォントは文字数が多くファイルサイズが大きいため、使用する文字だけを含むサブセットを使用することでファイルサイズを削減できます。
③システムフォントの活用：特定のWebフォントへのこだわりがなければ、OS標準搭載のシステムフォントを使用することでフォントファイルの読み込み自体をゼロにできます。
⑪サーバーを増強・移行する（応答時間TTFBの改善）
PSIで「サーバーの応答時間（TTFB）を短縮する」という指摘が継続している場合、①〜⑩の施策を実施しても根本的な改善にならない可能性があります。
TTFBの良好な目安はGoogle基準で「800ミリ秒以内」です。サーバーの改善方法は「プランのアップグレード（共有サーバー→上位プランへの移行）」「高速なホスティングサービスへの移行（ConoHa WING・さくらインターネット高速プラン・AWS・GCP等のクラウドへの移行）」があります。
リダイレクト（301/302）の数が多い場合もTTFBに影響するため、不要なリダイレクトの削減も有効です。HTTP/2・HTTP/3プロトコルへの対応で並列リクエストが改善される場合もあります。
⑫CDNを導入する
CDN（Content Delivery Network）とは「世界各地に分散したサーバーにコンテンツのコピーを配置し、ユーザーに最も近いサーバーからコンテンツを配信する仕組み」です。
物理的な距離によって発生する通信遅延（レイテンシ）を削減します。特に「全国・海外からアクセスがある」「画像や動画ファイルが多い」「アクセス数が多くサーバー負荷が高い」サイトで導入効果が高いです。
代表的なCDNサービスはCloudflare（無料プランあり）やAWS CloudFrontなどです。WordPressサイトではCloudflareのプラグインを使った簡易導入も可能です。
表示速度の改善はどこから着手すべき？効果×難易度の優先順位
表示速度の改善は、すべての施策を一度に実施する必要はありません。まずは現在のサイトで何がボトルネックになっているかを確認し、「効果が大きい・難易度が低い」施策から優先して対応することがポイントです。
・まずはPageSpeed Insightsの「改善できる項目」の上位から着手する
まずはPageSpeed Insightsの「改善できる項目」の上位から着手する
PSIの診断結果を確認すると、サイトごとに改善すべきポイントが異なります。まずは「改善できる項目」に表示された内容と、実際の影響度を照らし合わせて、優先順位を決めましょう。
| PSIの指摘文言（代表例） | 対応する本記事の施策 |
| 適切なサイズの画像を使用する / 効率的な画像エンコードを使用する | ① 画像の圧縮・リサイズ |
| 次世代フォーマットでの画像の配信 | ② 次世代フォーマット（WebP/AVIF）への変換 |
| オフスクリーン画像を遅延読み込みする | ⑥ 画像の遅延読み込み（Lazy Load） |
| レンダーブロック リソースの除外 | ⑦ レンダリングブロックするJS・CSSの見直し |
| ブラウザのキャッシュを活用する | ⑧ ブラウザキャッシュの有効化 |
| テキスト圧縮を有効にする | ⑨ gzip・Brotliによるテキスト圧縮 |
| Webフォントのパフォーマンスを改善する | ⑩ Webフォントの最適化 |
| サーバーの応答時間を短縮する（TTFB の短縮） | ⑪ サーバーの増強・移行 |
| 使用していない JavaScript を削除する / 使用していない CSS を削除する | ⑤ ソースコードの軽量化 |
| 静的アセットには効率的なキャッシュポリシーを使用する | ⑧ ブラウザキャッシュの有効化 |
施策別の効果・難易度・自社対応可否
「効果の大きさ」と「実施難易度」を軸に整理すると、改善の優先順位が伝わりやすくなります。表現も少し整えるなら、以下の形がおすすめです。
| 施策 | 効果 | 難易度 | 自社対応 | 推奨着手順 |
| ①画像の圧縮・リサイズ | 高 | 低 | ○ | ★★★ まず最初に |
| ②次世代フォーマット変換 | 高 | 低〜中 | ○（WPはプラグイン） | ★★★ まず最初に |
| ③動画埋め込み方式の見直し | 中〜高 | 低 | ○ | ★★★ まず最初に |
| ④プラグイン・タグの整理 | 中 | 低 | ○ | ★★★ まず最初に |
| ⑥Lazy Load（遅延読み込み） | 中 | 低 | ○（属性追加のみ） | ★★☆ 次に |
| ⑧ブラウザキャッシュ有効化 | 中 | 中 | △（プラグイン可） | ★★☆ 次に |
| ⑩Webフォントの最適化 | 中 | 中 | △（CSS変更） | ★★☆ 次に |
| ⑤ソースコードの軽量化 | 高 | 中 | △（エンジニア推奨） | ★★☆ エンジニアと |
| ⑦レンダリングブロック解消 | 高 | 高 | ✕（エンジニア依頼） | ★☆☆ エンジニア依頼 |
| ⑨gzip・Brotli圧縮 | 中 | 高 | ✕（サーバー設定） | ★☆☆ エンジニア依頼 |
| ⑪サーバー増強・移行 | 高 | 高 | ✕（ホスティング変更） | ★☆☆ TTFBが悪い場合 |
| ⑫CDN導入 | 中〜高 | 高 | ✕（インフラ設定） | ★☆☆ 大規模サイト向け |
まずは、画像・動画・不要なプラグインやタグなど、比較的取り組みやすく効果を確認しやすい施策から着手しましょう。 それでも改善が十分でない場合は、キャッシュやWebフォント、ソースコードの最適化へ進み、TTFBやサーバー性能に問題がある場合はサーバー移行やCDN導入を検討します。
この順番なら、最初から大掛かりな開発やサーバー移行に着手せず、改善効果を確認しながら段階的に対応できます。
スマホ（モバイル）だけ表示が遅い場合の対処法
PSIでモバイルのスコアだけが極端に低い場合、以下の観点でモバイル特有の原因を確認します。
①画像のレスポンシブ配信：モバイル画面（幅375px程度）に対してPC向けの大きな画像（幅1,920px等）を配信していると、スマートフォンでの読み込みが重くなります。srcset属性を使って画面サイズに応じた最適なサイズの画像を配信することで改善できます。
②モバイル回線での評価：PSIはモバイルテストに「4G回線相当のシミュレーション」を使用しているため、Wi-Fi環境では問題なくても4G回線では遅い場合があります。
③タップ操作の応答（INP）：スマートフォンでのタップ操作への応答速度はPCのクリックより遅くなる場合があります。JavaScriptの最適化がモバイルのINP改善の主要手段です。
自社でできる改善と制作会社に依頼すべき改善の切り分け
Webサイトの表示速度改善は、すべてをエンジニアに依頼する必要はありません。画像の圧縮や不要なプラグインの整理など、Web担当者が対応できる施策もあります。一方、JavaScriptやCSSの最適化、サーバー設定の変更などは、サイトの不具合につながる可能性があるため専門知識が必要です。
Web担当者が自分でできる施策
コーディングやサーバー設定の知識がなくても、サイトの管理画面や既存ツールを使って対応できる施策があります。まずは以下を確認し、自社で対応できる項目から進めましょう。
| 施策 | 具体的な作業 |
|---|---|
| ① 画像を圧縮・リサイズする | TinyPNG・Squooshなどで既存画像を圧縮し、表示サイズに合わせてリサイズしてからメディアライブラリで差し替える |
| ② WebP・AVIFへ変換する | WordPressならEWWW Image Optimizer・ShortPixelなどを使い、既存画像を次世代フォーマットへ変換する |
| ③ 動画の埋め込み方式を見直す | サイトに直接アップロードしている動画をYouTubeなどへ移し、iframeで埋め込む |
| ④ 不要なプラグインを整理する | WordPressのプラグイン一覧を確認し、使用していないものを無効化して問題がなければ削除する |
| ⑤ 不要な計測タグを整理する | Googleタグマネージャーでタグの使用状況を確認し、不要なタグを一時停止・削除する |
| ⑥ Lazy Loadを設定する | HTMLを編集できる場合、ファーストビュー外の画像にloading="lazy"を設定する |
| ⑧ ブラウザキャッシュを有効化する | LiteSpeed Cache・W3 Total Cacheなどのキャッシュプラグインでブラウザキャッシュを設定する |
上記の施策は「管理画面へのログイン権限」があれば技術知識がなくても実施できます。ただし「プラグインを削除したらサイトのデザインが崩れた」「キャッシュプラグインが競合してエラーが発生した」というリスクもあるため、実施前にサイトのバックアップを取ることを強く推奨します。
エンジニア・制作会社に依頼すべき施策
サーバー設定やコード改修、インフラ変更が必要な施策は、エンジニアや制作会社へ依頼するほうが安全です。依頼時は「表示速度を改善したい」と伝えるだけでなく、PageSpeed Insightsの指摘内容や現在の数値、改善したい指標まで共有すると、原因の特定や見積もりが進めやすくなります。
| 依頼すべき施策 | 依頼先への伝え方・必要な情報 |
| ソースコードの軽量化（minify・未使用CSS/JS削除） | PSIの「使用していないJavaScriptを削除する」指摘のスクリーンショットと現在のスコア |
| レンダリングブロックするJS・CSSの見直し | PSIの「レンダーブロック リソースの除外」指摘と、改善後の目標LCPの数値 |
| gzip・Brotli圧縮の有効化 | PSIの「テキスト圧縮を有効にする」指摘とサーバーの種類（Apache/Nginx/IIS） |
| サーバーの増強・移行（TTFB改善） | 現在のTTFB値（PSIで確認）・現在のホスティングサービス名・目標TTFB |
| CDNの導入 | サイトの月間PV数・対象コンテンツの種類・予算感 |
表示速度改善を外注する場合の費用相場
表示速度改善を外注する場合、依頼範囲によって費用は大きく変わります。簡単な速度診断なら数万円、本格的なコード改修やサーバー移行まで行う場合は数十万円以上になるケースもあります。
| サービスの種類 | 費用の目安（参考） | 含まれる内容 |
| 速度診断・レポートのみ（スポット） | 3〜15万円程度 | PSI・Core Web Vitals分析・原因特定・改善提案書の提出 |
| スポット改修（基本的な最適化） | 10〜30万円程度 | 画像最適化・キャッシュ設定・プラグイン整理・軽微なコード改修 |
| 本格的なコード改修・サーバー移行 | 30〜100万円程度 | レンダリングブロック解消・CDN導入・サーバー移行・全体的な最適化 |
| 継続的な監視・改善 | 月額3〜15万円程度 | 月次スコア計測・速度リポート・定期的な改善提案・対応 |
依頼の際は「現在のPSIスコア・Core Web Vitalsの測定値・目標スコア」を提示すると見積もりの精度が上がります。
改善した表示速度を維持する運用ルール
表示速度は、一度改善したら終わりではありません。画像の追加や計測タグの変更、機能追加などによって、ページの読み込み負荷は変化します。改善した状態を維持するには、日常の更新ルールに速度対策を組み込み、定期的に状態を確認することが大切です。
画像入稿・タグ追加のルールを決めておく
表示速度が改善した後に「新しい担当者が圧縮していない大きな画像をアップロードし続けた」「新しい広告キャンペーンのたびにタグを追加した結果、タグが積み上がった」という原因で速度がリバウンドするケースは非常に多いです。
これを防ぐためにWebサイト更新の「入稿ルール」を文書化し、更新担当者全員に共有することが重要です。入稿ルールに含めるべき主な項目を整理します。
| ルールの種類 | 内容 | ルールの例 |
| 画像サイズ | アップロード前の最大ファイルサイズ | 横幅は表示エリアに合わせてリサイズ（最大幅1,200px）・ファイルサイズは200KB以下 |
| 画像フォーマット | 使用する画像フォーマット | WebP形式を基本・JPEGは圧縮率80%以下で使用 |
| 圧縮ツール | アップロード前に使用する圧縮ツール | TinyPNG（Web上で無料）またはSquooshを使用してから入稿 |
| タグの追加 | 新しい計測タグ・スクリプトの追加手順 | GTM経由で追加（直接HTMLにscriptタグを追記しない）・追加前に担当者承認必須 |
| プラグイン追加 | 新しいプラグインの追加手順 | 追加前にエンジニアまたはWeb担当者の確認を得る・追加後PSIでスコアを確認 |
定期的にスコアを計測しモニタリングする
速度の維持には「定期的な計測と早期の異常検知」が重要です。推奨する監視の運用サイクルは「月次：Search ConsoleのWebに関する主な指標レポートを確認（不良・要改善ページの増減）」「四半期：主要ページのPSIスコアを手動で計測して記録（スコア推移のExcel・スプレッドシートへの記録）」「リニューアルや大型機能追加後：PSIをすぐに測定して変化を確認」です。Search Consoleの「ウェブに関する主な指標」レポートはサイト全体のCore Web Vitalsの状況をURLグループ別に確認でき・問題が発生したURLに関してメール通知が届くため、継続監視の主要ツールとして推奨します。
リニューアル・機能追加のタイミングで速度要件を決める
Webサイトのリニューアルや新機能追加を制作会社に依頼する際に「速度の要件を仕様書に含める」という発注者側の実務Tipsです。制作会社への発注時に「納品時のPSIスコアをモバイル○点以上・LCPを○秒以内」という速度要件を仕様書に明記することで、リニューアル後の速度低下を防ぐことができます。仕様書への記載例は「・モバイルのPageSpeed Insightsスコア：60点以上（目標：70点以上）」「・LCP（Largest Contentful Paint）：2.5秒以内」「・CLS（Cumulative Layout Shift）：0.1以下」という形です。速度要件を「後から言う」のではなく「発注前に合意する」ことが、リニューアル後の速度問題を防ぐ最も効果的なアプローチです。
webサイトの表示速度改善に関するよくある質問
ここでは、webサイトの表示速度改善に関するよくある質問に回答していきます。
表示速度は何秒以内が理想ですか？
Core Web VitalsのLCP（最大コンテンツの描画）に関するGoogleの基準では「2.5秒以内が良好（Good）・2.5〜4秒は要改善・4秒超は低速」とされています（参考：https://web.dev/lcp/）。ページ全体の「完全な読み込み完了時間」としては3秒以内が一般的な目標ですが、それより重要なのは「ユーザーが最初のコンテンツを見られるまでの速さ（LCP）」です。LCPを2.5秒以内に収めることを優先的な目標として設定することを推奨します。
表示速度を改善するとSEO順位はどれくらい上がりますか？
「表示速度を改善すれば順位が○位上がる」という保証はできません。Googleは速度・Page Experienceシグナルを「コンテンツの品質が同等水準の場合の判断材料」として使用しており、速度改善だけで順位が大幅に変化することは通常ありません。
ただし「表示速度の改善→離脱率の低下→セッション時間の増加→ページが多く読まれる」という間接的な効果がSEO評価にポジティブな影響を与えることは考えられます。表示速度改善はSEO単独の対策としてではなく「UXの改善・CVRの向上・集客コストの最適化」という複合的な効果として評価することが適切です。
WordPressの高速化プラグインは使うべきですか？
キャッシュプラグイン（LiteSpeed Cache・W3 Total Cache・WP Super Cache等）は適切に設定すれば表示速度の改善に有効です。
ただし、「プラグインを入れすぎると逆効果になる」「複数のキャッシュプラグインを同時に有効化すると競合してエラーが起きる」という注意点があります。
推奨するアプローチは「まずすでに導入済みのプラグインの重複をなくす（キャッシュ系は1つに絞る）→設定画面で基本的なオプション（キャッシュ・ミニファイ・ブラウザキャッシュ）を有効化→変更後に全ページの表示を確認する」という手順です。
プラグインを追加する前後にPSIでスコアを計測し、改善したかどうかを数値で確認することを推奨します。
まとめ：webサイトの表示速度改善は「測定→優先順位→維持」の順で進めよう
webサイトの表示速度改善は「まず測定（PSI・Core Web Vitals）して原因を特定→効果×難易度の優先順位で着手→改善後の維持のための運用ルールを整備」という3段階で進めることが最も効率的です。非エンジニアのWeb担当者でも「画像の最適化・プラグインの整理・動画の外部ホスティング移行」という自社対応可能な施策から始めることで、コストをかけずに大きな改善が実現できるケースがあります。
WINDOMはコンテンツSEO・オウンドメディア運用代行を軸にwebサイトのパフォーマンス改善相談も受け付けています。「PSIのスコアが低いが何から手をつければいいか」「制作会社に相談したが費用が高くて困っている」という方は、まず無料相談でお気軽にお声がけください。
