Fastest Cache : accélérer votre site avec Varnish et NGINX

Définition

Pourquoi accélérer la vitesse de chargement de votre site ? 

Il est bon de savoir que la vitesse de chargement de votre site est primordial pour assurer le succès de celui ci. Pour une entreprise par exemple cela donne une première image à ces visiteurs. De plus, un chargement trop long de ce dernier peut avoir un impact sur le référencement de votre site sur les principaux moteurs de recherche et ne permettra pas une exposition suffisante pour faire vivre celui-ci. 

Il n'existe pas de seuil à ne pas dépasser concernant le chargement de vos pages web. Cependant, le temps de chargement de la plupart des sites internet est inférieur à trois secondes. 

Qu'est ce que Fastest Cache et à quoi sert-il ?

L’outil Fastest Cache est un système conçu et développé par LWS permettant d’optimiser les performances de chargement de votre site internet grâce à l’utilisation de mécanismes de cache de page, configurés au niveau du serveur web. L’outil combine les technologies apportées par NGINX et Varnish.

NGINX est un serveur web orienté performance permettant de gérer beaucoup plus de requêtes que Apache (voir notre billet de blog intitulé “Apache VS Nginx : Test de performance”). Elle est principalement utilisée sur Fastest Cache pour gérer l'accès sécurisé en https:// de votre site, éliminer les requêtes HTTP malveillantes (voir LWS Protect) et acheminer les requêtes HTTP aux serveurs de cache Varnish.

Varnish est un service HTTP implémentant un mécanisme de cache de page permettant de mettre en cache le résultat d’une requête HTTP en mémoire.

Avec les bonnes configurations mises en place, NGINX permet d’accueillir plus de requêtes sur votre site internet, et Varnish permet à la fois d’accélérer le temps de chargement de votre page tout en réduisant votre consommation CPU et mémoire.

Procédure

Pourquoi accélérer la vitesse de chargement de votre site ? 

Il est bon de savoir que la vitesse de chargement de votre site est primordiale pour assurer le succès de celui-ci. Pour une entreprise par exemple cela donne une première image à ses visiteurs. De plus, un chargement trop long de ce dernier peut avoir un impact sur le référencement de votre site sur les principaux moteurs de recherche et ne permettra pas une exposition suffisante pour faire vivre celui-ci. 

Il n'existe pas de seuil à ne pas dépasser concernant le chargement de vos pages web. Cependant, le temps de chargement de la plupart des sites internet est inférieur à trois secondes. 

Qu’est-ce que Fastest Cache et à quoi sert-il ?

L’outil Fastest Cache est un système conçu et développé par LWS permettant d’optimiser les performances de chargement de votre site internet grâce à l’utilisation de mécanismes de cache de page, configurés au niveau du serveur web. L’outil combine les technologies apportées par NGINX et Varnish.

NGINX est un serveur web orienté performance permettant de gérer beaucoup plus de requêtes par rapport au serveur web traditionnel Apache HTTPd Server (voir notre billet de blog intitulé “Apache VS Nginx : Test de performance”). LWS utilise NGINX pour pouvoir recevoir en amont un volume élevé de requêtes HTTP sans compromis de performance. Celui-ci peut ensuite être efficacement filtré et éliminer les requêtes malveillantes (voir LWS Protect) et acheminer les requêtes HTTP au serveur de cache Varnish ou LiteSpeed, selon le choix du client depuis son interface d'hébergement.

Varnish est un service HTTP implémentant un mécanisme de cache de page permettant de mettre en cache le résultat d’une requête HTTP en mémoire RAM.

Avec les bonnes configurations mises en place, NGINX permet d’accueillir plus de requêtes sur votre site internet, et Varnish permet à la fois d’accélérer le temps de chargement de votre page tout en réduisant votre consommation CPU et mémoire RAM.

Comment fonctionne le service Fastest Cache ?

Fonctionnement sans cache

Pour mieux comprendre le fonctionnement, nous allons voir dans un premier temps comment cela se passe sans système de cache pour que le visiteur puisse voir votre site.

1. Le visiteur demande la page au serveur web. Exemple : index.php
2. Le serveur web effectue les exécutions de scripts nécessaires (PHP, Python, Node.js …)
3. Le serveur web reçoit le résultat de l’exécution
4. Le serveur web envoie la page HTML issu du résultat de l’exécution du script

