サイト表示速度の改善

ホームページが遅いと指摘されたときは、何の時間を、どのURLで測ったのかを確認することから始めます。
画像を軽くする、キャッシュを使うといった対策を一度に入れると、どの変更が効いたのか、何が原因で不具合が出たのかを追いにくくなります。

この記事では、アセントウェブで2026年10月に確認した画像6点の容量と修正記録を使い、測定、原因の切り分け、変更後の確認を順に説明します。
ここで示す容量の削減率は画像ファイルの比較です。ページ全体の表示時間や問い合わせ数の改善率を示すものではありません。

遅いと言われた指標と対象URLを確認する

サーバーの応答と、画面の表示は別の時間

ページは、サーバーから情報を受け取り、画像や文字などを読み込んで表示します。
最初の応答が早くても、大きな画像や重い処理が残っていれば、必要な内容が見えるまで待つことがあります。

GoogleのCore Web Vitalsは、LCP・INP・CLSを使って読み込み、操作への反応、表示の安定性を評価します。
良好の目安はLCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下で、実際の利用データの75パーセンタイルを端末別に見る考え方です。GoogleのWeb Vitals解説

Ahrefsの監査にある読み込み時間や「遅いページ」という分類を、この三つの評価と同じものとして扱わないでください。
使用したツール、対象URL、指標名を残して、同じ種類の数字を比較します。

実際の利用データと、試験環境の測定を分ける

PageSpeed Insightsには、実際の利用状況をまとめたフィールドデータと、Lighthouseによる試験環境のデータがあります。
前者は過去28日間の利用状況で、ページ単位のデータが足りない場合には、サイトのオリジン単位の情報になることや、表示されないことがあります。PageSpeed Insightsの公式説明

ページを直してすぐ、過去28日間の評価がすべて入れ替わるわけではありません。
直後は同じ試験条件で変更の影響を調べ、利用データは対象期間を見ながら追う、という役割分担にします。

改善前の状態を、同じ条件で記録する

トップページだけで判断しない

商品やサービスのページ、画像の多い記事、問い合わせフォームなどでは、読み込む内容が異なります。
最初に確認するURLを決め、ページごとに記録してください。

スマートフォンとパソコン、ログイン中とログアウト状態、初回表示と再訪では条件が変わります。
一般の訪問者の状態を調べるときは、管理画面にログインしている自分の表示だけで結論を出さないようにします。

試験は一回の点数だけで判断せず、複数回のばらつきも残します。
大きな差が出る場合は、条件が変わっていないか、特定の時間帯だけ遅いのかを確認します。

自社の記録でも、条件の違う数字をつながない

2026年10月15日のAhrefs監査で遅いとされた4ページについて、翌16日の確認記録では、各URLを3回測ったTTFBが0.213〜0.289秒でした。
ただし、Ahrefsのクロールと同じ場所・同じ回線・同じキャッシュ条件で測った比較ではありません。

そのため、「約1秒から0.2秒へ改善した」とは判断していません。
この確認で言えるのは、当時の測定環境でその応答時間が記録されたことまでです。スマートフォンでの描画やCore Web Vitalsを測定した結果とは分けて扱います。

容量の大きい画像は、実際に配信するファイルまで確認する

自社で確認した6画像の容量比較

自社サイトの監査では、PNG画像6点が大きい画像として挙がりました。
対応時には画質を確認してJPEGへ変換し、ページ内の参照先を更新しています。次の値は、2026年10月15日の監査CSVと、16日の修正後取得記録を照合したものです。

6ファイルの合計は約82.87％小さくなりました。
計算は「1 − 変更後の合計 ÷ 変更前の合計」です。6点が同じ一つのページですべて使われているという意味ではなく、ページ全体の転送量が82.87％減ったという主張でもありません。

対応記録では、既存のWebPファイルも合計約778万バイトありました。
形式名だけで軽くなったと判断せず、今回実際に容量が小さくなったJPEGを使用しています。新しいWebPが配信されたことは、この対応の完了条件にしていません。

