rocket nginx
3.1.0
Rocket-Nginx est une configuration Nginx pour le plugin de cache WordPress WP Rocket. Il permet à Nginx de servir directement des fichiers précédemment mis en cache sans appeler WordPress ou PHP. Il ajoute également des en-têtes au cache CSS, JS et médias afin d'exploiter le cache du navigateur en réduisant les requêtes adressées à votre serveur Web.
Vous pourriez vous demander : « Cette configuration est-elle bonne ? ».
Disons simplement que WP Rocket l'utilise lui-même sur son site web pour le rendre encore plus rapide !
Ce projet est sponsorisé par SatelliteWP, un service de maintenance WordPress situé près de Montréal, Canada. Notre service est offert en anglais et en français. SatelliteWP fait de l'entretien des sites WordPress.
La configuration a été créée par Maxime Jobin (@maximejobin) et est désormais maintenue par SatelliteWP.
Comme l'objectif de la configuration est de servir directement les fichiers mis en cache sans avoir à exécuter de PHP depuis WordPress, cela peut empêcher l'appel de vos tâches planifiées. Comme vous le savez peut-être déjà, les tâches WP-Cron ne sont pas de véritables tâches cron et ne sont exécutées que lorsque vous avez des visites sur votre site.
Afin de vous assurer que vos tâches planifiées s'exécutent quand elles le devraient, il est fortement suggéré de désactiver les tâches cron WordPress et de créer une véritable tâche cron.
Pour désactiver la tâche cron WordPress, ajoutez la ligne suivante à votre wp-config.php :
define( 'DISABLE_WP_CRON', true );
Ensuite, effectuez manuellement une tâche cron toutes les 15 minutes (cela devrait suffire pour la plupart des sites Web) :
*/15 * * * * wget -q -O - http://www.website.com/wp-cron.php?doing_wp_cron &>/dev/null
ou
*/15 * * * * curl http://www.website.com/wp-cron.php?doing_wp_cron &>/dev/null
ou
*/15 * * * * cd /home/user/public_html; php wp-cron.php &>/dev/null
Assurez-vous de tester que vos tâches s'exécutent toujours après ce changement !
Pour utiliser le script, vous devez l'inclure dans votre configuration actuelle. Si votre site Web WordPress n'est pas encore configuré pour fonctionner avec Nginx, vous pouvez consulter la configuration Nginx pour la documentation WordPress.
Une seule instance de Rocket-Nginx est nécessaire pour tous vos sites Web WordPress utilisant WP Rocket. Vous pouvez générer autant de fichiers de configuration que nécessaire.
Vous pouvez créer un répertoire rocket-nginx dans votre répertoire de configuration Nginx. Si vous utilisez Ubuntu, votre configuration Nginx (nginx.conf) devrait se trouver dans : /etc/nginx/ .
Pour installer, vous pouvez :
cd /etc/nginx
git clone https://github.com/satellitewp/rocket-nginx.git
Depuis la version 2.0, la configuration doit être générée. Pour générer la configuration par défaut, vous devez renommer le fichier ini désactivé et exécuter l'analyseur de configuration :
cd rocket-nginx
cp rocket-nginx.ini.disabled rocket-nginx.ini
php rocket-parser.php
Cela générera la configuration default.conf qui pourra être incluse pour tous les sites Web. Si vous devez modifier la configuration par défaut, vous pouvez modifier le fichier ini et ajouter une autre section au bas du fichier.
Ensuite, dans votre fichier de configuration Nginx, vous devez inclure la configuration générée. Si les configurations de vos sites Web sont dans /etc/nginx/sites-available , vous devez modifier votre configuration :
server {
...
# Rocket-Nginx configuration
include rocket-nginx/conf.d/default.conf;
...
}
Avant de recharger votre configuration, assurez-vous de la tester : nginx -t
Une fois votre test effectué, vous devez recharger votre configuration. service nginx reload
C'est ça.
Il n'y a aucune configuration à faire. Cela fonctionnera immédiatement. Mais vous pouvez modifier plusieurs choses...
Ouvrez simplement le fichier rocket-nginx.ini et voyez toutes les options qu'il contient.
Vous pouvez ajouter une nouvelle section basée sur la configuration par défaut comme ceci :
# 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"
Une fois que vous avez modifié le fichier ini, vous devez régénérer votre fichier de configuration Nginx en exécutant l'analyseur :
php rocket-parser.php
Ensuite, les sections nouvellement ajoutées ou modifiées généreront un fichier de configuration de mise à jour (*.conf).
Enfin, chaque fois que vous générez (ou régénérez) les fichiers de configurations, vous devez :
Testez-le pour vous assurer qu'il n'a généré aucune erreur :
nginx -t
Rechargez la configuration :
service nginx reload
À partir de la version 3.0, un dossier conf.d est créé. Pour chaque profil différent que vous créez, un sous-dossier est créé dans ce dossier. Dans celui-ci, vous pouvez créer des fichiers qui seront inclus dans le fichier de configuration généré.
Vous pouvez inclure des fichiers de configuration à différents moments.
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : start.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : global.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : http.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : preprocess.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : css.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : js.*.conf .
Dans le profil par défaut, créez un fichier dans conf.d/default/ ayant le modèle de nom de fichier suivant : media.*.conf .
Vous souhaiterez peut-être vérifier si vos fichiers sont servis directement par Nginx et sans appeler PHP. Pour ce faire, ouvrez le fichier rocket-nginx.ini et modifiez la valeur de débogage de :
debug = false
À:
debug = true
L'en-tête suivant est présent, que le débogage soit défini sur true ou false :
Raisons pour lesquelles un fichier mis en cache n'est pas diffusé :
Rocket-Nginx est-il parfait ? Non, ce n'est pas le cas ! Nous avons essayé de le rendre le plus parfait possible, mais le langage de script de Nginx n'offre pas toutes les possibilités offertes par un langage comme PHP par exemple. Il existe donc certaines limites.
Slugs codés
Réponse courte : un slug codé ne peut pas être servi par Rocket-Nginx.
En raison des limitations de script de Nginx, les slugs comme « جزازة العشب » sont codés et le fichier est stocké par WP Rocket sous le nom « %d8%ac%d8%b2%d8%a7%d8%b2%d8%a9%20%d8%a7 ». %d9%84%d8%b9%d8%b4%d8%a8' (minuscule). Certains navigateurs, comme Google Chrome, enverront la requête sous la forme '%D8%AC%D8%B2%D8%A7%D8%B2%D8%A9%20%D8%A7%D9%84%D8%B9%D8% B4%D8%A8' (majuscule). En utilisant un langage comme PHP, il serait facile de comparer ces chaînes comme étant égales. Avec Nginx, cela n'est possible que si un module tiers (comme Perl ou Lua) est nécessaire. Pour rendre Rocket-Nginx aussi générique que possible, il a été décidé de ne pas ajouter de dépendance de module. Si vous souhaitez prendre en charge les slugs encodés et ajouter le code manquant, notez que la version 3.1.0 (et versions ultérieures) propose un nouvel include de configuration nommé "preprocess" pour modifier la casse de la variable $rocket_uri_path (forcer les minuscules).
Compatibilité WEBP
Réponse courte : Rocket-Nginx ne servira pas les fichiers de mise en cache WebP générés par WP Rocket si vous activez la fonctionnalité de compatibilité WebP.
WP Rocket est capable de créer un cache spécifique si vous avez utilisé un outil pour convertir vos images (JPG, PNG, ...) en WebP. Malheureusement, le langage de script de Nginx n'est pas assez puissant pour réaliser correctement la validation. Par conséquent, si vous activez cette fonctionnalité, Rocket-Nginx laissera WP Rocket gérer la requête et servir la bonne page en cache, en fonction du contexte.
Rocket-Nginx est-il compatible avec BF Cache (cache arrière/avant) ?
Oui! Si votre site Web n'affiche pas de données sensibles et correspond bien à la mise en cache arrière/suivant, vous devez modifier votre configuration Rocket-Nginx en suivant la discussion sur BF Cache dans les numéros.
Comment passer de la version 1 ou 2 à la version 3 ?
Nous vous suggérons de sauvegarder votre configuration précédente et de recommencer. Profitez de cette occasion pour tout revoir car beaucoup de choses ont changé. Officiellement, la version 3.x n'est pas rétrocompatible avec les versions précédentes. Repartir de zéro ne devrait pas prendre plus de 15 minutes.
Quoi de neuf dans la version 3.x ?
Beaucoup de choses !
Avez-vous des repères sur le projet ?
Non. Les gens aiment les benchmarks autant qu’ils les détestent. Dans tous les benchmarks, des personnes affirment que X, Y ou Z auraient pu être réalisés pour améliorer le résultat. Dans ce projet, le benchmark dépendra du nombre de plugins dont vous disposez et qui affectent la page même si la sortie est en cache (par exemple, WP Rocket exécute PHP même lorsqu'un fichier est en cache). Ce que nous pouvons dire cependant, c'est que vous passerez de NGINX → PHP-FPM → WordPress (PHP et base de données) → Static file à NGINX → Static file . En d'autres termes, vous servez le fichier statique directement depuis NGINX au lieu de transmettre la requête à FPM puis à PHP (pour WP Rocket... au moins) avant de servir le fichier statique.
Rocket-Nginx fonctionnera-t-il si mon site Web utilise un certificat SSL (https) ?
Oui! Rocket-Nginx détectera si la demande a été effectuée via HTTP ou HTTPS et servira le bon fichier en fonction du type de demande. Les deux protocoles sont gérés automatiquement depuis la version 1.0.
Publié sous la licence MIT. Consultez le fichier de licence pour plus de détails.
