Stratégie de cache pour un site autonome : configurer le cache de page, le cache d’objets et le cache navigateur
1. Ce que gère chaque niveau de cache
Le cache d’un site autonome se divise en trois niveaux, chacun résout un problème différent : ne les confondez pas. Le cache de page enregistre le rendu HTML complet sous forme de fichier statique ; au prochain accès à la même URL, le fichier est renvoyé directement, sans repasser par PHP ni la base de données. Le cache d’objets stocke les résultats des requêtes à la base de données en mémoire (Redis ou Memcached par exemple) ; la prochaine requête identique est lue directement en mémoire, sans interroger MySQL. Le cache navigateur utilise les en-têtes de réponse HTTP pour dire au navigateur du visiteur « garde ce fichier en local » ; à la prochaine visite, il le lit directement sur le disque local.
Le gain de performance diffère beaucoup d’un niveau à l’autre. Le cache de page rapporte le plus — il saute entièrement l’exécution PHP et les requêtes à la base de données, et le LCP passe de plus de 4 secondes à moins d’une seconde. Le cache d’objets rapporte moyennement — il ne fait qu’économiser le temps des requêtes à la base de données ; si le cache de page est déjà touché, le cache d’objets n’est même pas sollicité. Le cache navigateur profite aux visiteurs qui reviennent — le premier accès doit télécharger, le deuxième lit en local, et la vitesse de revisite s’améliore nettement.
| Niveau de cache | Ce qu’il stocke | Où il stocke | Gain de performance | Outils typiques |
|---|---|---|---|---|
| Cache de page | Page HTML complète | Disque ou mémoire du serveur | Maximal, LCP réduit de 60 % à 80 % | WP Rocket、LiteSpeed Cache |
| Cache d’objets | Résultats de requêtes, objets PHP | Redis ou Memcached | Moyen, temps de requête DB réduit de 50 % | Redis、Memcached |
| Cache navigateur | CSS/JS/images | Navigateur du visiteur, en local | Visiteurs qui reviennent, second accès rapide | En-tête de réponse Cache-Control |
| Cache CDN | Ressources statiques + une partie du HTML | Nœuds de périphérie mondiaux | Latence inter-régions réduite de plus de 50 % | Cloudflare、Akamai |
Beaucoup de gens se précipitent sur Redis et Memcached, alors que pour un site B2B indépendant, bien configurer le cache de pages résout déjà 80 % des problèmes de performance. Le cache d’objets est un bonus : à activer seulement au-delà de 50 000 visiteurs uniques par mois ou quand les requêtes en base ralentissent. Pour le lien entre CDN et cache à trois niveaux, voir Accélération mondiale par CDN et choix des nœuds et pour les seuils de performance acceptables, voir Optimiser les Core Web Vitals.
2. Cache de pages : comment stocker le HTML sans erreur
Le cache de pages est la couche la plus rentable, mais aussi celle où l’on se trompe le plus facilement. Les symptômes typiques d’une mauvaise configuration : après avoir envoyé une demande, un visiteur voit le contenu envoyé par le visiteur précédent ; ou un utilisateur connecté voit encore la page en version déconnectée. La cause : le cache de pages stocke aussi en fichier statique du HTML contenant du contenu dynamique.
La bonne méthode consiste à distinguer deux catégories selon l’URL et l’état de l’utilisateur : les pages publiques statiques (accueil, pages produit, articles de blog) passent par le cache de pages ; les pages dynamiques (après envoi d’un formulaire de demande, l’administration wp-admin, les pages après connexion, le panier) doivent impérativement l’ignorer. Les extensions de cache WordPress (WP Rocket, LiteSpeed Cache) gèrent toutes deux les règles « exclure une URL » et « ignorer le cache selon le cookie ».
| Type de page | Mise en cache | Durée de cache | Règle d’exclusion |
|---|---|---|---|
| Accueil, liste de produits | Cache | 1 heure à 4 heures | Exclure les utilisateurs connectés |
| Article de blog | Cache | 12 heures à 1 jour | Rafraîchir manuellement à chaque mise à jour |
| Page formulaire de demande de devis | Pas de cache | Aucune | Toujours revenir à l’origine |
| Page de confirmation d’envoi | Pas de cache | Aucune | Avec cookie de session |
| Back-office wp-admin | Pas de cache | Aucune | Exclure le cookie administrateur |
| Page de résultats de recherche | Cache court ou aucun cache | 5 minutes | Éviter de mettre en cache des termes de recherche différents |
Exemple concret : sur le site d’un fabricant d’équipements industriels, la page de détail d’un produit a pour URL /products/cnc-machine-a/. Son contenu ne change que tous les quelques mois, elle peut donc tout à fait être mise en cache 1 jour. En revanche, la page de confirmation d’envoi du formulaire de demande a pour URL /inquiry-thank-you/ : chaque visiteur doit y voir la confirmation de sa propre demande, elle ne doit jamais être mise en cache. Dans WP Rocket, ajoutez /inquiry-thank-you/ et /wp-admin/* à la liste Never Cache URL(s).
L’invalidation du cache est aussi un point clé du cache de pages. Vous modifiez un article de blog : comment le rendre visible en ligne immédiatement ? Deux méthodes : purger tout le cache manuellement à la publication, ou utiliser le rafraîchissement par URL pour ne vider que cet article. WP Rocket rafraîchit automatiquement le cache concerné lors de la mise à jour d’un article, mais beaucoup de pages personnalisées ne le déclenchent pas automatiquement : prenez l’habitude de cliquer sur Purge après chaque publication. crater lie l’invalidation du cache au processus de publication sur les sites d’export ; voir La stack technique de crater et ses quatre extensions maison.
3. Cache d’objets : comment réutiliser les résultats de requêtes en base
Quand le cache de page est touché, ni PHP ni la base de données ne s’exécutent, et le cache d’objets n’est donc pas sollicité. Mais quand le cache de page n’est pas touché — par exemple si vous venez de publier un nouvel article ou si vous accédez à une page dynamique qui ne doit pas être mise en cache — PHP doit interroger la base de données. Une page WordPress effectue en moyenne 12 à 20 requêtes en base, chaque requête passant par des E/S disque. Accumulées, les requêtes lentes peuvent faire dépasser la seconde à une page.
Le cache d’objets stocke ces résultats de requêtes dans Redis ou Memcached, et la prochaine requête identique est lue directement en mémoire. Redis s’installe sur un seul serveur, et WordPress s’y connecte via l’extension Redis Object Cache, sans modifier une seule ligne de code. Bien configuré, le temps de requête en base baisse de plus de 50 %, et le temps de réponse en cas de cache de page manqué passe de 1,5 seconde à moins de 0,5 seconde.
| Indicateur | Sans cache d’objets | Avec cache d’objets Redis | Gain |
|---|---|---|---|
| Requêtes en base par page | 12 à 20 par page | 2 à 5 par page | Réduction de 70 % à 80 % |
| Durée d’une requête | 5 à 20 ms (E/S disque) | 0,1 à 1 ms (mémoire) | 10 à 50 fois plus rapide |
| Temps de réponse en cas de cache de page manqué | 1 à 1,5 seconde | 0,3 à 0,5 seconde | Baisse de plus de 50 % |
| Utilisation CPU de MySQL | Plus de 80 % en pic | 30 % à 40 % en pic | Baisse de plus de la moitié |
Le cache d’objets n’est pas obligatoire. Pour un site B2B sous 10 000 UV par mois, la pression sur la base est faible, le cache de page absorbe déjà 95 % des requêtes, et le gain de Redis reste marginal. Quand faut-il y passer ? Deux signaux : d’abord, plus de 100 requêtes dépassant 1 seconde par jour dans le journal des requêtes lentes de MySQL ; ensuite, un délai de plusieurs minutes entre l’enregistrement d’un article dans l’administration et sa prise en compte côté public (cache d’objets mal invalidé). Pour les requêtes lentes et l’optimisation des index, voir Requêtes lentes et optimisation des index pour un site indépendant.
4. Cache navigateur : comment configurer les en-têtes de cache des ressources statiques
Le cache navigateur est la couche la plus simple à configurer des trois : elle ne touche à aucun programme côté serveur, il suffit d’ajouter quelques lignes d’en-têtes de réponse dans le serveur web (Nginx ou Apache). Le principe : quand le serveur renvoie du CSS, du JS ou des images, il ajoute dans l’en-tête HTTP Cache-Control: max-age=2592000 pour dire au navigateur « garde ce fichier en local pendant 30 jours ». Passé ce délai, toute nouvelle visite ne sollicite plus le serveur.
Mais voilà un conflit classique : avec une durée de cache longue, le site est rapide pour l’utilisateur ; mais si vous modifiez le CSS ou le JS, l’utilisateur garde l’ancienne version en local et voit une page au style cassé. La solution n’est pas de raccourcir la durée de cache, mais d’ajouter un numéro de version ou un hash au nom du fichier — par exemple style.css?v=2 ou style.abc123.css. Le contenu change, l’URL change, et le navigateur retélécharge automatiquement.
| Type de ressource | Recommandations Cache-Control | max-age | Stratégie de mise à jour |
|---|---|---|---|
| Images (jpg/png/webp) | public, max-age=31536000 | 1 an | Nom de fichier avec hash, on change l’image, on change le nom |
| Fichiers de police | public, max-age=31536000 | 1 an | Les polices ne changent pas, rien à modifier |
| Feuilles de style CSS | public, max-age=604800 | 7 jours | Nom de fichier avec numéro de version ?ver=2 |
| JavaScript | public, max-age=604800 | 7 jours | Nom de fichier avec numéro de version ?ver=2 |
| Pages HTML | no-cache, must-revalidate | Pas de cache | Vérification à chaque retour à l’origine |
| favicon.ico | public, max-age=604800 | 7 jours | Rarement modifié |
Un constat contre-intuitif : beaucoup craignent qu’avec un cache trop long, les visiteurs ne voient pas leurs modifications, alors ils fixent le max-age de toutes les ressources à 1 heure. Résultat : chaque visiteur retélécharge tous les CSS et JS à chaque visite, et le temps d’affichage du premier écran augmente. La bonne approche : voir large (1 an pour les images, 7 jours pour les CSS/JS), et gérer les mises à jour avec un hash de fichier ou un numéro de version. La fonction wp_enqueue_script de WordPress ajoute automatiquement un numéro de version, qui change dès que le thème ou une extension est mis à jour : aucune gestion manuelle n’est nécessaire.
Pour l’optimisation des images et la gestion des médias, voir Gestion des médias et compression des images. Sur un site multilingue, le cache des ressources statiques implique aussi l’interaction entre hreflang et le cache CDN, voir Mise en place du hreflang multilingue.
V. Stratégies d’invalidation du cache et conflits fréquents
Une fois le cache configuré, la grande question est : comment le faire expirer au bon moment ? Un cache qui n’est pas invalidé à temps affiche du contenu obsolète ; un cache invalidé trop souvent fait perdre le gain de performance. Sur un site indépendant, l’invalidation du cache intervient dans quatre cas courants : publier un nouvel article, mettre à jour une fiche produit, modifier les CSS/JS, envoyer un formulaire de demande. Chaque cas appelle sa propre stratégie.
| Situation | Périmètre d’invalidation | Méthode d’invalidation | Points d’attention |
|---|---|---|---|
| Publication d’un nouvel article de blog | Accueil + liste des articles + article | Rafraîchissement automatique par WP Rocket | Les pages de catégorie et d’étiquette doivent aussi être rafraîchies |
| Mise à jour du prix d’un produit | Fiche produit + page de liste | Purge manuelle des URL concernées | Ne pas tout purger, cela nuit aux performances |
| Modification des CSS/JS | Fichiers statiques concernés | Le changement de version prend effet automatiquement | Ne pas toucher au max-age, renommer le fichier |
| Envoi d’un formulaire de demande | La page du formulaire ne doit jamais être mise en cache | Règle d’exclusion par URL | La page de confirmation non plus |
| Refonte complète du site | Tout le cache | Purge All en un clic | À faire aux heures creuses |
| Mise à jour d’une extension ou d’un thème | Tout le cache | Purge automatique ou manuelle | Sauvegarder avant la mise à jour |
Deux conflits fréquents : d’abord, installer deux extensions de cache (WP Rocket et LiteSpeed Cache par exemple), qui modifient toutes les deux le .htaccess et la mémoire tampon de sortie, ce qui donne une page blanche ou un affichage cassé. La règle : une seule extension de cache sur tout le site. Ensuite, le conflit entre cache de page et état de connexion : un utilisateur connecté à l’administration voit toujours la version en cache de la page publique, avec une barre de navigation erronée. La solution : l’extension de cache détecte le cookie de connexion et saute le cache.
Une fois la stratégie de cache en place, il faut la surveiller en continu : vérifier une fois par mois le taux de hit et le LCP. Une baisse soudaine du taux de hit vient généralement de quelqu’un qui a modifié la structure des URL ou ajouté des liens avec des paramètres aléatoires. La liste de surveillance et d’alerte se trouve Surveillance et alertes du site, et les tâches de maintenance courantes Les six tâches mensuelles de la maintenance d’un site. Il faut aussi refaire un exercice de sauvegarde et de restauration après chaque changement de configuration du cache, voir Sauvegarde et restauration : s’entraîner à réagir.
FAQ — Questions fréquentes
Un site WordPress indépendant doit-il forcément installer une extension de cache ?
Peut-on mettre en cache la page du formulaire de contact ?
Quand faut-il passer au cache objet Redis ?
Quelle durée choisir pour le cache navigateur ?
Que faire si les visiteurs ne voient pas les modifications après la mise en cache ?
Le cache de pages et le cache CDN entrent-ils en conflit ?
Pour conclure
En matière de cache, les débutants tombent souvent dans l’un des deux extrêmes : soit ils ne configurent rien et chaque page exécute PHP et la base de données à la volée, avec un premier affichage qui dépasse les 4 secondes ; soit ils configurent trop agressivement et mettent aussi en cache les pages de formulaire, si bien que l’utilisateur voit la soumission de quelqu’un d’autre. La bonne approche, c’est de procéder par couches : mettre hardiment en cache les pages statiques, ne jamais mettre en cache les pages dynamiques, et appliquer aux ressources statiques un cache longue durée avec numéro de version.
Trois étapes pour passer à l’action. Première étape : installez une extension de cache de page (WP Rocket ou LiteSpeed Cache, au choix) et excluez les pages de formulaire ainsi que wp-admin. Deuxième étape : configurez les en-têtes Cache-Control de Nginx — 1 an pour les images, 7 jours pour le CSS et le JS, aucun cache pour le HTML. Troisième étape : au-delà de 50 000 visiteurs uniques par mois, ajoutez le cache objet Redis. Une fois ces trois étapes terminées, le LCP passe généralement sous la seconde, sans risque de mélanger le contenu en cache.
Une phrase à retenir : le cache est le levier de performance d’un site indépendant — le cache de page fait gagner 80 % du temps, le cache objet soulage la base de données, le cache navigateur accélère les visites de retour. Chaque couche gère son périmètre, et surtout, ne laissez pas les pages de formulaire entrer dans le cache.