【事例・検証あり】Webページの表示速度改善方法!原因特定と施策の手順と具体的な方法

【事例・検証あり】Webページの表示速度改善方法!原因特定と施策の手順と具体的な方法

Webページの表示速度は、SEO順位やユーザー体験、コンバージョン率に直結する重要な要素です。

本記事では、表示速度が遅くなる原因の特定方法から、実際の改善手順、具体的な施策までを体系的に解説します。

初心者でも実践できる内容に整理しているため、どこから改善すべきか明確になり、効率的にサイト高速化を進めることができます。

LandingHub導入で表示速度の改善事例を紹介

株式会社ヴェントゥーノ様

改善ポイント1

PageSpeed Insights ページにより増減はあるが、導入前3点ほどだったものが現在は24点に向上している

改善ポイント2

広告や企画等の影響も考慮しつつ、導入前後で概算130%程度の改善感触がある

改善ポイント3

社内にエンジニア不在、オフライン中心事業でWebに関する知見者が少ない中での改善ができた

事例の詳細はこちら

株式会社クロコス様・株式会社ファンファレ様

改善ポイント1

記事LPから本LPへ遷移するときのローディング画面の表示遅延が解消(クロコス様)

改善ポイント2

社内リソースを大幅に割かず速度改善を実現(クロコス様)

改善ポイント3

FVに大容量の動画を設置してもスムーズに再生が可能に(ファンファレ様)

事例の詳細はこちら

ゴリラクリニック様

改善ポイント1

重い動画ファイルを使用したLPでも高速表示が可能に

改善ポイント2

動画を盛り込んだLPにより、ユーザー反応が改善

改善ポイント3

「動画LP × 表示速度改善」の仕組みが整い、今後のLP改善やマーケ施策に必須の基盤に

事例の詳細はこちら

→LandingHub導入サービスのその他の実績

表示速度が遅くなる主な原因

画像容量が大きい

Webページで最も表示速度へ影響しやすいのが画像容量です。

高解像度の画像をそのまま掲載すると、読み込みデータ量が増加し、特にスマホ回線では表示完了まで時間がかかります。

ECサイトやLPでは画像点数が多くなりやすく、LCP悪化の大きな原因になります。

JPEGやPNGをそのまま使うのではなく、WebP・AVIFへの変換、適切なリサイズ、画像圧縮、Lazy Load導入などを行うことで、ページ表示速度を大きく改善できます。

JavaScriptが重い

JavaScriptは便利な反面、読み込み量が多いとページ表示を大きく遅延させます。

特にアニメーション、計測タグ、チャットツール、広告タグなどを大量に導入しているサイトでは、ブラウザ処理負荷が増え、INP悪化や操作遅延につながります。

不要なJavaScriptを削除し、非同期読み込み(async・defer)や遅延実行を行うことで改善可能です。

使っていないライブラリを整理するだけでも、表示速度が大きく改善するケースがあります。

CSS最適化不足

CSSが肥大化していると、ブラウザがページ描画を開始するまでに時間がかかります。

特にWordPressテーマやページビルダーでは、未使用CSSが大量に読み込まれているケースが多く、表示速度低下の原因になります。

必要以上に大きなCSSファイルはレンダリングをブロックし、ファーストビュー表示を遅らせます。

CSS圧縮、不要CSS削除、Critical CSS導入などを行うことで、初期表示速度を改善し、Core Web Vitals向上にもつながります。

サーバー応答速度が遅い

サーバー応答速度(TTFB)が遅いと、ページデータの読み込み開始自体が遅れ、全体の表示速度悪化につながります。

アクセス集中に弱いサーバーや低性能な共有サーバーでは、特に表示遅延が発生しやすくなります。

また、データベース処理が重いWordPressサイトも影響を受けやすい傾向があります。

高速サーバーへの移行、CDN導入、PHPバージョン最適化、キャッシュ利用などを行うことで、サーバー応答速度を大きく改善できます。

外部タグが多い

Google広告、アクセス解析、ヒートマップ、チャット、SNS埋め込みなどの外部タグを大量に設置すると、外部サーバーとの通信が増加し、表示速度低下につながります。

特にマーケティングツールを多用しているページでは、タグ管理が複雑化し、JavaScript処理負荷が高くなるケースが多くあります。

不要タグの削除や読み込み優先順位の最適化、タグマネージャー整理を行うことで、ページ速度改善とINP改善の両方に効果があります。

フォント読み込みが重い

Webフォントはデザイン性向上に役立ちますが、読み込み容量が大きいと表示速度へ悪影響を与えます。

特に日本語フォントはデータ量が非常に大きく、複数ウェイトを読み込むとページ表示が遅くなる原因になります。

