WEBサイト構築の流れやかかる費用の相場も紹介
2024.07.09
ホームページの表示速度が遅い原因と改善方法｜WordPressサイトでLCP33.9秒を8.8秒にした方法
「ホームページを開いても、なかなか画像が出てこない」「スマホだと表示が遅い気がする」など、運用しているサイトで、こうした声が出てくることがあります。
実際に計測してみると、あるコーポレートサイトではスマートフォンでメインの画像が表示されるまでに33.9秒かかっていました。ユーザーの多くは、そこまで待ってくれません。
この記事では、WordPressで構築されたコーポレートサイトの表示速度を改善したときの手順を、実際の数値と一緒にまとめました。
目次
表示速度が遅いと、何が起きるのか
表示速度の問題がやっかいなのは、不具合として報告されにくい点です。ページは最終的に表示されるので、エラーにはなりません。ただ、ユーザーは待たずに戻ってしまいます。Googleの調査（2017年）では、読み込みに3秒以上かかるページは、モバイル訪問者の53%が離脱しています。
そして、以下の問題が発生します。
- 広告費 … クリックした時点で費用は発生します。表示前に戻られると、支払いだけが残ります
- 検索順位 … Googleは表示体験を測る指標（Core Web Vitals）を、評価の要素としています
- 問い合わせ … 最初の画面が遅いほど、その先のフォームまで進んでもらえません
まずは計測する｜PageSpeed Insightsで見るべき4つの指標
改善の前に、まず現状を数値で押さえます。使うのはGoogleのPageSpeed Insights（無料）です。URLを入れるだけで、スマートフォン（SP）とPCそれぞれの結果が出ます。
いろいろな数値が並びますが、最初に見るのは次の4つになります。
| 指標 | 意味 | 目安（良好） |
|---|---|---|
| LCP | 主要コンテンツ（多くはメイン画像）が表示されるまでの時間 | 2.5秒以下 |
| FCP | 何かが最初に表示されるまでの時間 | 1.8秒以下 |
| TBT | 操作を受け付けられない時間の合計 | 200ms以下 |
| CLS | 読み込み中にレイアウトがずれる量 | 0.1以下 |
総合スコア（0〜100）の数字そのものより、スコアの下にある「診断」の内訳を見てみると「何が原因で、どれくらい損しているか」がmsやKBで書かれています。
今回のサイトの状態｜描画が始まるまで約7秒
今回、WordPressで構築されたコーポレートサイトの改善前の診断では、次のような内容でした。
| 指摘 | 数値 | 位置づけ |
|---|---|---|
| レンダリングブロック | 約7,030ms | 最大要因 LCP の主因 |
| LCP | 15秒 | CSS/JS を全部読むまで描画しない状態 |
| 画像が未最適化 | 約1,104KB | WebP 未対応・実寸より大きい配信 |
| 未使用 CSS | 約166KB | 読んでいるが使っていない |
| 未使用 JS | 約149KB | 同上 |
| 総ペイロード | 約2,783KB | 1ページあたりの転送量 |
| メインスレッドの長時間タスク | 6件 | JS の実行が詰まっている |
目を引くのは、いちばん上の「レンダリングブロック 約7,030ms」です。つまり、ブラウザがCSSとJavaScriptを読み終えるまで、7秒間なにも描画していないという状態でした。
表示速度が遅くなる4つの原因
今回のサイトで実際に効いていた原因を、整理すると次の4つでした。多くのサイトで共通する内容です。
原因1：CSSとJavaScriptが描画をせき止めている
<head>の中で読み込まれるCSSとJavaScriptは、原則として読み終わるまで描画を止めます。読み込むファイル数が増えるほど、この待ち時間は伸びていきます。今回の約7秒は、ほぼこれが原因でした。
原因2：画像が「表示するサイズ」より大きい
横幅1392pxの画像を、375pxのスマートフォンにもそのまま送っていました。表示は正しく見えるので気づきにくいのですが、通信量としては数倍のムダになります。
原因3：そのページで使っていない CSS / JS を読んでいる
WordPressでは、プラグインが全ページにCSSとJSを出力しがちです。コーポレートサイトで使っているお問い合わせフォームのプラグイン（CSSとJS）が、フォームのないページでも読み込まれているといった状態でした。（今回は未使用CSS約166KB、未使用JS約149KBがありました）
原因4：Webフォントの読み込み
Webフォントの読み込みが今回の隠れた本命でした。日本語のWebフォントは1ウェイトで1MB近くになることがあり、見出しに1つ使うだけで、画像何枚分もの読み込みが発生します。
実際に行った主な施策
① 画像の表示サイズの改善
1.スマートフォンには、小さい画像を送る
同じ画像を、表示サイズごとに3種類用意しました。ブラウザが画面幅を見て、必要なものだけを読み込みます。
| 用途 | サイズ | 容量 |
|---|---|---|
| スマートフォン向け | 375×269 | 約12KB |
| タブレット向け | 768×552 | 約28KB |
| パソコン向け | 1392×1000 | 約81KB |
これまでは、パソコン向けの1392pxの画像をスマートフォンにもそのまま送っていましたが、改善を行ったことでスマートフォンに送る画像が約81KB → 約12KBになり、7分の1以下になりました（画像形式も、軽量なWebPを使用しました）。
2.最初に見える画像だけ、遅延読み込みから外す
「画像の遅延読み込み」は、スクロールされるまで画像を読み込まない仕組みです。WordPressでは、何も設定しなくても自動で有効になっています（この仕様はバージョンによって変わります）。ページ全体を軽くする効果的な手段ですが、最初に見える画像にかけてはいけません。いちばん早く出したい画像を、わざわざ後回しにすることになるからです。
今回のコーポレートサイトは、この遅延読み込みがメイン画像にまでかかっている状態でした。そこで、次のように設定を分けています。
| 画像 | 設定 |
|---|---|
| トップページのメイン画像・ロゴ | 最優先で読み込む（遅延させない・先読みする） |
| 下層ページの背景画像 | 先読みする |
| 2枚目以降の画像 | これまで通り遅延読み込み |
3.画像に「幅と高さ」を指定しておく
サイズが指定されていないと、画像が読み込まれた瞬間に文字やボタンが下へ押し出されてしまいます。あらかじめ幅と高さを指定しておけば、ブラウザが場所を確保してから読み込むため、ズレが起きません。前半で紹介した「CLS」は、このズレの量を表した数値です。
今回はサイト側で寸法を自動的に付与する仕組みを入れ、手書きしていたメインビジュアル（1392×1000）とロゴ（360×78）にも指定を追加しました。
②読み込むファイルを減らす
圧縮する。ただし「まとめる」処理はしない
ファイルから、改行やスペースなど表示に関係ない部分を削って容量を減らしました（圧縮）。これは基本的に安全な処理になります。
一方で、複数のファイルを1つにまとめる処理はあえて行っていません。読み込む順番が変わることでデザインが崩れるケースがあり、あとから原因を追いにくくなるためです。速度改善ツールの設定画面では、この2つが並んで用意されていることが多いので、注意が必要になります。
使っていないファイルは、一気に消さない
「使われていないCSSが約166KB」という指摘がありましたが、これを一度に削ると高い確率で崩れます。今回は、内容が重複していた1ファイルの読み込みだけを止めました（約34KBの削減）。崩れたページが出た場合は、そのページだけ元の読み込みに戻せるようにしてあります。全部消すのではなく、確認しながら段階的に減らしていく前提の設計になります。
③プログラムの読み込み方を変える
そのページで使わないプログラム（JavaScript）を止める
| 止めたもの | 止めた条件 |
|---|---|
| スライダー（画像が自動で切り替わる機能） | スライダーを使っていないページ |
| お問い合わせフォーム関連・スパム対策 | フォームのないページ |
| 絵文字表示用の機能、記事の埋め込み機能 | サイト全体（使用していないため） |
| 管理画面用のアイコン | ログインしていない訪問者の表示 |
| SEOプラグインの表示用ファイル | サイト全体（検索エンジン向けの情報は残す） |
| 古いブラウザ対応用のプログラム | サイト全体 |
| 使っていない書体 | サイト全体 |
あわせて、同じプログラムが2回読み込まれていた箇所も見つかり、1回にまとめました。長く運用しているサイトでは、こうした重複がしばしば残ってしまいます。（具体的にはwp_dequeue_script() / wp_dequeue_style() を wp_enqueue_scripts フックで条件分岐させる設定を行いました。）
プログラムの読み込みを「後回し」にする
プログラムは、読み込みが終わるまで表示をせき止めます。そこで、ページを描いたあとに実行する設定に切り替えました。
ただし、すべてを後回しにはできず、ページによって設定を切り分けました。
- 通常のページ … 後回しにする
- お問い合わせページ … これまで通り先に読み込む
こうすることで、速度とフォームの動作を両立できます。なお、プログラムを止めたページでエラーが出ないようにする追記も行いました。
一番効果的だったのはGoogle Fonts
ここまでの対応で、パソコンでの表示はかなり改善しました。ところがスマートフォンだけが重いまま残りました。
調べてみると、原因はトップページの大きな見出しでした。ここに Google Fontsから日本語のWebフォントを読み込んでおり、「メインコンテンツの表示時間（LCP）」として計測されていたのが、この見出しでした（フォントが届くまで、表示が確定しない状態になっていました。）。
日本語のフォントは収録している文字数が多く、Google Fontsで配信されているものでも1書体で1MB近くになります。メイン画像は約12KBまで減らしました。その画像80枚分を、見出しの書体ひとつで読み込んでいたことになります。
対応した施策
- Google Fonts から読み込んでいたフォントを、自社サーバー内に置いて読み込む方式に変更
- 使用する太さを3種類だけに限定（それ以外は削除）
- サイトで実際に表示される文字だけを残す「サブセット化」を実施
- フォントが届くまでは、代わりの書体で先に文字を表示する設定に変更
改善の結果｜LCP 33.9秒 → 8.8秒
ここまでの対応を反映した結果です。モバイル（SP）での計測を、改善前後で比較しました。
| 指標 | SP 改善前 | SP 改善後 | PC 改善前 | PC 改善後 |
|---|---|---|---|---|
| パフォーマンススコア | 55 | 66 | 86 | 92 |
| First Contentful Paint | 17.4秒 | 2.9秒 | 1.3秒 | 0.7秒 |
| Largest Contentful Paint | 33.9秒 | 8.8秒 | 2.1秒 | 1.8秒 |
| Speed Index | 17.4秒 | 4.7秒 | 1.3秒 | 1.0秒 |
| Total Blocking Time | 20ms | 160ms | 80ms | 50ms |
| Cumulative Layout Shift | 0 | 0.005 | 0.004 | 0.005 |
特に大きいのは、最初に何かが表示されるまでの時間（FCP）が17.4秒から2.9秒になったことです。真っ白な画面を見ている時間が、6分の1になりました。
TBT が増えているのはなぜか
表を見ると、スマートフォンの「操作できない時間（TBT）」だけが20ミリ秒から160ミリ秒に増えています。これは、プログラムの実行を表示のあとに回したことで、処理のタイミングが後ろにずれたためです。
とはいえ、どちらも「良好」の目安である200ミリ秒未満に収まっています。表示を17.4秒早める代わりに、0.14秒を引き受けており、体感は明確に良くなります。
まとめ｜速度より先に決めるべきこと
ここまで、原因の見つけ方から具体的な設定までをご紹介してきました。最後に、実際に着手するときの考え方を整理します。
- 施策を選ぶ前に、計測結果の「診断」欄を読む。原因の順番を間違えると効果が出ない
- 今回の最大の原因は画像ではなく、表示をせき止めていた処理と日本語のWebフォントだった
- 画像は「軽くする」より先に、表示サイズに合わせて出し分ける
- 遅延読み込みは、最初に見える画像を除外しないと逆効果になる
- 画像に幅と高さを書けば、読み込み中のレイアウトのズレは防げる
- 結果：メイン画像の表示まで33.9秒 → 8.8秒（約74%短縮）、最初の表示は17.4秒 → 2.9秒
弊社では、ホームページの無料相談を行っています。表示速度の改善はもちろん、これからホームページを制作したい方、自社で運営しているホームページをリニューアルしたい方、情報収集だけでも結構ですので、お気軽にご相談くださいませ。
" alt="椎木 航">