Fonctionnement avec le module Fastest Cache

Lorsque Fastest Cache est activé, un serveur de cache est introduit entre le visiteur et le serveur web.

Le but est de réduire le nombre d’exécutions de scripts nécessaire en gardant le résultat de l’exécution en mémoire pour les prochaines requêtes nécessitant la même réponse. Ceci permet de ne plus exécuter plusieurs fois le même script pour aboutir à un même résultat.

Ainsi, nous éliminons le temps d’attente de l’exécution du script sur le temps de chargement de la page, et par la même occasion, nous économisons les ressources utilisées lors de l’exécution du script.

1. Le visiteur demande la page au serveur web. Exemple : index.php
2. Fastest Cache vérifie si la réponse peut être obtenue depuis le cache :

• Si oui, la page est directement retournée au visiteur sans nécessité d’accéder au service web et sans exécuter le script
• Si non, la page est générée par le serveur web, ce qui entraîne l’exécution du script (PHP, Node.js, Perl, Ruby, …). Une fois la page générée, Fastest Cache détermine si la réponse peut être gardée en cache.
  • Si oui, la page est enregistrée dans la mémoire cache et renvoyé au visiteur
  • Si non, la page est renvoyée au visiteur sans être enregistré dans la mémoire cache

On constate que lorsqu’une page est stockée dans la mémoire cache, le traitement par le serveur web ainsi que l’exécution du script est évité, ce qui réduit considérablement le temps d’exécution et la consommation de ressources.

Comportement du système de mise en cache

Fastest Cache se base sur de multiples signaux pour décider du comportement de mise en cache adopté :

• Extension du fichier dans l'URL
• Présence et contenu des paramètres URL (query strings)
• En-tête de réponse Cache-Control
• Cookies

Fastest Cache détecte également certains CMS et extensions / modules et implémente des comportements de mise en cache spécifiques liés à ces outils.

Comportement à la réception de la requête

Fastest Cache ne met en cache que les méthodes HTTP GET et HEAD.

Lorsqu'un visiteur visite un URL, Fastest Cache normalise la requête en supprimant les cookies et paramètres d'URL qui n'influent pas sur le rendu final du script côté serveur (paramètres d'URL Google Analytics, cookies liés à des scripts Javascript ...).

Une fois normalisée, la requête est vérifiée si elle contient une authentification HTTP (en-tête de requête HTTP Authorization) ou s'il reste des cookies (en-tête de requête HTTP Cookie). Si oui, alors la requête sera renvoyée au serveur web sans passer par le système de cache.

Comportement à l'envoi de la réponse

Si la requête n’a pas contourné le cache au moment de la réception de la requête, Fastest Cache analyse à nouveau la réponse HTTP fournie par le serveur web et vérifie s'il est possible de mettre en cache la réponse pour une utilisation future.

Si la réponse HTTP fournit un en-tête de réponse HTTP Cdn-Cache-Control, Fastest Cache respecte immédiatement ce qui y est défini :

• Si no-store, no-cache ou private y est défini, Fastest Cache renvoie la réponse au visiteur sans le garder dans le cache.
• Si s-maxage ou max-age y est défini, Fastest Cache utilise immédiatement cette valeur comme délai de rétention de la page dans le cache.

Si Cdn-Cache-Control est défini avec Set-Cookie, Cdn-Cache-Control sera ignoré et la réponse ne sera pas gardée dans le cache.

Les fichiers statiques correspondants aux thèmes, plugins, uploads et core WordPress sont automatiquement gardés en cache pour 30 jours.

Si la réponse HTTP provient du système de cache de page LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize ou FastPixel, celui-ci est gardée en cache pour 7 jours. Ces plugins WordPress procèderont eux-mêmes à la purge du cache Varnish lorsqu'ils suppriment le cache de page.

Si la réponse HTTP provient du dossier /_next/static, celui-ci est également gardée en cache pour 7 jours.

Si la réponse HTTP renvoie un code HTTP 404, ceci est gardée en cache pendant 900 secondes. Cela permet d'éviter davantage de requête inutile sur la base de données MySQL notamment pour WordPress.