フォント読み込み完了まで文字が表示されない「FOIT」が発生するケースもあります。

不要ウェイト削除、サブセット化、font-display設定、ローカルフォント活用などを行うことで、表示速度とユーザー体験を改善できます。

キャッシュ設定不足

キャッシュ設定が適切でない場合、ユーザーがページへアクセスするたびに画像・CSS・JavaScriptなどを毎回再読み込みするため、表示速度が低下します。

特にリピーター訪問時の表示速度へ大きく影響します。

ブラウザキャッシュやサーバーキャッシュ、CDNキャッシュを適切に設定することで、通信量を削減し高速表示が可能になります。

WordPressではキャッシュプラグイン導入だけでも改善効果が大きく、Core Web Vitals改善にもつながります。

Webページの表示速度の改善方法

Webページの表示速度は、LPの離脱率やCVRやとSEO評価に直結する重要な要素です。

ページ読み込み速度の改善により、離脱率の低下、コンバージョン率の向上、検索順位の上昇が期待できます。

画像最適化、サーバー設定、コード軽量化など、多角的なアプローチでページスピードを大幅に改善しましょう。

【効果大】次世代フォーマットの採用

次世代フォーマットのWebPやAVIFを採用することで、従来のJPEGやPNGよりファイルサイズを削減し同等画質を実現します。

WebPは広範囲のブラウザサポート、AVIFはさらに高い圧縮率を提供します。

独自検証を実施した結果ここまでの差が出ました。

詳しい詳細は下記のページをご覧ください。

【独自検証】webpの対応で表示速度はどのくらいかわる?

検証の条件は下記の条件で実施しています。

項目

条件

ページ構成

同一HTML・CSS

Before

JPEG・PNG

After

WebP

画像枚数

17枚

画像サイズ

高解像度画像

比較環境

同一環境

画像ファイル容量の削減効果

画像

ビフォー

WebP

削減率

JPEG商品画像(最大)

2.7 MB

436 kB

約84%

JPEG商品画像(最小)

1.5 MB

75.8 kB

約95%

PNG商品画像

4.2 MB

358 kB

約91%

LCP数値の改善

BEFOREのLCP

AFTERのLCP

35.57s

7.90s

転送量・ページ読み込み時間の削減効果

項目

BEFORE

AFTER

転送量

38.6MB

7.4MB

ページ読み切りまでの時間

38.83s

7.84s

元々の画像の容量や枚数によって変わりますが、未対応の場合はかなり大きな変化が見込めることがわかります。

次世代フォーマットに変換する方法

JPG画像やGIF、PNGの拡張子をwebpやAVIFに変換できる無料ウェブツールがあります。

手動で1つ1つの画像をアップし変換することで、次世代フォーマットの画像が作れます。

ただ、それだと手間や工数がかかって大変なため、LandingHubの導入もおすすめです。

LandingHubではタグ設置するだけで自動的に画像を次世代フォーマットに変換できます。

【効果大】画像を圧縮する

また、次世代フォーマットの変換と並行して画像圧縮もすることで最大限の効果を発揮できます。

圧縮することにより画像が軽量化され、画像はもちろん、ページ全体の読み込み速度も速くなります。

こちらも画像圧縮でどこまで差が生まれるのか、検証しています。

詳しい検証結果の詳細はこちらからご覧頂けます。

【独自検証】画像圧縮でどこまで表示速度は改善される?実際に検証してみた!

検証条件

検証項目

Before(画像圧縮前)

After(画像圧縮後)

使用した画像

Beforeと同じ元画像

Beforeと同じ画像を圧縮

画像の枚数

30枚+LCP用の画像1枚

30枚+LCP用の画像1枚

元画像と圧縮後の容量

約127MB

約19MB

画像フォーマット

JPEG

JPEG

画像サイズ

同一

同一

画像の表示サイズ

同一

同一

Lazy Load

OFF

OFF

画像圧縮の削減効果

指標

圧縮前のページ

圧縮後のページ

変化

画像合計容量

約129MB

約19MB

85%削減

ページ容量

129MB

19.4MB

85%削減

ページ読み込み完了時間

2.2分

24.49秒

1分37秒改善

LCP

29.94秒

8.12秒

21.82秒改善

画像かなり容量の重い状態での比較ですが、ここまでの差が生まれました。

この項目はページの表示速度もそうですが、ユーザービリティにも大きく影響が出る項目なので必ず対策するようにしてください。

画像を圧縮させる方法

次世代フォーマットと同様に、無料ウェブツールがあります。

手動で1つ1つの画像をアップし圧縮することで、圧縮した画像を作れます。

こちらも無料でできる反面、手間や工数がかかるため、LandingHubの導入もおすすめです。

