rocket nginx
3.1.0
Rocket-Nginx は、WordPress キャッシュ プラグイン WP Rocket の Nginx 構成です。これにより、Nginx は、WordPress や PHP を呼び出すことなく、以前にキャッシュされたファイルを直接提供できるようになります。また、Web サーバーへのリクエストを減らしてブラウザのキャッシュを活用するために、CSS、JS、メディアをキャッシュするヘッダーも追加します。
「この構成はどれほど優れているのだろうか?」と自問するかもしれません。
WP Rocket 自身が Web サイトでこれを使用して、さらに高速化しているとだけ言っておきましょう。
このプロジェクトは、カナダのモントリオール近郊にある WordPress メンテナンス サービスである SatelliteWP によって後援されています。当社のサービスは英語とフランス語の両方で提供されます。 SatelliteWP は WordPress サイトの主要なサイトです。
この構成は Maxime Jobin (@maximejobin) によって作成され、現在は SatelliteWP によって維持されています。
この設定の目的は、WordPress から PHP を実行することなく、キャッシュされたファイルを直接提供することであるため、スケジュールされたジョブが呼び出されない可能性があります。すでにご存知かもしれませんが、WP-Cron ジョブは実際の cron ジョブではなく、サイトにアクセスした場合にのみ実行されます。
スケジュールされたタスクが必要なときに確実に実行されるようにするには、WordPress cron ジョブを無効にして実際の cron ジョブを作成することを強くお勧めします。
WordPress cron ジョブを無効にするには、次の行をwp-config.phpに追加します。
define( 'DISABLE_WP_CRON', true );
次に、15 分ごとに手動で cron ジョブを実行します (ほとんどの Web サイトではこれで十分です)。
*/15 * * * * wget -q -O - http://www.website.com/wp-cron.php?doing_wp_cron &>/dev/null
または
*/15 * * * * curl http://www.website.com/wp-cron.php?doing_wp_cron &>/dev/null
または
*/15 * * * * cd /home/user/public_html; php wp-cron.php &>/dev/null
この変更後もタスクが引き続き実行されることを必ずテストしてください。
スクリプトを使用するには、それを実際の構成に含める必要があります。 WordPress Web サイトがまだ Nginx で実行するように構成されていない場合は、WordPress ドキュメントの Nginx 構成を確認できます。
WP Rocket を使用するすべての WordPress Web サイトに必要な Rocket-Nginx のインスタンスは 1 つだけです。必要なだけ構成ファイルを生成できます。
Nginx 構成ディレクトリにrocket-nginxディレクトリというフォルダーを作成できます。 Ubuntu を使用している場合、Nginx 構成 (nginx.conf) は/etc/nginx/にあります。
インストールするには、次のことができます。
cd /etc/nginx
git clone https://github.com/satellitewp/rocket-nginx.git
バージョン 2.0 以降、構成を生成する必要があります。デフォルトの構成を生成するには、無効な ini ファイルの名前を変更し、構成パーサーを実行する必要があります。
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php
これにより、すべての Web サイトに含めることができるdefault.conf構成が生成されます。デフォルト設定を変更する必要がある場合は、ini ファイルを編集して、ファイルの最後に別のセクションを追加します。
次に、Nginx 構成ファイルに、生成された構成を含める必要があります。 Web サイトの設定が/etc/nginx/sites-availableにある場合は、設定を変更する必要があります。
server {
...
# Rocket-Nginx configuration
include rocket-nginx/conf.d/default.conf;
...
}
設定をリロードする前に、必ずテストしてください: nginx -t
テストが完了したら、構成をリロードする必要があります。 service nginx reload
それでおしまい。
行うべき設定はありません。すぐに使えます。ただし、いくつか編集できます...
rocket-nginx.iniファイルを開いて、その中のすべてのオプションを確認してください。
次のように、デフォルト設定に基づいて新しいセクションを追加できます。
# This creates the new section and will generate a new configuration
[example.com : default]
# This will add a value to invalidate the cache with a cookie
cookie_invalidate[] = "my_custom_cookie"
ini ファイルを編集したら、パーサーを実行して Nginx 構成ファイルを再生成する必要があります。
php rocket-parser.php
その後、新しく追加または変更されたセクションにより、更新構成ファイル (*.conf) が生成されます。
最後に、構成ファイルを生成 (または再生成) するたびに、次のことを行う必要があります。
テストして、エラーが発生しないことを確認します。
nginx -t
設定をリロードします。
service nginx reload
バージョン 3.0 以降では、 conf.dフォルダーが作成されます。作成する異なるプロファイルごとに、そのフォルダー内にサブフォルダーが作成されます。その中で、生成された構成ファイルに含まれるファイルを作成できます。
構成ファイルはさまざまなタイミングで含めることができます。
デフォルトのプロファイルでは、ファイル名パターンstart.*.confを持つファイルをconf.d/default/に作成します。
デフォルトのプロファイルでは、次のファイル名パターンを持つファイルをconf.d/default/に作成します: global.*.conf 。
デフォルトのプロファイルでは、ファイル名パターンhttp.*.confを持つファイルをconf.d/default/に作成します。
デフォルトのプロファイルでは、ファイル名パターンpreprocess.*.confを持つファイルをconf.d/default/に作成します。
デフォルトのプロファイルで、ファイル名パターンcss.*.confを持つファイルをconf.d/default/に作成します。
デフォルトのプロファイルでは、ファイル名パターンjs.*.confを持つファイルをconf.d/default/に作成します。
デフォルトのプロファイルでは、次のファイル名パターンを持つファイルをconf.d/default/に作成します: media.*.conf 。
ファイルが PHP を呼び出さずに Nginx によって直接提供されているかどうかを確認してください。これを行うには、 rocket-nginx.iniファイルを開き、デバッグ値を次のように変更します。
debug = false
に：
debug = true
次のヘッダーは、デバッグが true に設定されているか false に設定されているかに関係なく存在します。
キャッシュされたファイルが提供されない理由:
Rocket-Nginx は完璧ですか?いいえ、そうではありません!私たちは可能な限り完璧にしようと努めましたが、Nginx のスクリプト言語は、たとえば PHP のような言語が提供するすべての可能性を提供するわけではありません。したがって、いくつかの制限があります。
エンコードされたスラッグ
短い答え: エンコードされたスラッグは Rocket-Nginx では提供できません。
Nginx のスクリプト制限により、「جزازة العشب」のようなスラッグはエンコードされ、ファイルは WP Rocket によって「%d8%ac%d8%b2%d8%a7%d8%b2%d8%a9%20%d8%a7」として保存されます。 %d9%84%d8%b9%d8%b4%d8%a8' （小文字）。 Google Chrome などの一部のブラウザは、リクエストを「%D8%AC%D8%B2%D8%A7%D8%B2%D8%A9%20%D8%A7%D9%84%D8%B9%D8%」として送信します。 B4%D8%A8' (大文字)。 PHP などの言語を使用すると、これらの文字列を等しいものとして比較するのが簡単になります。 Nginx では、サードパーティ モジュール (Perl や Lua など) が必要でない限り、これは不可能です。 Rocket-Nginx をできるだけ汎用的なものにするために、モジュールの依存関係を追加しないことが決定されました。エンコードされたスラッグをサポートし、不足しているコードを追加する場合は、バージョン 3.1.0 (以降) で、 $rocket_uri_path変数の大文字と小文字を変更する (小文字を強制する) ための「preprocess」という名前の新しい構成インクルードが提供されることに注意してください。
WEBP の互換性
簡単な答え: WebP 互換機能を有効にすると、Rocket-Nginx は WP Rocket によって生成された WebP キャッシュ ファイルを提供しません。
画像 (JPG、PNG など) を WebP に変換するツールを使用した場合、WP Rocket は特定のキャッシュを作成できます。残念ながら、Nginx のスクリプト言語は検証を正しく実行できるほど強力ではありません。したがって、この機能を有効にすると、Rocket-Nginx は WP Rocket にリクエストを処理させ、コンテキストに応じて適切なキャッシュされたページを提供します。
Rocket-Nginx は BF Cache (バック/フォワード キャッシュ) と互換性がありますか?
はい！ Web サイトに機密データが表示されず、バック/フォワード キャッシュに適している場合は、問題の BF Cache の説明に従って Rocket-Nginx 構成を編集する必要があります。
バージョン 1 または 2 からバージョン 3 にアップグレードするにはどうすればよいですか?
以前の設定を保存して、最初からやり直すことをお勧めします。多くのことが変更されたため、この機会にすべてを見直してください。公式には、バージョン 3.x には以前のバージョンとの下位互換性がありません。最初から始めるのに 15 分もかかりません。
バージョン 3.x の新機能は何ですか?
いろいろ！
このプロジェクトに関するベンチマークはありますか?
いいえ、人々はベンチマークを嫌いますが、ベンチマークを愛しています。すべてのベンチマークで、結果を改善するために X または Y または Z を実行できたはずだと主張する人がいます。このプロジェクトでは、ベンチマークは、出力がキャッシュにある場合でもページに影響を与えるプラグインの数によって異なります (たとえば、WP Rocket はファイルがキャッシュにある場合でも PHP を実行します)。ただし、言えることは、NGINX → PHP-FPM → WordPress (PHP とデータベース) → 静的ファイル、 NGINX → 静的ファイルの順に進むということです。言い換えれば、静的ファイルを提供する前にリクエストを FPM に渡してから PHP (少なくとも WP Rocket の場合) に渡すのではなく、NGINX から静的ファイルを直接提供しています。
Web サイトが SSL 証明書 (https) を使用している場合、Rocket-Nginx は機能しますか?
はい！ Rocket-Nginx は、リクエストが HTTP または HTTPS を通じて行われたかを検出し、リクエストの種類に応じて適切なファイルを提供します。バージョン 1.0 以降、両方のプロトコルが自動的に処理されます。
MITライセンスに基づいてリリースされています。詳細については、ライセンス ファイルを参照してください。