表示寸法、画質、読み込まれるサイズを確かめる

大きな元画像を小さな枠で表示していても、元の大きいファイルを読み込んでいれば転送量は減りません。
ページ上の見え方に合った画像サイズを用意し、端末に応じて適切な画像が選ばれているかを確認します。

写真、ロゴ、文字を含む図、透明な画像では、適した形式や圧縮の強さが異なります。
容量だけを優先して、商品やサービスの判断に必要な細部を失わないようにしてください。

代替テキストは、画像の意味を伝えるために設定します。
速度改善のためにキーワードを詰め込む欄ではなく、画像を差し替えた後も内容に合っているかを確認します。

画像を軽くしても遅い場合は、残る工程を調べる

最初に見せる画像まで、一律に遅延させない

画面外の画像を必要に応じて読み込む方法はありますが、最初の画面で大きく表示する画像まで同じ扱いにすると、表示開始を遅らせることがあります。
GoogleのLCP改善資料でも、LCPの対象画像に遅延読み込みを適用しないことや、読み込み開始までの遅れを確認することが説明されています。LCPの改善方法

「すべての画像を遅延読み込みする」といった一律の設定にせず、最初に表示する要素と、後から表示する要素を分けて確認します。

スクリプト、フォント、サーバーは症状に合わせて調べる

プラグインや外部タグを削除する前に、何のために使われているか確認します。
フォーム、計測、予約、決済などの機能を担っているものを、件数を減らす目的だけで止めないでください。

キャッシュ設定も、更新内容が反映されるか、利用者ごとの情報が正しく扱われるかを含めて検証します。
ログイン後の画面やカートなどがあるサイトでは、公開ページと同じ設定を機械的に適用しないようにします。

改善後は、数字と機能の両方を確認する

同じ条件で測り、変更を採用するか決める

変更前と同じURL・端末設定・測定方法で確認し、指標がどう変わったかを残します。
改善した数字だけを選ばず、変わらなかった項目や悪くなった項目も記録してください。

フォームの送信や予約など、通知・データ登録が生じる確認は、テストであることを関係者に共有して行います。
この表は読者が使う確認票です。今回、すべての機能でテスト送信を実行したという記録ではありません。

戻す方法を用意してから変更する

元画像や変更前の設定を残し、一つの変更ごとに確認します。
問題が出たときに戻せる範囲を決めておくと、原因を追いやすくなります。

更新の手順や継続的な管理も見直す場合は、Webサイト保守・運用の支援範囲もご確認ください。

よくある質問

PageSpeed Insightsは100点にすべきですか

点数だけを唯一の目標にする必要はありません。
実際の利用データ、どの要素が待ち時間を生んでいるか、必要な機能が正常に動くかを合わせて判断します。試験環境の点数が高くても、すべての訪問者の体験が保証されるわけではありません。

画像をWebPにすれば速くなりますか

形式の変更だけで判断できません。
画像の内容、寸法、圧縮設定、実際に配信されるファイルを確認します。自社の対応例でも、既存WebPより軽いJPEGを採用しており、実容量と画質を見て選んでいます。

速度を改善すれば検索順位も上がりますか

この記事の画像容量比較だけでは、検索順位への影響は判断できません。
検索意図に合う内容や使いやすさも含めて改善し、公開後の検索データは別に確認する必要があります。

まとめ：測る条件と、変更する箇所をそろえる

表示速度の改善は、指標とURLを確認し、変更前を記録してから進めます。
画像は形式名だけで判断せず、実際の容量・画質・配信先を確認し、残る遅延は工程ごとに切り分けます。

今回の自社記録で確認できたのは、6画像の合計容量が約82.87％減ったことです。
これをページの表示時間や事業成果の改善率に置き換えず、同条件の速度測定と機能確認を次の作業として残すことが大切です。