ブログの表示速度を調べたらLCP93.7秒だった|PageSpeed Insightsで分かった原因

ブログ運営

ブログの表示速度を調べたらLCP93.7秒だった|PageSpeed Insightsで分かった原因

「そういえば、自分のブログってどれくらい表示が速いんだろう?」

ふと気になって、PageSpeed Insightsでチェックしてみました。結果を見て、正直かなり驚きました。LCP(最大コンテンツの描画時間)が93.7秒。数値を見間違えたかと思って何度も見返しましたが、間違いではありませんでした。

この記事では、実際にPageSpeed Insightsで診断してみて分かった原因と、現状の数字をそのまま公開します。まだ改善作業はしていない、診断だけの段階の記事です。


この記事でわかること

  • PageSpeed Insightsで実際に出た数値
  • LCPが遅くなっている原因(診断結果)
  • TBT・CLSは良好という意外な結果
  • 今後どう改善していくつもりか

そもそも、なぜ表示速度が重要なのか

正直に言うと、これまで表示速度はあまり気にしていませんでした。記事の中身さえ良ければ読んでもらえると思っていたからです。ただ調べてみると、表示速度は主に2つの理由で軽視できないポイントだと分かりました。

1つ目は、読者の離脱です。ページの表示に時間がかかるほど、読者は開いた瞬間に別のページへ戻ってしまいます。せっかく検索結果に表示されても、開いた0〜数秒で読まれずに離脱されてしまえば、書いた記事は誰にも届きません。

2つ目は、検索順位への影響です。GoogleはLCPをはじめとする表示速度の指標(Core Web Vitals)を評価基準の一つに含めています。以前の引き継ぎメモでも「平均掲載順位30位前後」という数字が続いていましたが、内部リンクやタイトルの改善だけでなく、表示速度もその一因になっている可能性があります。

そう考えると、今回LCP93.7秒という数字を目にしたのは、むしろ「順位が伸び悩んでいた理由の一つが見つかった」という前向きな発見でもありました。


結論:原因は「ページが重すぎる」ことだった

先に結論から言うと、LCPが遅い理由は複雑な話ではありませんでした。ページ全体のデータ量が約24MBもあり、単純に「重すぎる」ことが主な原因でした。

操作の遅延やレイアウトのガタつきといった問題ではなく、画像や不要なCSS・JavaScriptが読み込まれ続けていることで、表示が完了するまでに時間がかかっている状態です。


PageSpeed Insightsで出た実際の数値

トップページをモバイル環境で診断した結果がこちらです。

指標 数値 評価
パフォーマンススコア 54点 要改善
First Contentful Paint(FCP) 5.6秒 悪い
Largest Contentful Paint(LCP) 93.7秒 非常に悪い
Speed Index 30.6秒 悪い
Total Blocking Time(TBT) 160ミリ秒 良好
Cumulative Layout Shift(CLS) 0 良好

数字だけ見ると絶望的に思えるかもしれませんが、実はここに重要なヒントがあります。TBTとCLSは良好なんです。つまり、ユーザーが操作しにくい・画面がガタつくといった問題は起きていません。純粋に「表示が完了するまで時間がかかる」というタイプの遅さでした。


診断で指摘された原因一覧

「診断」欄で指摘された項目をそのまま並べてみます。

指摘項目 内容
過大なネットワークペイロードの回避 合計サイズ 24,607 KiB(約24MB)
使用していないJavaScriptの削除 推定削減サイズ 425 KiB
使用していないCSSの削除 推定削減サイズ 111 KiB
CSSの最小化 推定削減サイズ 9 KiB
画像要素にwidth/heightが未指定 レイアウト計算に影響
メインスレッドの長時間タスク 長時間実行タスクが7件

正直、一番衝撃だったのは合計サイズが24MBを超えていたことです。普段スマホで写真を撮ってそのままアップロードすることが多く、画像の圧縮を意識していませんでした。それが積み重なって、ページ全体がとても重くなっていたようです。


原因として考えられること

① 画像を圧縮せずそのままアップロードしている

アイキャッチ画像や本文中の画像は、スマホで撮影・スクリーンショットしたものをそのままアップロードしていました。1枚あたりのファイルサイズが大きく、これが24MBという合計サイズにつながっていると考えられます。

② テーマ・プラグインの未使用CSS/JSが多い

Cocoon Childテーマや導入しているプラグインには便利な機能が多く入っていますが、その分すべてのページで使わない機能のCSS・JavaScriptまで読み込まれている可能性があります。未使用CSSが111KiB、未使用JavaScriptが425KiBという数字は、この仮説を裏付けています。

③ 画像にサイズ指定がされていない

width・heightを指定しないまま画像を挿入すると、ブラウザが画像のサイズを都度計算する必要があり、表示完了までの時間に影響します。Classic Editorでコードをそのまま貼り付けている都合上、この設定を意識できていませんでした。

診断結果を見ながら、友人にこの話をしたときのやり取りです。

まさかLCPが93秒って、逆に見たことないレベルだね。何それ怖い。
私も二度見したよ…。でも原因を見たら、画像を圧縮せずそのまま上げてたのが一番大きそうで、正直「あ、そりゃそうか」って納得しちゃった。
スマホで撮った写真そのままだと、数MBあることも普通にあるもんね。それが積み重なったら24MBも納得かも。
うん。中身を書くことばかり気にしてたけど、土台の部分がここまで手薄だったとは思わなかった。

TBT・CLSが良好だったのは意外だった

正直、ここまで数字が悪いと全部がダメなのかと思っていましたが、TBT(操作までの遅延)とCLS(レイアウトのズレ)は良好という結果でした。

つまり、サイトの作り自体が悪いわけではなく、「読み込むファイルの量」を減らせば改善の余地が大きいということが分かりました。原因がはっきりしただけでも、次にやるべきことが見えてきた気がします。


今後の改善方針

今回はまだ診断だけで、改善作業はこれからです。今のところ考えている方向性はこの3つです。

  • 画像を圧縮してからアップロードする(またはプラグインで自動圧縮する)
  • 使っていないプラグイン・機能を見直し、不要なCSS/JSを減らす
  • 画像にwidth・heightを指定する

実際に改善作業をしたら、Before/Afterの数値を比較した記事を別途書く予定です。今回はまず「現状を正直に把握する」ことを目的にまとめました。


まとめ|まずは現状を知ることから

ブログの表示速度は、正直これまであまり意識してきませんでした。今回PageSpeed Insightsで診断してみて、パフォーマンス54点・LCP93.7秒という数字を目の当たりにし、かなり驚きました。

ただ、原因を分解してみると「画像の重さ」「未使用CSS/JS」「サイズ未指定」という具体的なポイントが見えてきました。数字だけ見ると絶望的でも、原因が分かれば対処のしようがあります。

次は実際に改善作業に取り組み、その結果を正直に公開したいと思います。


関連記事

コメント