ホームページが重い原因は画像の書き出し設定｜見た目を変えずに容量を落とす手順

「ホームページの表示が遅い」「スマホで開くとなかなか画像が出ない」という相談を受けてサイトを調べると、原因のほとんどは画像です。それも「圧縮していないから」という単純な話ではなく、デザインツールから書き出したときの設定がそのまま残っているという、もっと上流の原因であることが目立ちます。

先に結論をお伝えします。重いサイトを軽くする正しい順番は、「測る → ファイル名を変えずにリサイズと圧縮 → それでも足りないページだけ形式変換」です。graciautoが改善を担当したあるクリニックのサイトでは、この順番で1ページ23.73MBあったページを1.03MB（96%減）まで落としました。見た目は一切変えていません。この記事では、その実測データをもとに、測り方から作業の順番、途中で起こりうる事故の防ぎ方までを解説します。

—

重いサイトで実際に起きていたこと

まず、どれくらい重いと問題なのかの目安です。一般に1ページの合計容量は2MB以内、写真の多いページでも3MB程度に収めたいところです。冒頭のクリニックサイトは主要ページが軒並みこの基準を大きく超えていました。

ページ	改善前	改善後
診療案内ページ	23.73MB	1.03MB
トップページ	18.65MB	1.99MB
サービス紹介ページ	13.48MB	1.20MB

調査して分かった原因は、大きく2つに集約されました。

1つ目は、デザインツール（Figma）の「3倍書き出し」がそのまま設置されていたこと。 Figmaにはスマホの高精細画面向けに2倍・3倍サイズで画像を書き出す機能があり、デザイナーからの納品データは3倍書き出しになっていることがよくあります。このサイトでは、実際の表示幅が1345pxのメイン画像に対して、5379px・7.69MBの画像がそのまま置かれていました。表示に必要なサイズの4倍です。

2つ目は、写真がPNG形式のまま設置されていたこと。 PNGはロゴや図版には向いていますが、写真に使うとJPEGの数倍の容量になります。このサイトでは写真416枚が透過情報付きのPNGのままで、合計122.6MBに達していました。

集計すると、サイト内で参照されている画像486枚のうち388枚（115MB分）が、実際の表示サイズの2倍を超える解像度でした。つまり容量の大部分は「表示に使われていないピクセル」だったわけです。

これは特殊な例ではありません。美容室やサロンのサイトでも、デザインデータからの書き出しをそのまま使っていれば同じ構図になります。制作時にきれいに見えることを優先すると、容量は後回しになりがちだからです。

手順1：圧縮の前に「実解像度×実表示サイズ」を突き合わせる

最初にやるべきは圧縮ではなく計測です。画像ごとに「ファイルの実解像度」と「画面上の実表示サイズ」を並べた一覧表を作ります。

ここで大事なのは、実表示サイズを推測ではなく実測することです。CSSの指定を目で追って「たぶんこの幅だろう」と判断すると、レイアウトの入れ子や最大幅の指定を見落とします。ブラウザの開発者ツールで実際の描画幅を確認するか、ページを機械的に開いて測定します。PC表示ではコンテンツ領域の固定幅、スマホ表示では画面幅に対する最大幅を先に確認しておくと、判定がぶれません。

判定基準はシンプルで、実表示サイズの2倍を超える解像度は過剰です（高精細画面対応として2倍までは意味があります)。この表を作ると「どのファイルを、どこまで縮めてよいか」が数字で確定し、以降の作業が迷いなく進みます。逆にこの表を作らずに圧縮ツールへ一括投入すると、縮めすぎて画質が落ちたり、縮め足りずに効果が出なかったりと、やり直しが発生します。

手順2：ファイル名を変えない最適化から当てる

計測が済んだら最適化ですが、リスクの低い施策から順に当てるのが原則です。最初にやるのは次の3点で、いずれもファイル名と拡張子が変わりません。

• 実表示サイズの2倍を上限にリサイズする
• PNGは減色・最適化をかける
• JPEGは品質85で再圧縮する

拡張子が変わらないということは、HTMLやCSSの画像参照を1箇所も書き換えなくてよいということです。 参照の書き換えが発生しなければ、書き換え漏れによるリンク切れ（画像が表示されない事故）が構造的に起こりません。先ほどのサイトでは、この段階だけで画像全体が128MBから73MBまで下がりました。

ここでもう一度計測し、目標に届いたかを実データで判定します。届いていればここで終了です。ページ数が少なく写真も軽いサイトなら、この段階で十分なことも多いです。

