自社サイト改善事例：画像転送量とCSSの重複を減らす
このサイトで2026年9月10〜11日に行った改修を、測定条件と数値で紹介します。対象は自社運用のPHPサイトです。軽量化だけでなく、記事が最後まで読めるかを確認する途中で見つかった不具合も書き残します。
Design
- 画面幅とキャッシュなど、比較条件をそろえて変更前を記録する。
- 画像とCSSの転送量を調べ、本文が最後まで表示されることも確認する。
- 公開後も同じ条件で確認し、測定した範囲と未検証の効果を分ける。
転送量の削減率を、そのまま速度や収益の改善率にはしない。
1. 何を直し、何を測ったか
比較記事を読む途中で大きな画像を読み込む構成と、共通CSSを異なるURLで二度参照する構成を見直しました。対象は、このホームページ運用ナビです。WordPressに関する記事を掲載していますが、サイト自体はHTML・CSS・PHPで構成しており、お客様のWordPressサイトを改修した事例ではありません。
最初にサーバー比較・開始費用・テーマ比較の3記事を調べ、既存のWebP画像を表示幅に応じて使うように変更しました。次に他の公開記事へCSSの点検を広げました。元のJPEGはフォールバック用に残し、本文、画像の説明、広告リンクの行き先は維持しています。
今回の指標は、ブラウザが受け取った圧縮後のレスポンス本体のバイト数です。表示時間やサイト全体の通信量とは分けて扱います。例えば画像が90%小さくなっても、ページの表示時間が90%短くなるとは言えません。読み込みの順序や他の通信も関係するためです。
2. 比較3記事の画像はどう変わったか
空のキャッシュを使い、Chromiumで画面幅390px・DPR 1と2、1280px・DPR 1の3条件を確認しました。DPRは画面のCSS上の大きさに対する画素密度の比率です。画像位置までスクロールして読み込み、外部広告・計測通信を遮断し、回線速度の制限は加えていません。計測日は2026年9月10日です。
スマホでは表を横にスクロールできます。単位はB（バイト）、画像1点のレスポンス本体です。
| 記事 | 変更前 | 390px / DPR 1 | 390px / DPR 2・1280px / DPR 1 |
|---|---|---|---|
| サーバー比較 | 271,997 B | 16,286 B（94.0%減） | 29,262 B（89.2%減） |
| 開始費用 | 279,200 B | 15,482 B（94.5%減） | 29,152 B（89.6%減） |
| テーマ比較 | 322,634 B | 18,662 B（94.2%減） | 34,904 B（89.2%減） |
同じ9条件で画像の縦横比と表示寸法を確認しました。画像候補は640px・960px幅です。高DPRのデスクトップなど、ここにない条件まで画質を検証したという意味ではありません。元画像が既に小さいサイトへ、同じ削減率を当てはめることもできません。
3. 44記事で共通CSSの重複を整理
9月11日の追加点検では、公開中の44記事を390pxと1280pxで確認しました。各記事が二つのURLから取得していた共通CSSは、内容のハッシュが一致していました。共通側が出力する参照を残し、個別記事と記事テンプレートに残っていた余分な参照を取り除きました。
全88条件で、この共通CSSは2リクエスト・17,046 Bから1リクエスト・8,523 Bになりました。CSS本体を半分削ったのではなく、同じ内容を二度取得する構成を直した結果です。この記事の画像の表とは対象日・対象ファイルが違うため、削減率同士を足し合わせていません。
確認では本文、リンク、要素の位置・寸法、適用されるスタイルを変更前後で比較しました。43記事は一致を確認し、残る1記事は次の不具合を修復したため、同じ表示の比較ではなく全文の復元確認を行いました。予約公開の9記事は、その時点で404を保つことも確認しています。
4. HTTP 200でも、記事は完成していなかった
契約前チェックリストの記事で、サーバーの応答は200でも、最初の広告案内の途中で本文が止まる問題が見つかりました。共通処理を関数の中から読み込んだとき、広告設定の変数を別の関数から参照できず、処理が中断していたことが原因です。
設定の取得処理を、その設定を利用する関数内で初期化する形に直しました。確認対象には、本文の最終節、2つの広告リンク、関連記事、公開履歴、フッターを含めています。広告をクリックして報酬を発生させる試験ではなく、出力されたリンクとページの構造を確認しました。
この経験から、公開後の点検では「URLが開く」に加えて「重要な内容が最後まで出る」を確認項目にしています。チェック項目を多くする場合も、表示、フォーム、公開制御など役割ごとに分けると、どこまで確認できたかを説明しやすくなります。
5. 自分のサイトで使う確認の順番
- 問題のURLと画面幅を決め、変更前の画面と読み込みを記録する。
- 画像やCSSなど、対象を一つに絞って変更する。
- 同じ条件で転送量、本文末尾、リンク、表示寸法を比較する。
- 戻せる状態で公開し、公開先でも結果を確認する。
- 日時と対象範囲を残し、次の変更と混ぜずに比較する。
通信の見方はChrome公式のNetworkパネルの説明を参照できます（確認日2026年9月12日）。今回の結果は実利用者のLCP・INP、検索順位、問い合わせ数、収益の向上を証明するものではありません。公開用に条件と値を整理した測定結果JSONも用意しました。
自分で点検する場合は表示速度を見直す基本へ。修正を依頼したい場合は、対象URLと気になる症状をまとめて制作・公開サポートの料金目安をご確認ください。既存ページの確認・軽微修正から範囲を相談できます。
自分のサイトで点検するときの記録表の例
表は横にスクロールできます。
| 項目 | 変更前 | 変更後 | 確認した方法 |
|---|---|---|---|
| ページの合計の容量 | （記入） | （記入） | ブラウザの開発者ツールのネットワーク |
| 画像の数と容量 | （記入） | （記入） | 同上 |
| 読み込むCSS・JavaScriptの数 | （記入） | （記入） | 同上 |
| 表示にかかった時間 | （記入） | （記入） | 同じ端末・回線で3回測った平均 |
| 見た目の変化 | — | （記入） | パソコンとスマホで目視 |
表は記入用の例です。この記事の数値は当サイトの結果で、ほかのサイトで同じ効果が出るとは限りません。
よくある質問
どこから手を付ければよいですか？
容量が大きいものから見ると、効果を確かめやすくなります。多くのサイトでは、画像の大きさを見直すのが最初の一歩になります。
CSSを整理したら表示が崩れませんか？
使っていないと思った指定が、別のページで使われていることがあります。整理したら、代表的なページを一通り表示して確認します。
公開日: 2026-09-12
最終更新日: 2026-10-16
追記履歴
- 2026-10-16 自分のサイトで同じ点検を行うときの記録表の例と、よくある質問を追加。
- 2026-09-12 初版公開