連結されたCSSまたはJavaScriptの配信方法に関するトラブルシューティング

この記事では、Jetpack BoostがCSSとJavaScriptの連結ファイルを配信する仕組み、現在使用されている配信方法の確認方法、直接配信とPHP経由のフォールバック配信に関する問題のトラブルシューティングについて説明します。

Jetpack Boost（v3.9.0以降）は、CSSとJavaScriptのファイルを連結・圧縮し、Webサーバーから直接配信することで、WordPressのパフォーマンスを最適化し、読み込み時間を短縮します。

直接配信できない場合は、PHPを使用するフォールバックシステムによって、最適化を続けながらコンテンツへのアクセスを維持します。

使用中の配信方法を確認する方法MD

サイトで現在使用されている配信方法を確認するには、次の手順に従ってください。

1. ブラウザーでWebサイトのページを開きます。
2. ページのソースを表示（右クリック→ページのソースを表示）します。
3. CSSまたはJavaScriptのファイルURLを探します。
   • 次の場所から読み込まれている場合は/wp-content/boost-cache/static/、これらのファイルはすでに直接配信されるようサイトが設定されています。
   • 次の場所から配信されている場合は/_jb_static/、WordPressが配信を処理しています。PHPがこれらのファイルを処理するため、リクエストが少し遅くなることがあります。複数のファイルを1つに連結することには依然としてメリットがありますが、サイトで直接配信が機能していない理由を確認するとよいでしょう。

カスタムパーマリンクとファイルの再生成MD

Jetpack Boostは、これらの連結ファイルを再生成するためにWordPressのカスタムパーマリンクシステムを利用します。ファイルが見つからない場合、WordPressが問題を検出し、Jetpack Boostで再生成処理を開始します。プラグインは、WordPressがwp-contentディレクトリ内に不足しているファイルがないか定期的に確認します。この確認に失敗すると、ファイルは/_jb_static/メソッドを介してPHPで配信されます。

手動テストMD

サイトで/_jb_static/を使用して連結されたファイルを配信している場合、存在しないURLにアクセスして手動テストを実行できます。次の/wp-contentディレクトリ内で、URLはプラグインが使用するファイルのように見えるはずです。例えば/wp-content/boost-cache/static/1234.css。WordPressの404エラーページを探してください。代わりに標準的なウェブサーバーの404エラーが表示される場合は、解決が必要な問題があることを示しています。

自動404テストはいつ実行されますか？MD

両方の連結モジュール（JSとCSS）が無効になっている状態で、いずれか一方を有効にすると、プラグインが確認を実行します。また、1日1回実行されます。これにより、サイトのファイル配信を継続的に監視できます。

自動404テストはWordPress.comまたはPressableでは実行されません。これらのホストでは、Jetpack Boostは常にPHPによる/_jb_static/配信方式を使用します。ウェブサーバーは、存在しないwp-contentファイルについて、WordPressが読み込まれる前に404を返す可能性があるためです。WordPressは404を認識しないため、その環境ではテストによる信頼できる結果を得られません。

wp-contentに関する問題を解決する方法MD

この問題は、カスタムパーマリンクに関連する基盤のWebサーバー設定が原因である可能性があります。

Apacheでの修正

Apacheサーバーではmod_rewriteルールがこれを管理していますが、wp-contentディレクトリで無効になっている可能性があります。.htaccessディレクトリ内にある非表示のwp-contentファイルを確認してください。存在する場合は、次のディレクティブを探します。

RewriteEngine Off

この行を削除するかコメントアウトすると、問題が解決することがあります。これらの設定に詳しくない場合は、ホスティングプロバイダーに問い合わせてサポートを受けてください。

.htaccessファイルがwp-contentディレクトリにない場合、ホスティングプロバイダーによって、このプラグインが依存するWebサーバー設定が無効にされている可能性があります。その場合、プラグインはWordPressの手法に切り替えて、連結されたCSSまたはJavaScriptを配信します。少し遅くなりますが、サイトにとっては依然として有益です。

Apache以外のサーバーでの修正

NginxなどApache以外のサーバーの場合は、サーバーのドキュメントを参照するか、ホスティングプロバイダーに問い合わせて、/etc/nginx/内の設定ファイルを変更する方法を確認してください。

開発者向けオプション：404テストを無効にするMD

次のセクションは開発者向けです。これらのオプションを誤って変更すると、サイトのCSSとJavaScriptの配信に問題が発生する可能性があります。不明な場合は、変更する前にホスティングプロバイダーに問い合わせてください。

is_404()テストを無効にするには、定数JETPACK_BOOST_DISABLE_404_TESTERをmu-pluginで定義します。この定数の設定例を次に示します。

<?php

if ( ! defined( 'JETPACK_BOOST_DISABLE_404_TESTER' ) ) {
    define( 'JETPACK_BOOST_DISABLE_404_TESTER', 1 );
}

テスターを無効にし、is_404()がwp-contentディレクトリで機能することを確認したら、jetpack_boost_static_minificationサイトオプションを1に設定できます。これらのファイルの配信に従来の方法を使用するには、0に設定します。

このオプションをWordPress.comまたはPressableで設定しないでください

そのjetpack_boost_static_minificationオプションを1に設定しないでください。WordPress.comまたはPressableでは、404テストは実行されないため、静的配信を強制すると、Jetpack Boostは、欠落したwp-contentファイルについて、WordPressが読み込まれる前にウェブサーバーが404を返すことを検知できなくなります。ホストがこれらの404をウェブサーバーレベルで返す場合（例えば、Pressableの軽量404切り替え）、サイトのCSSとJavaScriptが機能しなくなります。

Jetpack Boostのバージョン4.7.0以降、プラグインはそのjetpack_boost_static_minificationオプションをWordPress.comおよびPressableでは無視し、そこで常にPHPによる配信を使用します。これらのホストでは、4.7.0以降にアップグレードすると、このオプションを設定しても効果はありません。

WordPress.comまたはPressableでこのオプションをすでに1に設定していて、サイトのCSSまたはJavaScriptが機能しない場合は、jetpack_boost_static_minificationを0に戻して、PHP経由の配信を復元してください。

独自の404ルーティングを行うホストを管理していて、この動作を上書きしたい場合は、jetpack_boost_minify_use_static_cache_urlsフィルターを使用してください。これは、独自の404処理を把握しているホストでサポートされる上書き方法です。

まとめMD

直接配信が機能しない場合の多くは、.htaccessファイルが/wp-contentディレクトリにあることが原因です。その設定を確認すれば、404テストが本来どおり動作し、ファイルを直接配信できるようになります。WordPress.comとPressableでは、PHP経由の配信が想定される正しい動作です。