LandingHubではタグ設置するだけで自動的に画像を圧縮できます。

LandingHubであれば画像品質の最適化をした状態で自動で画像圧縮ができるため、品質も保てて工数も削減できた状態で利用できます。

【効果大】画像の遅延読み込みさせる

画像の遅延読み込み(lazy load)は、画面に表示される画像のみを優先的に読み込み、それ以外の画像を後から読み込むという方法です。

特に画像の多いページでは、遅延読み込みをさせることでファーストビューの読み込みが速くなりユーザービリティの向上に役立ちます。

通常は、ページ全体の画像を同時に読み込んでしまうため画像の表示に時間がかかり、ページの表示速度も遅くなります。

画面に表示される画像のみ先に読み込ませることで、初期表示速度を向上させることができます。

遅延読み込みについても実践・検証を行っています。

【実践解説】画像の遅延読み込みの設定方法と表示速度の改善効果を実測比較

検証条件は下記の通りです。

項目

検証条件

画像数

30枚

画像形式

JPG

比較内容

通常読み込み/遅延読み込み

ブラウザ

Google Chrome

計測ツール

Chrome DevTools

キャッシュ

無効

ネットワーク

Fast 4G(高速4G)

下記のような改善がありました。

遅延読み込み前と後の数値の結果

比較項目

遅延読み込みなし

遅延読み込みあり

改善結果

初期画像リクエスト数

60件

8件

52件減

初期転送量

3.2MB

0.373MB

約90%減

LCP

4.17s

1.04s

3.13秒改善

主にページ初期表示に関わる部分の数値ですが、遅延読み込みさせる画像が減る分転送量の削減効果と、LCP数値の改善がありました。

LandingHubもタグ設置だけで自動的に画像の遅延読み込みが可能です。

【効果大】レスポンシブ画像の実装

レスポンシブ画像は、デバイスの画面サイズや解像度に応じて最適な画像を配信する手法です。

特にスマホページで最適なサイズの画像を配信することで、画像の読み込みも速くなります。

その分、他の要素の読み込みも速くなるためページ全体の表示速度も改善されます。

レスポンシブ画像の対応の有無でどこまで速度改善があるか比較してみました。

検証している内容はこちらからご覧頂けます。

【独自検証】画像圧縮でどこまで表示速度は改善される?

検証条件は下記の通りです。

項目

内容

検証対象

画像を20枚掲載した検証用Webページ

Before

PC・スマホともに同じ大きな画像ファイルを配信

After

srcset・sizes を使用し、画面サイズなどに応じて適切な画像を配信

画像サイズ

PC用:幅1600px、スマホ用:幅600px

検証端末

スマートフォンページで比較

スマホの画面幅

412px程度

比較指標

画像の転送量、画像の読み込み時間、LCP、Lighthouseのパフォーマンススコア

レスポンシブ画像の導入結果の数値の変化

検証項目

レスポンシブ画像なし

レスポンシブ画像あり

改善結果

LCP画像の転送量

3.6 MB

124 kB

約96%削減

LCP画像読み込み時間

36.24秒

1.14秒

約35秒短縮

読み込んだ画像のサイズ

1,600px

600px

指定サイズの画像が読み込まれるように

ページ全体の転送量

37.0 MB

2.1 MB

約94%削減

ページ全体の読み込み時間

37.06秒

4.60秒

約32.4秒短縮

レスポンシブ画像を導入したことで、画像全体の転送量や読み込み時間の削減が見られました。

これらの改善によりページ全体の読み込み時間の改善も見られました。

レスポンシブ画像の設定とLandingHubの併用により更に効果が見込める施策になります。

レスポンシブ画像について詳しくは「レスポンシブ画像とは」で解説しています。

ソースコード(CSS・JavaScript等)の軽量化と不要リソースの削除

ソースコードの軽量化は、HTMLやCSS、JavaScriptから不要な空白、改行、コメントを除去してファイルサイズを削減する手法です。

主に圧縮できるポイントとしては下記があります。

  • 空白・改行・インデントの削除
  • 不要なコメントやソースの削除
  • 統合できるものは統合する

空白や改行などの削除ソース例

/* 圧縮前 */
.header {
    background-color: #ffffff;
    margin-top: 20px;
    padding: 10px 15px;
}

