Astral 360 WSA — Accélérateur de sites

Optimisation et outils de développement

Utiliser les outils de développement du navigateur pour identifier les cookies et URI à exclure de la cache.

Une bonne configuration de WSA dépend de votre connaissance du comportement réel de votre site : quels cookies utilise-t-il pour identifier les utilisateurs ? Quelles URL nécessitent du contenu en temps réel ? Cette page vous guide à travers l'utilisation des outils de développement du navigateur pour récupérer ces informations.

💡 Le tutoriel utilise Google Chrome pour les captures et les raccourcis, mais Firefox et Edge ont des outils similaires accessibles aux mêmes raccourcis clavier.

1. Préparer l'outil de développement

L'outil de développement vous aidera tout au long du tutoriel à obtenir des informations ordinairement inaccessibles sur votre site. Avant de commencer, vous devez vous rendre sur votre site et ouvrir l'outil.

1.1 Ouvrir l'outil

Dans Google Chrome, vous avez deux options :

  • Appuyez sur Ctrl + Maj + I (Windows / Linux) ou Cmd + Option + I (Mac) sur votre clavier.
  • Ou cliquez sur les 3 points en haut à droite, allez dans Plus d'outils, et cliquez sur Outils de développement.

1.2 Désactiver la cache du navigateur

Une fois l'outil ouvert, dirigez-vous dans l'onglet Network (Réseau) et cochez la case Disable cache (Désactiver le cache).

Cette case évite que le navigateur garde une copie de la page localement, ce qui fausserait l'analyse. Vous voulez voir ce qui se passe vraiment entre votre navigateur et le serveur, sans optimisations locales qui masqueraient le diagnostic.

⚠️ N'oubliez pas que la case Disable cache fonctionne uniquement quand l'outil de développement est ouvert. Dès que vous le fermez, la cache navigateur reprend.

2. Les témoins (cookies)

2.1 Qu'est-ce qu'un témoin ?

Les témoins (en anglais « cookies ») sont omniprésents lors de la navigation sur le web. Ce sont des informations sous forme de texte enregistrées dans votre navigateur afin d'aider à vous identifier dans diverses occasions lorsque vous naviguez sur le web. Ils ont une durée de vie qui peut aller de quelques minutes à quelques mois.

Un des exemples de leurs utilisations est pour identifier un utilisateur connecté.

2.2 Pourquoi les témoins comptent pour la cache

En prenant en compte que c'est le témoin qui garde l'authentification active, si l'utilisateur perd son témoin, il sera automatiquement déconnecté.

D'où l'importance de ne pas mettre dans la cache tout ce qui se trouve sur votre site. Une page avec un témoin important dans la cache pourrait causer :

  • Partages de sessions entre différents utilisateurs — une personne pourrait voir le panier d'achats d'un autre.
  • Empêchement de connexion — en plaçant un témoin vide dans la mémoire tampon, le site web va toujours croire qu'un visiteur n'a jamais entré ses informations de connexion.

2.3 Vérification des témoins sur votre site

Maintenant que vous avez une meilleure idée de l'utilisation des témoins sur le web, regardons ceux qu'utilise votre site :

  1. Rendez-vous sur la page d'accueil de votre site.
  2. Ouvrez l'outil de développement (F12).
  3. Assurez-vous d'être dans l'onglet Network.
  4. Cliquez sur le sous-onglet Doc (filtre pour ne voir que les documents HTML).
  5. Rafraîchissez la page (Ctrl + R).

Dans la majorité des cas, il ne devrait y avoir qu'une seule ligne dans la liste. Dans les cas où plusieurs lignes y figureraient, choisissez la ligne qui porte le nom de la page où vous êtes actuellement.

2.4 Lire la liste des cookies

Lorsque vous cliquez sur la ligne, une page apparaît sur la droite. Sur cette page, allez dans l'onglet Cookies.

Vous y trouverez une liste des témoins actuellement utilisés par votre site. Prenez-les en notes et classez-les dans deux catégories :

Catégorie « De base »

Les témoins toujours présents sur votre site et qui ne devraient pas causer de problème avec la mise en cache. Exemples typiques :

  • _ga, _gid — Google Analytics (suivi statistique uniquement).
  • cookielawinfo-* — Consentement RGPD.
  • wp_woocommerce_session_* — Session WooCommerce vide.

Ces témoins n'identifient pas un utilisateur connecté ou ne contiennent pas de données privées — la cache peut ignorer leur présence.

Catégorie « Important »

Les témoins qui identifient un utilisateur ou contiennent des données utilisateur. Naviguez sur les pages qui selon vous nécessiteraient l'ajout de nouveaux témoins :

  • Page de connexion — connectez-vous, puis observez les nouveaux cookies apparaître.
  • Panier d'achats — ajoutez un produit, voyez les nouveaux cookies.
  • Formulaire web — remplissez et soumettez, voyez les nouveaux cookies.
  • Espace membre — naviguez dans votre compte connecté.

