Un CDN distribue certaines ressources depuis un réseau de serveurs, plutôt que de demander systématiquement leur envoi à l’hébergement d’origine. Son cache peut éviter des transferts répétés. Il ne corrige pas à lui seul une page trop lourde, un serveur lent ou une requête mal conçue.
L’objectif est de servir plus efficacement les contenus partageables, sans afficher une information périmée ni mélanger les données de visiteurs différents. Avant d’activer une règle générale, identifie ce qui peut être conservé et ce qui doit rester propre à chaque session.
1. Identifier ce qui ralentit réellement le site
Examine des pages représentatives et leurs ressources : images, polices, scripts et réponse du serveur. Compare une première visite et une visite suivante, sur ordinateur et mobile. Note les conditions du test pour ne pas confondre un cache déjà chaud avec une amélioration durable.
Si une image est inutilement lourde, réduis d’abord son poids et adapte sa taille d’affichage. Si le serveur attend une requête externe, le CDN ne règle pas forcément cette dépendance. Le guide d’optimisation de la vitesse WordPress aide à distinguer diagnostic, corrections et vérification.
Mesure une page avec ses fonctions réelles. Une page rapide dont le formulaire ne fonctionne plus n’est pas une amélioration. Définis les parcours à préserver avant de modifier la distribution des contenus.
2. Séparer les ressources publiques des données privées
Une image publique identique pour tous les visiteurs est un bon point de départ. Un panier, un compte connecté ou une prévisualisation demandent une analyse différente. Un cache partagé ne doit pas redistribuer les données d’un utilisateur à un autre.
Le comportement dépend du fournisseur et de la configuration. Le comportement par défaut du cache Cloudflare ne met pas automatiquement en cache les pages HTML ou les réponses JSON. Les en-têtes de réponse, les cookies et les règles configurées influencent aussi l’éligibilité.
- Commence par les fichiers publics dont le contenu est identique pour tous.
- Exclus explicitement les espaces privés, les aperçus et les parcours sensibles.
- Vérifie les exceptions liées à la connexion, aux cookies et aux paramètres d’adresse.
- Ne force pas la mise en cache d’une réponse privée pour améliorer un score.
3. Définir des règles limitées et vérifiables
Une règle doit préciser les adresses concernées, les exceptions et la durée de fraîcheur. Distingue le cache du navigateur de celui du réseau : vider l’un ne signifie pas que l’autre a été actualisé.
Les réglages des règles de cache Cloudflare distinguent notamment le contournement du cache, l’éligibilité et la durée de conservation. Une ressource déclarée éligible n’est pas nécessairement stockée. Écraser les instructions du serveur doit être un choix explicite et testé.
Vérifie aussi ce qui distingue deux réponses : langue, paramètres, utilisateur connecté ou autre variation réelle. Ignorer tous les paramètres pour augmenter le taux de cache peut servir le mauvais contenu. Évite les règles globales tant que ces différences ne sont pas documentées.
4. Prévoir l’actualisation après publication
Teste une correction de texte et le remplacement d’une image. Observe la version reçue depuis le navigateur et depuis le réseau. La procédure de publication doit expliquer comment rendre une correction visible sans vider inutilement tous les caches.
Une ressource portant un nom versionné peut faciliter la distribution d’une nouvelle version. Pour les pages conservées sous la même adresse, prévois une actualisation ciblée et vérifie son effet. Note les délais de fraîcheur acceptables selon le contenu.
Une ancienne page encore visible peut devenir problématique si elle présente une disponibilité, un prix ou une instruction modifiée. Le bon réglage n’est donc pas une durée unique appliquée à tout le site : il dépend des contenus et de leur fréquence de changement.
5. Tester les parcours, pas seulement les en-têtes
Sur une copie de test ou un périmètre maîtrisé, vérifie la navigation, les formulaires et les connexions. Pour une boutique, contrôle séparément le panier, le paiement et la confirmation. Utilise deux sessions distinctes pour repérer un éventuel mélange de données.
Vérifie les réponses normales, les redirections et les erreurs. Une page introuvable ne doit pas rester servie après sa correction à cause d’une durée de cache mal choisie. Contrôle aussi l’accès aux fichiers et le fonctionnement sur mobile.
Les en-têtes indiquent une partie du comportement, mais ne prouvent pas à eux seuls que les parcours fonctionnent. Les tests doivent confirmer le contenu reçu et les résultats attendus, sans envoyer de commandes ou de messages réels non prévus.
6. Déployer progressivement et garder un retour arrière
Conserve la configuration précédente, change un périmètre limité et compare avant et après dans les mêmes conditions. Si le changement concerne les DNS, vérifie les services utilisant le domaine avant toute modification, notamment le courrier et les accès techniques.
Définis les situations qui imposent un retour arrière : contenu privé exposé, mauvaise version persistante ou parcours essentiel défaillant. Un CDN n’est ni une sauvegarde du site ni une garantie de disponibilité permanente.
La maintenance du site peut inclure le suivi de ces règles et les vérifications convenues. Pour étudier une amélioration, envoie-moi ton site et les lenteurs observées. Le diagnostic permettra de choisir une correction proportionnée, sans promesse automatique de classement ou de ventes.