Si la réponse HTTP renvoie un code HTTP 500, la réponse n'est jamais gardée en cache.

Si la réponse HTTP contient un cookie (en-tête de réponse HTTP Set-Cookie), la réponse n'est jamais gardée en cache.

Si la réponse HTTP fournit un en-tête de réponse HTTP Cache-Control ou Surrogate-Control, Fastest Cache suit le comportement de cache attendu pour les navigateurs. Si ces en-têtes sont fournis avec Cdn-Cache-Control, Fastest Cache ignore Cache-Control et Surrogate-Control au profit de Cdn-Cache-Control. Ceci permet, par exemple, d'obliger le navigateur à faire une requête HTTP pour consulter une liste d'article à chaque visite, sans que la liste d'article ne soit absent du cache serveur.

Présentation de l'interface et activation du service

Fastest Cache se présente sous la forme d’une icône dans cPanel dans la section “Performance”.

Une fois dans l’interface, le domaine principal, les domaines supplémentaires et les sous-domaines sont affichés sur la liste.

• La colonne “Statut du cache” affiche l’état d’activation du cache. Si celui-ci est sur “Activé” alors le cache est activé.
• Le bouton “Purger le cache” permet de supprimer toutes les données en cache pour ce nom de domaine en particulier.
• Le bouton “Désactiver le cache” permet de désactiver la mise en cache.
• Le bouton “Activer le cache” permet d’activer la mise en cache.
• Le bouton “Changer le mode de fonctionnement” permet de modifier le comportement du système de cache. Ces modes seront expliqués juste après.

Les différents modes de cache

Par défaut, le système de cache opte pour le mode « Utilisation générale » qui convient aux utilisations générales. Il existe toutefois d’autres modes :

Mode développeur : identique à la désactivation du cache, ceci permet d'outrepasser le système de cache pendant vos périodes de développement.
WordPress : un mode de cache plus adapté à WordPress où la gestion des dossiers (wp-content, wp-admin, …) et des cookies spécifiques à WordPress est améliorée.
Prestashop : un mode de cache plus adapté à Prestashop où la gestion des dossiers et des cookies est améliorée.

Purge du cache

Au-delà de l’interface cPanel permettant de purger le cache, il est possible de purger manuellement le cache depuis le terminal SSH du compte cPanel ou depuis un script hébergé sur le serveur.

Lancées depuis votre hébergement (script PHP de votre site, tâche Cron ou terminal SSH), ces méthodes ne demandent ni jeton d'API ni identifiant : Fastest Cache accepte directement les méthodes HTTP PURGE.

Purge du cache avec cURL

Purger le cache d’une page :

curl -X PURGE https://mon-site-web.com/mapage.php

Ceci permettra de purger le cache de l’URL https://mon-site-web.com/mapage.php.

Purger le cache d'un dossier :

curl -X PURGE 'https://mon-site-web.com/wp-content/uploads/.*'

Ceci permettra de purger tous les caches des URLs commençant par 'https://mon-site-web.com/wp-content/uploads/'

Purger le cache d'un site

curl -X PURGE https://mon-site-web.com/.*

Pour l'ensemble de ces trois commandes, trois retours sont possibles :

Code HTTP 200 : la purge s’est bien passée sans erreur.

Code HTTP 4xx : la purge n’est pas autorisée.

Code HTTP 5xx : une erreur s'est produite.

Purge automatique avec un script PHP (tâche Cron)

Le script suivant vide le cache de tout le site, ou de quelques pages seulement. Copiez-le dans un fichier purge-cache.php de votre hébergement, puis indiquez votre domaine dans $site. Pour ne purger que certaines pages, listez-les dans $pages.

<?php
/*
 * Purge du cache Varnish (Fastest Cache) - a lancer a la main ou par une tache Cron.
 * Aucun jeton n'est necessaire.
 *
 * $pages vide  : purge complete du site
 * $pages rempli : purge des seules adresses indiquees
 */

$site  = 'https://mon-site-web.com';
$pages = []; // exemple : ['/index.php', '/blog/']