Notez ces nouveaux témoins dans la catégorie « Important », puisqu'il ne faudra en aucun cas mettre en cache les pages contenant ces témoins afin de garantir le bon fonctionnement du site.

Exemples typiques :

  • wordpress_logged_in_* — Session WordPress connectée.
  • PHPSESSID — Session PHP générique.
  • woocommerce_cart_hash — Panier WooCommerce actif.
  • customer_* — Cookies de session client e-commerce.

2.5 Ajouter les cookies à WSA

Les témoins recueillis dans la catégorie « Important » devraient être placés dans la liste de cookies à ne pas placer dans la cache :

  • Mode simple : ces exclusions sont gérées automatiquement par les profils — le profil Boutique en ligne connaît déjà les cookies WooCommerce / PrestaShop / Magento.
  • Mode avancé : ouvrez l'éditeur d'un domaine, allez à l'onglet Dynamique, dans la section Cookie bypass list, ajoutez chaque nom de cookie un par un avec le bouton +.

💡 Le wildcard * en fin de nom est supporté. Par exemple, wordpress_logged_in_* match tous les cookies dont le nom commence par wordpress_logged_in_ (utile car WordPress ajoute un hash unique au nom).

3. Les adresses URI

3.1 Qu'est-ce qu'une URI ?

Une URI (Uniform Resource Identifier) est la partie du lien de votre site web qui représente une page, après le nom de domaine.

Pour un site bâti avec WordPress, la page d'administration avec le domaine sera monsite.com/wp-login.php. L'URI à considérer est alors /wp-login.php — on garde seulement ce qui suit le domaine.

3.2 Quelles URI exclure de la cache

Lorsqu'on parle d'ajouter du cache sur un site, il y a sûrement quelques pages où il est préférable de ne rien cacher. Parmi ces pages, voici quelques exemples où il est préférable de s'abstenir d'ajouter une mise en cache :

