Hummingbird で最適化を有効にした後に画像が表示されなくなった場合、原因はたいてい「遅延読み込みのスクリプトが遅延・結合されて動いていない」「CSS の結合や縮小で背景画像のパスが壊れた」「ページキャッシュが削除済みの最適化ファイルを参照している」のいずれかです。この記事では、開発者ツールで原因の種類を見分け、Hummingbird の管理画面で該当する設定だけを戻して、速度を保ったまま画像を表示させる手順を説明します。
まず画像の消え方を確認する
最初に、どの画像がどのように消えているかを確認します。シークレットウィンドウ（ログアウト状態）でページを開き、ブラウザの開発者ツールを使って次の点を見てください。
<img>タグで入れた画像が消えているのか、CSS の背景画像（スライダーの背景、見出しの装飾など）が消えているのか- 画像の場所に空白があるのか、レイアウトごと崩れているのか
- スクロールやクリックをすると遅れて表示されるのか、いつまでも表示されないのか
- ログイン中の管理者には正常に見えるのか
開発者ツールのネットワークタブで画像の読み込みを絞り込むと、さらに切り分けが進みます。画像が 404 になっていればパスの問題、そもそもリクエストが発生していなければ表示を担当するスクリプトが動いていない、と判断できます。要素タブで <img> を確認し、src が仮の画像のままで本来の URL が data-src などの別の属性に入っている場合は、遅延読み込みのスクリプトが実行されていません。
作業前の準備
設定を変える前に、サイトのバックアップを取ってください。Hummingbird の設定は管理画面から書き出せる場合があるので、変更前の状態を保存しておくと戻しやすくなります。（2026年10月現在）Hummingbird の画面構成や項目名はバージョンで変わることがあるため、以下では機能の名前を一般的な表現で説明します。
また、管理画面に入れないほど表示が崩れている場合は、FTP やファイルマネージャーで wp-content/plugins/ 内の Hummingbird のフォルダ名を一時的に変更すると、プラグインが停止して元の表示に戻ります。原因が分かったらフォルダ名を戻して、設定を見直してください。
原因1：JavaScript の遅延実行で遅延読み込みが動かない
Hummingbird には、JavaScript の実行をユーザーの操作（スクロールやクリックなど）まで遅らせる機能があります。読み込み速度の指標は改善しますが、画像の遅延読み込み（Lazy Load）を JavaScript で行っている場合、そのスクリプトまで遅れてしまい、操作するまで画像が表示されない、あるいは表示されないままになることがあります。
特に、Smush など別のプラグインやテーマが JavaScript ベースの遅延読み込みを使っている場合に起きやすい組み合わせです。対処は次のいずれかです。
- JavaScript の遅延実行の除外設定に、遅延読み込みのスクリプト（ファイル名やキーワード）を追加する
- 遅延実行をいったん無効にして画像が戻るか確認し、原因を確定させる
- 遅延読み込みを、WordPress 標準の
loading="lazy"属性による方式に切り替える
WordPress は 5.5 以降、画像に loading="lazy" 属性を自動で付けるようになっており、この方式は JavaScript を使わずブラウザが処理します。テーマやプラグイン側で JavaScript の遅延読み込みを使わない設定にできるなら、遅延実行との衝突を避けられます。
原因2：CSS の結合・縮小で背景画像のパスが壊れる
Hummingbird のアセット最適化で CSS の結合や縮小を行うと、元の CSS ファイルは別の場所（最適化ファイルの保存先）に作り直されて配信されます。元の CSS の中で背景画像を url(../images/bg.png) のような相対パスで指定していると、配置場所が変わったことで画像の参照先がずれ、404 になることがあります。プラグイン側で URL の書き換えは行われますが、テーマやプラグインの書き方によってはうまく変換されない場合があります。
ネットワークタブで背景画像が 404 になっているなら、この原因が疑わしいといえます。対処の手順は次のとおりです。
- アセット最適化の画面で、問題の画像を指定している CSS ファイル（テーマやスライダーのプラグインのもの）を探す
- そのファイルだけ結合や縮小の対象から外す
- 最適化ファイルのキャッシュを削除し、ページキャッシュも削除して再確認する
どのファイルか分からない場合は、自動の最適化モードから手動の設定に切り替え、ファイルごとに設定を戻していくと特定できます。手動の設定画面では、ファイル単位で縮小・結合・フッターへの移動・遅延などを選べます。
原因3：重要な CSS の生成や不要な CSS の削除
ページ上部の表示に必要な CSS だけを先に読み込み、残りを後から読み込む機能を使っている場合、生成された CSS にスライダーやギャラリーの表示に必要なスタイルが含まれず、画像が見えない状態になることがあります。後から読み込まれる CSS が適用されるまでの一瞬だけ消える場合も、この機能が関係しています。
この機能を一時的に無効にして画像が戻るなら、原因はここです。生成をやり直すか、問題のページや要素を対象外にする設定があれば利用してください。
原因4：ページキャッシュが古い最適化ファイルを参照している
アセット最適化の設定を変えたり、最適化ファイルのキャッシュを削除したりすると、結合後の CSS や JavaScript のファイルが作り直されます。ところがページキャッシュに保存された HTML は古いファイル名を参照したままなので、存在しないファイルを読み込もうとして CSS が当たらず、画像を含むレイアウトが崩れます。
この症状は、ネットワークタブで CSS や JavaScript のファイルが 404 になっていることで確認できます。アセット最適化の設定を変えたときは、ページキャッシュもあわせて削除する習慣をつけてください。サーバー側のキャッシュや Cloudflare などの CDN でも HTML をキャッシュしている場合は、そちらも削除が必要です。
原因5：CDN や URL の問題
Hummingbird の CDN 機能（有料版で提供される機能）や、外部 CDN を使っている場合、CDN 側で画像やアセットが正しく配信されていないと画像が消えます。CDN を一時的に無効にして直るかを確認してください。
サイトを https に移行した後なら、画像の URL が http のまま残っている混在コンテンツが原因の可能性もあります。開発者ツールのコンソールに混在コンテンツの警告が出ていないかを確認します。
設定を戻すときの考え方
原因の切り分けでは、設定を一度にまとめて戻すのではなく、1つずつ戻しては確認するのが近道です。おすすめの順番は次のとおりです。
- JavaScript の遅延実行を無効にする
- 重要な CSS の生成・不要な CSS の削除を無効にする
- CSS の結合・縮小を無効にする
- CDN を無効にする
変更のたびに最適化ファイルのキャッシュとページキャッシュを削除し、シークレットウィンドウで確認します。原因の機能が分かったら、その機能だけを除外設定で調整し、ほかの最適化は有効なまま残すと、速度を大きく落とさずに済みます。最後に PageSpeed Insights などで速度を確認し、画像の表示と速度の両方に問題がないかを見ておきます。
まとめ
- Hummingbird の最適化後に画像が消えたら、開発者ツールで「404 なのか」「リクエスト自体がないのか」を最初に見分ける
- 遅延読み込みが動かない場合は、JavaScript の遅延実行から遅延読み込みのスクリプトを除外するか、
loading="lazy"方式を検討する - 背景画像が 404 なら、CSS の結合・縮小で相対パスが壊れている可能性があり、該当ファイルを最適化の対象から外す
- アセット最適化の設定を変えたら、ページキャッシュや CDN のキャッシュもあわせて削除する
- 設定変更前にバックアップを取り、機能を1つずつ戻して原因を特定する