function purger($url)
{
    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_CUSTOMREQUEST  => 'PURGE',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' purge complete : HTTP ' . purger($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Pour le lancer automatiquement, par exemple chaque nuit, créez une tâche Cron qui exécute ce fichier avec PHP. Si vous voulez simplement vider tout le cache, la tâche Cron peut aussi exécuter directement :

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Purge avec un plugin ou module

La majorité des plugins/modules ayant une intégration Varnish est compatible avec le mécanisme de purge interne de Fastest Cache.

Voici quelques plugins testés et vérifiés compatibles :

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

Détection HTTPS et redirections

L’état HTTPS et les ports indiqués sur Apache sont injectés sur l'environnement et ne nécessitent généralement aucune modification supplémentaire.

Toutefois, si la détection HTTPS n’est pas fonctionnelle avec Fastest Cache, ceci peut causer des boucles de redirections infinies. Ainsi, il sera nécessaire de modifier les données de détection.

Les en-têtes HTTP de confiance pour la détection sont :

• X-Forwarded-Proto
• X-Forwarded-Port

Ainsi, si vous utilisez la redirection HTTPS suivante avec un .htaccess :

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

et que cela ne fonctionne pas, vous pouvez remplacer la variable SERVER_PORT par X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare et autres CDN

Les CDN de type CloudFlare peuvent filtrer les requêtes HTTP qui pourraient bloquer les requêtes “PURGE” et utilisées par Fastest Cache pour purger le cache. Il vous est alors conseillé de préciser l'adresse IP du serveur lors de votre purge avec curl afin d'outrepasser les CDN lors des actions de purge :

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

Les CDN peuvent également contenir une couche de cache supplémentaire que vous devez gérer indépendamment du cache fourni par Fastest Cache.

Trucs et astuces

Purge du cache

Au-delà de l’interface cPanel permettant de purger le cache, il est possible de purger manuellement le cache depuis le terminal SSH du compte cPanel ou depuis un script hébergé sur le serveur.

1. Purge du cache avec cURL

Purger le cache d’une page :

curl -X 'PURGE' http://mon-site-web.com/mapage.php

Ceci permettra de purger le cache de l’URL http://mon-site-web.com/mapage.php.

Purger le cache d'un dossier :

curl -X 'PURGE -H 'X-Purge-Method:regex' 'http://mon-site-web.com/wp-content/uploads/.*'

Ceci permettra de purger tous les caches des URLs commencant par 'http://mon-site-web.com/wp-content/uploads/'

Purger le cache d'un site

curl -X 'FULLPURGE' http://mon-site-web.com

Pour l'ensemble de ces trois commandes, deux retours sont possibles :

Code HTTP 200 : la purge s’est bien passée sans erreur.

Code HTTP 405 : la purge n’est pas autorisée ou ne s'est pas effectuée.

2. Purge avec un plugin ou module

La majorité des plugins/modules ayant une intégration Varnish est compatible avec le mécanisme de purge interne de Fastest Cache.

Voici quelques plugins testés et vérifiés compatible :

• WP Rocket : https://wp-rocket.me
• Proxy Cache Purge : https://wordpress.org/plugins/varnish-http-purge/

Détection HTTPS et redirections

L’état HTTPS et les ports indiqués sur Apache sont modifiés par le module mod_fastestcache intégré sur Apache. Il n’est donc généralement pas nécessaire d’apporter des modifications.

Toutefois, si la détection HTTPS n’est pas fonctionnelle avec Fastest Cache, ceci peut causer des boucles de redirections infinies. Ainsi, il sera nécessaire de modifier les données de détection.

Les en-têtes HTTP de confiance pour la détection sont :

• X-Forwarded-Proto
• X-Forwarded-Port

Ainsi, si vous utilisez la redirection HTTPS suivante avec un .htaccess :

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

et que cela ne fonctionne pas, vous pouvez remplacer la variable SERVER_PORT par X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare et autres CDN

Les CDN de type CloudFlare présentent des filtres de requêtes HTTP qui pourraient bloquer les requêtes “PURGE” et “FULLPURGE” utilisées par Fastest Cache pour purger le cache.

Nous vous recommandons de n’utiliser qu’un seul niveau de cache, donc au choix Cloudflare ou Fastest Cache.

Leur utilisation combinée peut induire des comportements non désirables. Testez les deux, utilisez ce qui convient le mieux à votre besoin.