NitroPackの最適化が“時々失敗”するなら、WordPress の Warning を潰せ！

2025年10月2日 最終更新日時 : 2025年10月17日 nissy
  • 「NitroPack の Page optimization がスポットで failed する」場合、WordPress 側の Warning/Notice が出力に混入 → ヘッダー送出失敗・空応答・REST 壊れ、にありました。
  • /wp-content/debug.logを見ながら修正すると、あきらかにfailedがに減りました。

Cloudflare Cache Rulesでキャッシュヒット率を大きく向上させる前に、キャッシュヒット時のコンテンツ品質確保をしないと、真っ白画面そのものをCloudflareにキャッシュさせてしまうことになるため、重要な作業となります。

Information

NitroPackプラグイン：バージョン 1.18.5

なぜ Warning でPage optimizationの赤●failedが増えるのか

NitroPack はページ最適化時に下記の前提が崩れると x-nitro-disabled: 1 や failed に転びます。

  1. ヘッダー送出前に何かが出力された
    　Warning/Notice が画面に混ざる → Headers already sent → Cache-Control や内部判定が壊れる。
  2. 一瞬でも“空HTML/異常応答”になった
    　条件分岐のズレ・PHP Warning連鎖で 404/500/空応答 → そのジョブは failed。
  3. REST 応答が壊れた
    　/wp-json/… の JSON 先頭に Warning 文字列 → Nitro の内部呼び出しが decode 失敗。
  4. キャッシュキー分散やリダイレクト誤発火
    　Notice 由来の分岐遅延で Vary・ルーティングが揺れ、Warmup が “ミスマッチ”。

調査向け2アクション

画面にWarningを出さず、ログだけに残す定番のコードを wp-config.php に記載。ログからデバッグ作業に入ります。まず、試験環境から行うことを強く推奨します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

NitroPack のヘッダーで失敗の型を掴む

curl -I "https://example.com/path"
# x-nitro-disabled: 1
# x-nitro-disabled-reason: search / 404 / error / cookie など

2025/10/2に対応した Warning と対処

1) foreach() argument must be of type array|object, null given

NitroPackプラグインが オプション値を配列想定で回しているのに、実体は null。
→ pre_option フィルターで配列既定値を強制（アップデート耐性◎）


add_filter('pre_option_ajaxShortcodes', function ($v) {
  if (is_array($v)) {
    if (!isset($v['enabled']))    $v['enabled'] = false;
    if (!isset($v['shortcodes']) || !is_array($v['shortcodes'])) $v['shortcodes'] = [];
    return $v;
  }
  return ['enabled'=>false, 'shortcodes'=>[]];
});

add_filter('pre_option_wc_aelia_currency_switcher', function ($v) {
  if (is_array($v)) {
    if (!array_key_exists('ipgeolocation_enabled', $v)) $v['ipgeolocation_enabled'] = null;
    return $v;
  }
  return ['ipgeolocation_enabled'=>null];
});

2) Attempt to read property "taxonomy" on null

タクソノミークエリの確定前に get_queried_object()->taxonomy を触る。
→ “無害な保険”で未確定なら触らない（副作用を避けるため状態は上書きしない）

add_action('parse_query', function (WP_Query $q) {
  if (is_admin() || !$q->is_main_query()) return;
  if ($q->is_tax() || $q->is_category() || $q->is_tag()) {
    $qo = get_queried_object();
    if (empty($qo) || !is_object($qo) || !property_exists($qo, 'taxonomy')) return;
  }
}, 0);

点検→修正→再計測のミニ手順

  1. ログを時系列で確認
    • /wp-content/debug.log を grep（Warning を抽出）。対策実装前後の最新日時分秒でWarninig消えを確認する。
  2. 同時刻にアクセスした URL を再現
    • 404/プレビュー/検索/カテゴリページなど、失敗が出やすいURLを叩く
    • 例：
      • curl -I "https://example.com/?s=test"（検索系）
      • curl -I "https://example.com/wp-json/"（REST）
      • curl -I "https://example.com/this-should-404"（404系）
  3. NitroPack ヘッダーと Cloudflare の状態を確認
    • x-nitro-disabled(-reason) / cf-cache-status を確認
  4. Warning を潰す（上のコードを追加）
    • 保守用プラグインを作り、まとめて実装すると管理しやすいです。NitroPackプラグインのgithubのURLはおそらく非公開なので、カスタマーチャットで、ボットではなく中の人に聞くのも有用。
  5. 同じ URL を再度計測
    • NitroPack の Page optimizationでfailedが消える、またはfailed頻度が目に見えて下がれば成功

まとめ

  • NitroPack の Page optimizationのスポットfailed は、WordPress 側の Warning を潰すだけで顕著に減る可能性あり。
  • 「出力は/wp-content/debug.logだけ・配列既定値の強制・未確定タクソノミーに触らない」の三点でまず安定化。

そのうえで Warmup/Preload、Cloudflare Cache Rules の最適化を積み上げると、Edge問わず安定したヒットに繋がります。

追記

failedする場合、以下フォルダの配下にあるキャッシュフォルダをフォルダ丸ごと削除すると、きれいにcompletedになります。

※同フォルダ配下に、.htaccess、notifications.jsonが有るためこれらは削除しないほうが賢明です。

/wp-content/cache/*******-nitropack/
カテゴリー
CoreWebVitals
タグ