Accueil
/
Aide du site web
/
Vitesse et disponibilité
/
Comment améliorer le taux de cache de votre site web ?

Comment améliorer le taux de cache de votre site web ?

Qu’est-ce que le taux de cache ?

Lorsqu’il s’agit de la vitesse de chargement de votre site web, l’un des facteurs les plus critiques à prendre en compte est le nombre de vos requêtes traitées depuis le cache. Les requêtes mises en cache sont beaucoup plus rapides que celles qui dépendent de la puissance de calcul du serveur pour être traitées, ce qui signifie que plus le nombre de requêtes traitées depuis le cache est élevé, plus le chargement de votre site web est rapide.

Les serveurs web SiteGround ont un système de cache intégré (NGINX Direct Delivery, service de cache dynamique) et ils vérifient toujours si le contenu demandé est présent dans les pools de cache avant de le transférer par proxy. Si le contenu est trouvé dans le cache, alors il est servi immédiatement au client (évitant ainsi le traitement de PHP, les requêtes MySQL, etc.). C’est ce qu’on appelle un cache HIT . D’un autre côté, si le contenu n’est pas trouvé dans le cache, le serveur web doit le récupérer sur le serveur d’origine et le mettre en cache pour de futures requêtes. C’est ce qu’on appelle un cache MISS .

Le taux de cache représente le pourcentage de requêtes traitées depuis le cache sans qu’il soit nécessaire d’accéder au serveur d’origine. Un taux de cache plus élevé indique que davantage de requêtes sont traitées depuis le cache, ce qui réduit la charge sur le serveur d’origine et améliore les performances globales du site web.

Par exemple, s’il y a 100 lignes dans le fichier journal d’accès de votre site web et que 80 d’entre elles contiennent « HIT » et 20 d’entre elles contiennent « MISS », le taux de cache serait de 80 %.

Certaines pages stockent des données sensibles ou des requêtes POST la plupart du temps, elles sont donc exclues de la mise en cache par défaut – en d’autres termes, connectez-vous à votre tableau de bord d’administration WordPress, le processus de commande et les demandes de paiement réelles sont tous ne sont pas censés être mis en cache et ne sont pas pris en compte lors du calcul du taux de cache.

En mesurant le ratio « HIT », vous pouvez déterminer l’efficacité de votre stratégie de mise en cache et si vous devez ajuster des paramètres de votre site web afin d’améliorer ses performances. Un taux de cache élevé indique que votre stratégie de mise en cache fonctionne bien et que vous tirez efficacement parti des fonctionnalités de vitesse de site fournies par SiteGround. Un faible taux de cache, en revanche, suggère que votre stratégie de mise en cache pourrait ne pas être efficace, et vous devrez peut-être envisager d’implémenter d’autres techniques d’optimisation.

Pour les sites abonnés à nos rapports de performance mensuels, nous mesurons le taux de cache et le rapportons à notre client. Notre recommandation est de viser un résultat supérieur à 60 %.

Comment augmenter le taux de cache de votre site web ?

1. Gardez un œil sur les en-têtes Cache-Control personnalisés définis dans vos fichiers .htaccess

Avoir des règles .htaccess pour ajuster les en-têtes de réponse est l’un des moyens les plus courants de contrôler l’efficacité de la mise en cache. Malheureusement, nous avons remarqué beaucoup d’en-têtes Cache-Control génériques intégrés dans les fichiers .htaccess qui ne sont pas spécifiques à l’emplacement et par conséquent affectent négativement le taux de HIT du cache et les performances.

Exemple:

 Jeu d’en-têtes Cache-Control « no-cache,no-store » 

Les serveurs web SiteGround respectent les directives de l’en-tête Cache-Control et ne mettent pas en cache les réponses lorsque l’en-tête contient les directives « Private », « No-Cache » ou « No-Store ».

Règle empirique #1 : Assurez-vous que « Header set Cache-Control » dans .htaccess est utilisé uniquement pour les pages, les emplacements ou les fichiers de votre site web qui contiennent des données clientes sensibles et ne devraient pas être mis en cache – pas pour le site entier. Exemple:

 # ajoute l’en-tête Cache-Control à l’unique fichier contact.php