Type de page Exemples WordPress Exemples WooCommerce / e-commerce
Administration /wp-admin, /wp-login.php /admin, /dashboard
Formulaire dynamique /contact (parfois) /checkout, /cart
Espace membre /account, /profile /my-account, /customer/*
Aperçu de contenu /?p=preview /preview

Cependant, il reviendra à vous de juger de l'utilité de ne pas mettre une page en cache. Par exemple, sur un blog, une page /contact qui se contente d'afficher un formulaire statique peut tout à fait être cachée — c'est uniquement le traitement du formulaire (la soumission POST) qui ne doit pas l'être, et celui-là n'est jamais caché de toute façon (WSA ne cache que les requêtes GET).

3.3 Comment noter l'URI d'une page

Pour noter l'adresse de la page, il vous suffit de vous y rendre et de regarder après la barre oblique du nom de domaine :

URL complète dans le navigateur URI à noter
https://exemple.com/wp-login.php /wp-login.php
https://shop.exemple.com/cart/ /cart/
https://blog.exemple.com/?p=preview&id=42 /?p=preview
https://site.com/admin/dashboard/users /admin/dashboard/users

📝 Si vous avez plusieurs sous-dossiers, vous pouvez simplement bypass le dossier parent : /admin couvre tous les chemins commençant par /admin/. Pas besoin d'énumérer chaque sous-page.

3.4 Ajouter les URI à WSA

Les pages recueillies devraient être ajoutées dans la liste d'URI à ne pas placer dans la cache :

  • Mode simple : ces exclusions sont gérées automatiquement par les profils.
  • Mode avancé : ouvrez l'éditeur d'un domaine, allez à l'onglet Dynamique, dans la section URI bypass list, ajoutez chaque URI un par un avec le bouton +.

📝 Important : il faut placer seulement ce qui suit le domaine. Par exemple, pour la page https://exemple.com/wp-login.php, on garde seulement /wp-login.php.

4. Vérifier que la cache fonctionne (nouveauté WSA 2.2)

Une fois vos cookies et URI configurés, vérifiez que la cache agit comme prévu :

4.1 Activer l'en-tête de status de cache

WSA peut envoyer un en-tête X-Nginx-Cache-Status sur chaque réponse, qui vous indique en temps réel ce qui se passe :

  • Mode simple : activé par défaut, rien à faire.
  • Mode avancé : onglet Basique → toggle Show cache status header sur Activé.

4.2 Lire l'en-tête dans DevTools

  1. Outil de développement → onglet Network.
  2. Rafraîchissez la page de votre site.
  3. Cliquez sur la première ligne (la page HTML elle-même).
  4. Dans le panneau droit, allez à Headers (En-têtes) → section Response Headers.
  5. Cherchez X-Nginx-Cache-Status.

4.3 Interpréter la valeur

Valeur Signification Action
HIT Servi depuis la cache. Parfait ! Aucune.
MISS Première visite, la page est maintenant en cache. Rafraîchir une 2e fois → devrait passer HIT.
BYPASS Cache contournée délibérément (cookie, URI exclu, Cache-Control). Vérifier que c'est intentionnel. Si non, voir 4.4.
EXPIRED Entrée périmée, fresh fetched. Normal après le TTL expiré.
REVALIDATED Re-validé avec Apache (304). Normal.

4.4 Si vous voyez toujours BYPASS

Causes typiques :

  • Un cookie est setté sur chaque page : votre app envoie un Set-Cookie à chaque visite. Vérifiez l'onglet Cookies dans Network pour identifier lequel.
  • L'URL matche une URI d'exclusion : vérifier vos URI bypass lists dans WSA.
  • L'app envoie Cache-Control: no-cache : visible dans l'onglet Headers → Response Headers. Activez Bypass Cache-Control dans WSA pour ignorer cette directive.

4.5 Comparer cache HIT vs MISS pour mesurer le gain

Dans l'onglet Network, la colonne Time affiche la durée de chaque requête :

  • Sans cache (MISS) : typiquement 200-1000 ms.
  • Avec cache (HIT) : typiquement 5-50 ms.

Le ratio est votre gain mesuré. Un site WordPress typique passe de 600 ms (MISS) à 15 ms (HIT) — 40× plus rapide.

5. Protection contre les robots (nouveauté WSA 2.2)

Le mode avancé WSA 2.2 inclut maintenant 8 catégories de protection contre les robots indésirables. Vous pouvez vérifier dans les logs serveur quels robots visitent votre site :

5.1 Voir les robots bloqués par WSA

Le tableau de bord WHM affiche un Top Offenders avec les 10 User-Agents les plus bloqués sur les 24 dernières heures.

Côté cPanel client : ouvrez le mode avancé, dans l'onglet Bot Protection, chaque catégorie est en mode Server default par défaut. Si vous voyez des robots inattendus dans votre log Apache, vous pouvez :

  1. Forcer une catégorie en Bloqué sur votre domaine.
  2. Ajouter le User-Agent spécifique à la liste de cette catégorie.

5.2 Identifier un robot dans vos logs

# Voir les User-Agents les plus fréquents sur votre site
cd /home/<utilisateur>/access-logs
sort *.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

Les User-Agents qui apparaissent en haut de la liste sans correspondance avec un vrai navigateur (Chrome, Firefox, Safari, mobiles) sont vos candidats à blocage.

6. Vérifier le format de compression servi

WSA active automatiquement la compression Gzip et, si installé par votre hébergeur, Brotli. Pour vérifier laquelle est servie à votre navigateur :

  1. Network → cliquez sur la page HTML.
  2. Headers → Response Headers → Content-Encoding.
Valeur Compression
br Brotli (idéal, ~20% plus petit que gzip).
gzip Gzip (standard, large compatibilité).
(absent) Pas de compression (fichier déjà compressé, ou erreur de config).

7. Vérifier que HTTP/3 fonctionne (nouveauté WSA 2.2)

Si votre hébergeur a activé HTTP/3 sur le serveur :

  1. Network → cliquez sur n'importe quelle ligne.
  2. Headers → Response Headers → cherchez Alt-Svc.

Si vous voyez Alt-Svc: h3=":443"; ma=86400, h2=":443"; ma=86400, votre serveur annonce HTTP/3.

Pour vérifier que votre navigateur l'utilise :

  1. Rechargez la page une fois (pour que Chrome capte l'annonce Alt-Svc).
  2. Rechargez à nouveau.
  3. La colonne Protocol dans Network doit afficher h3 au lieu de h2 ou http/1.1.

💡 Si la colonne Protocol n'apparaît pas, faites un clic droit sur les entêtes de colonne de Network et activez Protocol.

8. Workflow recommandé pour un nouveau site

Un workflow complet pour configurer WSA sur un nouveau site en utilisant les outils de développement :

  1. Installer WSA en mode simple avec le profil le plus adapté (Daily pour un blog, Store pour une boutique, etc.).
  2. Naviguer sur votre site dans toutes ses zones importantes :
    • Page d'accueil
    • Page produit / article
    • Page de connexion / inscription
    • Panier / checkout (si applicable)
    • Page de contact / formulaire
  3. Inventorier les cookies apparus à chaque étape (les sites e-commerce génèrent de nouveaux cookies au fil de l'interaction).
  4. Vérifier les X-Nginx-Cache-Status sur les pages publiques (devrait être HIT) et sur les pages connectées (devrait être BYPASS).
  5. Si une page connectée renvoie HIT, c'est un risque de fuite — basculer en mode avancé et ajouter le cookie manquant à la liste de bypass.
  6. Mesurer les temps de réponse sur 5-10 pages pour confirmer le gain.

9. Pour aller plus loin