手順3：足りないページだけWebP化する

拡張子を変えない最適化だけでは届かないページに限って、WebP形式への変換を行います。WebPはJPEGやPNGより圧縮効率が高い形式ですが、拡張子が変わるため、HTML・CSS内の参照をすべて書き換える必要があります。先ほどのサイトでは291枚を変換し、書き換え箇所は26ファイル・756箇所に及びました。リスクが一段上がるので、全ファイルではなく未達のページに限定するのが判断基準です。この段階まで実施して、画像全体は最終的に9.2MBまで下がりました。

WebP変換で1つ実務的なポイントがあります。すべての画像を同じ品質設定で変換しないことです。写真は品質85の非可逆圧縮で問題ありませんが、料金表や地図、文字の入った図版に同じ設定を使うと、文字のフチがにじむことがあります。色数を数えて、512色以下のフラットな図版は劣化ゼロの可逆圧縮、写真は品質85と自動で振り分けると、文字がにじむリスクを仕組みごと消せます。なお「可逆・非可逆の両方で圧縮して小さい方を採る」という方法は一見丁寧ですが、大きな写真の可逆圧縮は処理が終わらないほど遅く、実用になりません。色数で先に振り分けるのが現実的です。

起こりうる事故と、その予防策

この作業には定番の落とし穴がいくつかあります。あらかじめ知っていれば防げるものばかりです。

参照の書き換え漏れ。 WebP化で拡張子を書き換える際、プログラムが変数でファイル名を組み立てている箇所（image_${名前}.png のような書き方）は、単純な文字列置換では検出できません。置換作業のあとに旧拡張子がコード内に残っていないかを全文検索する工程を必ず入れます。置換した箇所数ではなく、残っていないことを確認するのがポイントです。

気づかない画質劣化。 圧縮後の見た目チェックを目視だけに頼ると、微妙な劣化や表示崩れを見落とします。改善前のページと改善後のページを同じ条件でスクリーンショットに撮り、ピクセル単位で差分を数値化すると客観的に判定できます。先ほどのサイトでは平均差が255段階中0.18〜1.00に収まっており、「見た目は変わっていない」を数字で確認してから公開しました。

元画像の消失。 最適化は上書き作業になるため、作業前に元画像一式をバックアップし、ファイルが完全に一致していることを確認してから始めます。圧縮しすぎた画像だけ後から差し替えたい、という場面は実際に発生します。

サイト側を軽くしても終わらないケース：CMSの画像

もう1つ、見落とされやすい構造的な問題があります。サイト本体の画像をすべて最適化しても、CMS（WordPressなど）にアップロードされた画像は別管理だということです。

先ほどのサイトでも、本体の画像を最適化した後にトップページだけ容量が下がりきらない現象がありました。調べると、重い画像の上位はすべてWordPressの記事アイキャッチで、1枚449KBの未圧縮PNGがアップロードされていました。トップページは最新記事のアイキャッチを並べる作りだったため、運用側が重い画像をアップロードするたびにトップページが重くなる構造だったわけです。

この構造は一度の最適化作業では解決しません。対策は、アップロード時に自動で画像を圧縮する仕組みをCMS側に入れるか、サイト生成時にアイキャッチも最適化の対象に含めるかのどちらかです。制作会社に改善を依頼する場合も、「今ある画像を軽くする」だけでなく「今後アップロードされる画像はどうなるのか」まで確認しておくと、数ヶ月後に元に戻る事態を防げます。

まとめ：測ってから、リスクの低い順に

ホームページが重いときの対処を整理します。

1. 推測で圧縮を始めず、実解像度と実表示サイズの突き合わせ表を作る（原因の大半は「表示に使われていないピクセル」）
2. ファイル名の変わらないリサイズ・再圧縮から当てる（参照書き換えが不要＝事故が起こらない）
3. 届かないページだけWebP化する（図版は可逆・写真は品質85で振り分け）
4. 置換漏れの全文検索・ピクセル差分・バックアップで事故を予防する
5. CMSにアップロードされる画像の対策まで含めて設計する（ここを外すと徐々に元に戻る)

表示速度はSEOの評価要素であると同時に、スマホで開いた瞬間に「待たされるか、すぐ見えるか」というユーザー体験そのものです。プラグインやサーバーの変更を検討する前に、まず画像の実態を測ってみてください。数字を見れば、どこから手を付けるべきかは自然に決まります。