En-tête défini Cache-Control « no-cache,no-store »
 

2. Inspecter avec précision les directives Expire et max-age

Une autre approche bien connue pour contrôler l’efficacité des serveurs de cache consiste soit à inclure des en-têtes Expires avec une date et une heure postérieures au futur, soit un en-tête Cache-Control avec la directive max-age définie sur zéro ou une valeur numérique négative.

Exemple #1:

 # Expire les en-têtes (pour un meilleur contrôle du cache)

...
# Votre document html
ExpiresByType text/html « accès plus 0 seconde »
...
 

Cette définition dans les fichiers .htaccess signifie que le cache devrait expirer immédiatement pour le type de contenu text/html (la plupart des pages web sont livrées dans ce type) et que la requête devrait être servie par le serveur principal et non par le cache.

Exemple #2:

 Jeu d’en-têtes Cache-Control « max-age=0 » 

Avoir un en-tête Cache-Control avec max-age=0 ou -1 (ou un autre nombre négatif) signifie encore une fois que la requête doit être traitée par le moteur et non par le cache.

Règle empirique n°2:

3. Éviter l’utilisation de l’en-tête Set-Cookie

Une autre approche pour contourner la mise en cache est d’avoir un en-tête Set-Cookie. Généralement, l’en-tête Set-Cookie est utilisé avec la variable « PHPSESID » – un cookie de session qui est utilisé pour identifier la session d’un utilisateur sur un site web. Cependant, générer et utiliser un cookie de session sur des pages qui ne contiennent pas d’informations sensibles peut être le signe d’un module ou d’un thème mal conçu. Par conséquent, l’existence d’un en-tête Set-Cookie évite que les réponses ne soient mises en cache à chaque fois qu’une exécution PHP est effectuée.

 <?php
session_start(); 

Lorsque c’est le cas, vous remarquerez la ligne suivante dans les en-têtes de réponse HTTP de votre site web:

 set-cookie: PHPSESSID=5eff6b1bc4f7ab78758e112be82f7b9e 

Règle empirique n°3: Dans le cas où votre site web utilise l’en-tête Set-Cookie et le « PHPSESID » le plus couramment utilisé, assurez-vous qu’il est généré uniquement pour identifier la session d’un utilisateur sur un site web et pas sur toutes les pages et messages.

4. Éviter d’utiliser Vary: en-tête User-Agent

Cette configuration ne désactive pas complètement la mise en cache comme décrit dans les exemples précédents, mais elle diminue considérablement le taux de cache. En fait, le problème est que souvent les visiteurs de votre site web utiliseront différents User-Agent (navigateurs différents, avec des versions différentes), ce qui mettra pratiquement chaque première visite en cache. C’est aussi un cas courant lorsqu’un greffon WP ajoute un tel en-tête. Dans ces cas, les réponses sont mises en cache mais il y a différentes entrées de cache pour les différents agents utilisateurs, rendant le cache considérablement moins efficace.

Voici un exemple d’en-tête .htaccess variable:

 Jeu d’en-têtes Vary User-Agent

Les en-têtes HTTP peuvent également être gérés via les applications du compte d’hébergement. L’en-tête Vary, par exemple, peut être configuré via PHP de la manière suivante:

 ?php
header("Vary: User-Agent");

ou sur un site WordPress (à partir du fichier functions.php)

, fonction add_vary_header ($headers)
{
$headers['Vary'] = 'User-Agent';
Renvoie $headers ;
}
add_filter('wp_headers', 'add_vary_header'); 

Règle d’or n°4: Essayez d’éviter d’utiliser l’en-tête Vary User-Agent si cela n’est pas absolument nécessaire ou exigé par les développeurs du thème. Cela vous aidera à améliorer considérablement le taux de mise en cache et les performances de votre site.

Si l’utilisation d’un en-tête User-Agent Vary est indispensable, il est toujours préférable d’avoir un cache par agent utilisateur plutôt qu’aucun cache.

Si vous souhaitez que nos ingénieurs d’assistance étudient la possibilité d’améliorer le taux de cache de votre site actuel, vous pouvez nous envoyer un ticket via le service d’assistance > Autre> Optimisation du taux de cache .

Partager cet article