/* 圧縮後 */
.header{background-color:#fff;margin-top:20px;padding:10px 15px}

階層や値の統合や整理したソース例

/* 最適化前 */
.header { margin: 10px; }
.header { padding: 5px; }

/* 最適化後 */
.header { margin: 10px; padding: 5px; }

また、使用していないCSSルールやJavaScript関数の削除、重複コードの統合も効果的です。

これにより転送データ量が削減され、ページ読み込み時間の大幅短縮とサーバー負荷軽減を実現できます。

【効果中〜大】CSSの内部化

内部CSS化というのは、ファーストビューで必要なCSS部分をHTMLの<style>タグ内に直接記述する方法です。

そうすることでファーストビューで必要なCSSだけを先に読み込むことができ表示速度が早くなります。

独自検証を実施した結果ここまでの差が出ました。

詳しい詳細は下記のページをご覧ください。

【実践解説】CSSインライン化とは?表示速度改善の方法と効果を実測データで解説

検証内容については下記となります。

項目

内容

計測環境

Chrome DevTools

通信速度

Fast 4G

デバイス

モバイル環境

比較対象

外部CSSとインラインCSS

実践の結果、下記のような改善が見受けられました。

LCP数値の改善

インライン化前

インライン化後

改善結果

4.16s

2.44s

1.72秒改善

上記のようにインライン後はLCPの数値も改善が見られました。

CSSやJavaScriptなどの外部ファイルは、上記のように非同期で読み込ませたり、不要な部分を後から読み込ませることでレンダリングブロックを防ぎ表示速度を改善させます。

こちらの要素はLandingHubでは対応範囲外のため、実際のHTMLを直接修正することで相乗効果が見込めます。

【効果中】フォントのサブセット化を行う

フォントのサブセット化で不要な文字を削除することで、フォントファイルの容量を大幅に削減し、ダウンロード時間を短縮できます。

初期表示の高速化やLCPの改善につながります。

実際に独自検証した結果ここにまとめています。

詳しい詳細は下記のページをご覧ください。

【独自検証】フォントのサブセット化での容量を削減効果を検証

検証の条件は下記の条件で実施しています。

項目

条件

フォント

NotoSansJP

フォーマット

WOFF2

CSS・HTML

読み込むフォントファイルをビフォーアフターで変更

ネットワーク

Fast 4G

フォントサブセット化の効果

サブセット化前

サブセット化後

削減率

フォント容量

2.3 MB

48.1 KB

約98%

転送量

2.3 MB

57.9 KB

約97%

読み込み時間

2.86 s

581 ms

約80%

読み込みの速度がや容量が下がっているのは数値を見ても一目瞭然でわかります。

それ以外にも、サブセット化後は、テキストのフォントの変化は見られませんがサブセット前はページがある程度読み込み終わってからフォントが変化していることがわかります。

上記の動画をご覧いただくとわかりやすいですが、このように容量以外にもページの見た目の部分でも変化が出ます。

日本語フォントは文字数が多く、ファイル容量が大きくなりやすく、LPなど使用する文字が限定されるページでは特に有効な方法です。

LandingHubではフォントのサブセット化は対応できないため、個別で対処することで表示速度の改善に更に貢献できる施策となります。

JavaScriptの非同期読み込みと遅延実行

JavaScriptは便利な反面、読み込み量が増えるとページ表示速度を大きく低下させます。

特に同期読み込みのまま大量のJavaScriptを配置すると、HTML解析が止まり、ファーストビュー表示が遅くなります。

そのため、asyncやdeferを利用した非同期読み込みや、必要なタイミングまで実行を遅らせる「遅延実行」が重要です。

JavaScript最適化のおすすめの方法として、1つ目はファーストビューで必要な分のJavaScriptをasync属性で読み込みます。

async属性は、JavaScriptを非同期で読み込み・実行する属性なので、HTMLの解析を停止せずにスクリプトを並行してダウンロードし、準備完了次第すぐに実行されます。

async属性の記述例としては下記のようになります。

<!-- async: 非同期で読み込み・実行 -->
<script src="script.js" async></script>

2つ目はファーストビュー以外のJavaScriptをdefer属性で読み込みます。

defer属性は、JavaScriptの実行をHTML解析完了後まで延期する属性です。

スクリプトは非同期でダウンロードされますが、HTMLの解析が完了してからDOMContentLoaded前に、記述順通りに実行されるようになります。

jQueryなどのライブラリやDOM操作を行うスクリプト、依存関係があるコードに最適で、実行順序が保証されるためレンダリングブロックを回避しつつ安全にスクリプトを読み込めます。

defer属性の記述例としては下記のようになります。

<!-- defer: 並行ダウンロード、HTML解析完了後に実行 -->
<script src="script.js" defer></script>

※async属性、defer属性は<head>内での記述を行います。

これでレンダリングブロックを回避してページ表示速度を改善できます。

JavaScriptの最適化について詳しくは「JavaScriptの速度改善方法」もご覧ください。

CSSの圧縮

CSSファイルはWebサイトのデザイン表示に必要ですが、不要なコードや改行、重複記述が多いとファイル容量が肥大化し、表示速度低下の原因になります。

CSS圧縮(Minify)は、不要な空白やコメントを削除し、コードを軽量化する施策です。

これにより通信量が減少し、ブラウザの読み込み時間を短縮できます。特にモバイル環境では効果が大きく、表示速度改善によってユーザー体験向上やSEO評価改善にもつながります。

JavaScript圧縮とあわせて実施されることが多い代表的な高速化施策です。

参考:CSSの圧縮

【効果小〜中】GTMの最適化

GTMの最適化は、Google Analytics、広告、SNSウィジェット等のタグ読み込みによる速度低下を防ぐ手法です。

不要なタグを削除し、必要なもののみ厳選して読み込みます。

また、独自検証を実施した結果このような結果が出ました。

詳しい詳細は下記のページをご覧ください。

【独自検証】GTM最適化でサイトの表示速度は改善できる?タグによる速度への影響と改善方法

検証の条件は下記の条件で実施しています。

項目

検証条件

GTM

未整理のものと整理済みのものを比較

ネットワーク

同一条件

キャッシュ

同一条件

計測項目

LCP、転送量など

GTMタグの中身は下記のようになります。

項目

最適化前

最適化後

ヒートマップタグ

2件

1件

GA4

1件+イベントタグ+5

1件+イベントタグ+5

広告タグ

7件

1件

CRM用タグ

1件

1件

自作javascriptタグ

30件

停止状態

上記のように自作のjavascriptを30件を最適化後は停止状態にしています。

それ以外にも無駄な広告タグを除外しているという意味で7件あった広告タグを1つに減らし、ヒートマップタグも1つに減らしています。

最適化後の変化

項目

最適化前

最適化後

リクエスト数

174

118

転送量(transferred)

54.7 MB

39.6 MB

リソース

58.5 MB

42.6 MB

GTMの最適化もタグの内容や量にもよりますが、少なからず表示速度に影響はあるということは言えます。

LandingHubではGTMの整理はできないため、LandingHub導入後も個別に対応していただくことで、更に表示速度改善の効果が見込める施策です。

CDNとサーバーキャッシュを活用する

CDN(Content Delivery Network)は、世界各地のサーバーに静的コンテンツを配置し、ユーザーに最も近いサーバーからリソースを提供することで読み込み時間を大幅短縮します。

また、サーバーキャッシュは、動的コンテンツを一時保存してデータベースアクセスを削減し、応答速度を向上させます。

両者の組み合わせにより、グローバルな高速配信と効率的なサーバー処理を実現します。

CloudflareやAmazon CloudFrontなどでCDNサービスを利用でき、日本サービスではさくらのCDNなどがあります。

LandingHubをタグ設置を導入頂くだけでCDN機能もついてきます。

LandingHubを導入しておけば、他のCDNサービスを別で導入する必要はなくなります。

CDNについて詳しくは「CDNとは」で詳しく解説しています。

ブラウザキャッシュを活用する

ブラウザキャッシュは、CSS、JavaScript、画像などの静的リソースをユーザーのブラウザに一時保存し、2回目以降の再訪問時の読み込み時間を大幅短縮する仕組みです。

.htaccessファイル、HTMLのメタタグやJavaScriptなどでも指定できます。

また、ブラウザキャッシュの設定では、どのファイルに対して、どの程度の期間キャッシュをするか設定ができます。

リソースタイプ

推奨期間

理由

画像ファイル

1年

変更頻度が低い

CSS・JS

1ヶ月〜1年

バージョン管理で対応

フォント

1年

変更されることが稀

HTML

1日〜1週間

内容更新が頻繁

参考ではありますが、運用の必要性に応じてリソース別にキャッシュする期間を設定してあげるといいでしょう。

DOM階層最適化

DOM階層最適化は、HTMLの構造を単純化してブラウザの処理負荷を軽減する手法です。

過度にネストした要素や不要なdiv要素を削除し、階層の深さを浅くすることでレンダリング速度を向上させます。

下記のソース例のように、無駄な要素をまとめるなどしてDOM要素や階層の削減が実現できます。

<!-- 悪い例 -->
<div class="wrapper">
  <div class="container">
    <div class="section">
      <p>コンテンツ</p>
    </div>
  </div>
</div>

<!-- 良い例 -->
<section class="content">
  <p>コンテンツ</p>
</section>

適切なセマンティックHTMLタグを使用し、無駄なマークアップを排除することで、ブラウザのパースや描画処理が効率化され、特にモバイル環境での表示速度が大幅に改善されます。

DOMについて詳しくは「DOMとは」の記事で解説しています。

ページの表示速度の状況を把握する方法

まずはWEBページの状況を把握するために、信頼性の高い計測ツールで現状のパフォーマンススコアを確認していく必要があります。

ここではPageSpeed Insightsを使ったページの表示速度計測方法を解説していきます。

PageSpeed Insightsの測定方法と結果の確認方法

PageSpeed InsightsにアクセスしURLを入力し分析ボタンをクリックするだけで計測が行われます。

計測に1分前後ほど待つ場合がありますが、計測結果や改善点も詳しく表示されます。

スマホ・デスクトップの数値が見分けられる

計測されると下記の画像のような表示となり計測結果も表示されます。

ここでは、URL入力のすぐ下の部分(画像の赤で囲われている箇所)でスマホとデスクトップそれぞれの計測結果を別に見ることができます。

スマホとPCでは大きく差が生まれることが多く、スマホ・デスクトップ別にどこを修正したらいいか確認する際はこちらを見るようにしましょう。

実際のユーザーの環境での評価の見方

URL入力欄の少し下の部分に「実際にユーザー環境で計測する」という項目が出てきます。

実際にユーザー環境で計測された数値は下記画像の赤枠部分で確認することができます。

ポイントとして、ここで表示されているデータは「実際のユーザーの環境」での評価となります。

実際のユーザーの環境というのは、Chrome User Experience Report(CrUX)データに基づいており、以下の具体的な条件が加わり測定されています。

  • デバイスやブラウザ環境
  • 回線速度や接続環境
  • 地理条件

そのため「実際のユーザーの環境で計測されている数値」となり、ユーザー環境によっても変動することだけ理解しておくといいでしょう。

表示速度を改善する場合に確認する指標

表示速度を改善する場合は、下記の指標の数値を確認しましょう。

  • LCP(最も大きなコンテンツが表示されるまでの時間)
  • INP:ユーザーの操作に対するページの応答速度
  • FCP:ページ内で最初のコンテンツが表示されるまでの時間
  • TTFB:サーバーが最初のデータを返すまでの時間

上記以外にもPageSpeed Insightsでは「CLS」という指標があります。

CLSはレイアウトのズレを表す大事な指標ではありますが、表示速度という観点では直接影響しないので、ここはで割愛します。

パフォーマンスの問題を診断するの見方

更に下の方へスクロールすると、下記の画像のように「パフォーマンスの問題を診断する」という項目があります。

ここでは、パフォーマンス、ユーザー補助、おすすめの方法、SEOという項目に分けて改善方法が公開されます。

それぞれ詳しく解説していきます。

「パフォーマンス」の項目の見方について

パフォーマンスの項目は下記の画像のような項目が表示されています。

ここでは

  • FCP:ページ内で最初のコンテンツが表示されるまでの時間
  • LCP:ページ内で最も大きなコンテンツが表示されるまでの時間
  • TBT:ページが操作不能な時間の合計
  • CLS:ページ表示中のレイアウトの予期しない移動量
  • SI:ページの可視部分が表示される平均速度

これらの数値の評価が確認できます。

「パフォーマンス」の項目に関しては、「FCP」「LCP」「TBT」「CLS」「SI」という5項目の指標の数値が見れます。

また「パフォーマンスの問題を計測する」セクションは、Lighthouseエンジンによるラボデータ(シミュレーション環境)で測定されているという点は押さえておきましょう。

具体的には、下記のような環境下で計測されている数値となります。

  • CPUを4倍スローダウン
  • ネットワークを4G LTE速度に制限
  • モバイルは375×667px画面
  • デスクトップは1920×1080px画面
  • キャッシュなしの初回訪問の状態

実際のユーザー環境とは異なる理想的な実験室環境で、具体的な技術的問題の特定と改善提案に特化した診断結果となります。

インサイト・診断項目の見方

更にスクロールしていくと、下記の画像のようなINSIGHTS、診断という項目が出てきます。

ここでは、計測結果に応じた具体的な改善内容が確認できます。

上記画像の①では、各指標別の改善項目を絞り込むことができます。

②に関しては、具体的に改善余地のある項目が並びます。

更に右側にある③をクリックすると、更に詳しい改善箇所なども表示されます。

具体的な改善箇所を確認する場合は、インサイト・診断項目を確認して改善を進めましょう。

表示速度が遅い要素の確認と優先度の決め方

表示速度の改善は、遅くする要因が大きいものから改善していくことで施策効果を感じやすくなります。

施策を実施する前に、まずはどの部分が特に遅い要因となっているかを確認し、施策の優先度を決めましょう。

運用上の都合で全ての施策が難しいという場合に、とても役に立つ考え方となります。

下記で確認方法をご紹介します。

①計測する回線の基準を決める

まずは正確な測定環境の基準を決めましょう。

ユーザーの実際の通信環境を反映した測定が重要で、闇雲に計測しても意味がありません。

まずGoogle Analyticsでモバイル・デスクトップの訪問比率を確認し、モバイルが60%以上なら4G環境を測定基準にすべきです。

PageSpeed Insightsはデフォルトで4G想定のため、実環境に近い結果が得られます。

Chrome DevToolsを使った計測前の設定手順

Chrome DevToolsでは、「ネットワーク」タブからスロットリングをかけます。

基本的におすすめは「低速4G」を選択し、実ユーザーの体感速度を再現するのがいいかと思います。

上記の画像の赤枠部分で設定ができます。

サイトの計測目的に合わせて選択してみてください。

※ここの設定で計測結果もかなり変わるため、サイトに合わせて基準をしっかり作っておくことをお勧めします。

②ページ表示速度が遅い原因を把握する

ページの読み込みを段階的に分けると下記のように分けられます。

  • ページのリクエスト開始からダウンロード完了までの時間
  • <head>内のリソースの読み込み時間
  • <body>内のリソースの読み込み時間

まずはどのフェーズの部分の読み込み速度に時間がかかっているかを確認します。

Chrome DevToolsでウォーターフォールを確認し優先を決める

Chrome DevToolsの「ネットワーク」タブを開き、サイトを読み込み直します。

そうすると、下記の画像のように読み込まれたファイルの一覧とウォーターフォールという列で読み込みの状況が把握できます。

上記の図で段階を表すと

赤い枠がページのリクエスト開始からダウンロード完了までの時間

黄色い枠が<head>内のリソースの読み込み時間

青い枠が<body>内のリソースの読み込み時間

という具合に段階に分けて確認することができます。

施策の優先度の決め方としては、上記で説明したグラフを確認し、読み込み時間が長い段階の部分から優先して施策をしていくのが表示速度のインパクトも大きいためお勧めです。

【ケース別】サーバーのレスポンス開始が遅い場合の表示速度改善方法

ウォーターフォールで一番初めに読み込まれるサーバーからのレスポンス受信開始からダウンロード完了までの時間が遅い場合はこちらの改善策をお試しください。

ここはサーバーからのレスポンスが大きく影響する段階です。

下記の手順で計測と現状を把握するところから始めましょう。

  1. Chrome DevTools
  2. 「ネットワーク」タブ
  3. スロットリングなしに設定
  4. 再度ページを読み込み

スロットリングについて通常は「低速4G」で設定することが多いですが、サーバーレスポンシブを正しく計測する場合は「スロットリングなし」に設定するので、その点だけ注意しておきましょう。

まずは、一番初めに読み込まれているファイルのフォーターフォールを確認します。

上記のように詳細を出したら「サーバーの応答を待機しています」の項目を確認します。

目安としてここが20ms以下であればとても良い状態です。

20〜40ms程度であれば許容の範囲になりますが、40ms以上ある場合は下記の改善ポイントをチェックしていきましょう。

②サーバーの応答速度をあげる

サーバー応答速度の向上は、TTFB(Time To First Byte)を改善してページ表示の基盤を最適化する手法です。

特に高性能サーバーへの移行、CDN導入、キャッシュ機能、HTTP/2またはHTTP/3の活用といった方法があり、これによりサーバー応答時間が短縮され、全体的なページ読み込み速度とユーザーエクスペリエンスが大幅に改善されます。

サーバーの速度改善方法も是非参考にしてみてください。

高性能サーバーを使用する

特にサーバーは、最新世代のCPU(多コア・高クロック)とSSDストレージ、大容量メモリ(16GB以上)を搭載したサーバーに移行することで、データベースアクセスやファイル読み込みが大幅に高速化されます。

また、サーバー帯域も重要な選定基準となります。サーバー規模別に合わせて帯域のプランも検討しましょう。

並行して最新のphpを利用している状態にしておくことをお勧めします。

サーバーの種類は専用サーバーを選ぶことで、CPUやメモリなどを独占で使用できるのでサーバーのパフォーマンスを最大限生かせます。

高性能サーバーのポイント

  • 専用サーバーを選ぶ
  • 高性能CPUのサーバーを利用する
  • SSDストレージを選ぶ
  • 大容量メモリ(16GB以上)搭載のものにする
  • 最新のphpを使用する
  • サーバー帯域

HTTP/2またはHTTP/3を使用する

HTTP/2およびHTTP/3は、従来のHTTP/1.1よりも通信効率が大幅に改善され高速化されます。

下記の画像のように、リクエストとレスポンスの効率が格段に上がります。

クライアントとサーバーとの接続効率があがることで表示速度も格段に上がります。

基本的にはサーバーサービスで設定ができるものがほとんどです。

HTTP/3やHTTP/2について詳しくは「HTTP/3とは?HTTP/2の違いや特徴を比較」の記事でも詳しく説明しています。

【ケース別】<head>内の読み込み時間が長い場合の表示速度改善策

ウェブサイトを表示するまでの過程として、サーバーのレスポンスを受けたあとは先に<head>を読み込みます。

<head>内の読み込みはCSSやJavaScriptなどの外部ファイルが、レンダリングのブロックにつながる要素が多いため表示の遅延を起こしやすい部分です。

レンダリングブロックにつながる要素を最適化していくことで表示速度改善に繋がります。

googleの表示速度の指標でもある「LCP」や「FCP」にも効果がある対策です。

詳しくは「レンダリングブロックとは」の記事をご覧下さい。

Webサイトの表示速度が重要な理由

webサイトの表示速度はウェブマーケティングにおいてかなり重要な要素です。

主に下記のような要素に影響します。

影響項目

損失の大きさ

改善の緊急度

ユーザー離脱

★★★★★

最優先

SEO順位低下

★★★★★

最優先

コンバージョン率低下

★★★★★

最優先

広告費の無駄

★★★★☆

高

ブランドイメージ悪化

★★★★☆

高

モバイル機会損失

★★★★★

最優先

競合への顧客流出

★★★★★

最優先

サーバーコスト増

★★★☆☆

中

採用への悪影響

★★★☆☆

中

特に要素として大きな部分をそれぞれ解説していきます。

表示速度と離脱率の関係

Webサイトの表示速度は、ユーザーの離脱率に直接的な影響を与えます。

Googleの調査によると、ページの読み込み時間が長くなるほど、ユーザーは待ちきれずにサイトを離れてしまいます。

表示速度別の離脱率データ

ページ読み込み時間

ユーザー離脱率

直帰率の増加

1秒

基準値

-

3秒

32%増加

+32%

5秒

90%増加

+90%

6秒

106%増加

+106%

10秒

123%増加

+123%

わずか3秒の遅延で、ユーザーの53%がサイトを離脱します。

さらに、表示速度が1秒から3秒に悪化するだけで、直帰率が32%も上昇するのです。

モバイル環境ではこの傾向がさらに顕著で、5秒以上かかるページでは74%のユーザーが離脱します。

特に、ECサイトや問い合わせフォームなど、コンバージョンを目的とするページでは、この離脱率の上昇が直接的な売上損失につながります。

ユーザーは待つことを嫌い、表示が遅ければ即座に競合サイトへ移動してしまうため、表示速度の最適化は最優先で取り組むべき課題です。

表示速度とSEO順位の関係

Googleは2021年のアルゴリズムアップデートで、ページ表示速度を検索順位の重要な評価指標として正式に組み込みました。

Core Web Vitals(コアウェブバイタル)の基準を満たさないサイトは、内容が優れていても検索結果で不利になります。

Core Web Vitals基準と順位への影響

指標

良好(合格)

不良(不合格)

順位への影響

LCP(表示速度)

2.5秒以下

4.0秒以上

2〜5位下落

INP(操作反応)

100ms以下

300ms以上

1〜3位下落

CLS(レイアウト安定性)

0.1以下

0.25以上

1〜2位下落

実際の調査データでは、ページ表示速度が1秒遅延するごとに検索順位が平均2〜3位下がることが確認されています。

特にモバイル検索では影響が顕著で、表示速度が4秒を超えるサイトは10位以上順位が低下するケースもあります。

表示速度の改善により、検索トラフィックが20〜40%増加した事例も多数報告されています。

SEO対策としてコンテンツ改善だけでなく、表示速度の最適化は必須の施策です。

表示速度とコンバージョン率の関係

Webサイトの表示速度は、購入や問い合わせなどのコンバージョン率に直結します。

ユーザーは表示が遅いサイトでは購入を諦め、競合サイトへ移動してしまいます。

逆に、ページ表示が1秒遅延するとコンバージョン率が平均7%低下します。

ECサイトでは、表示速度が0.1秒遅いだけで売上が1%減少するというAmazonのデータもあり、大規模サイトでは年間数億円の損失につながります。

問い合わせフォームでは表示速度が遅いと到達率が低下し、資料請求やメールアドレス登録も減少します。

Webサイトの表示速度改善方法まとめ

Webサイトの表示速度改善は、一度に完璧を目指す必要はありません。

できることから一つずつ、着実に進めていきましょう。

表示速度の改善は、SEO順位の向上、離脱率の低下、コンバージョン率のアップという3つの成果をもたらします。

焦らず、一歩ずつ改善を重ねることで、競合に勝てるWebサイトが完成します。

今日から始められる小さな施策でも、積み重ねれば大きな成果につながります。一緒に、より良いWebサイトを目指して頑張っていきましょう。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る