Décrire le défaut au moment où il apparaît
Après activation de Remove Unused CSS dans WP Rocket, le menu ouvert perd son fond, une fenêtre ne se positionne plus ou les boutons changent de taille. Au premier chargement, la page peut paraître correcte puis se dégrader plus tard. Choisissez une adresse et un état précis. Notez l’appareil, la largeur, le geste et la zone touchée. Une capture du menu fermé ne vérifie pas le style du menu ouvert. Gardez un exemple de l’état attendu avec les mêmes contenus.
Relevez les options d’optimisation changées au même moment. Une suppression de CSS, un report de JavaScript et une ancienne page mise en cache peuvent produire des symptômes proches. Commencez par attribuer le défaut à une seule fonction sur une copie ou un environnement d’essai prévu par l’équipe. Vous avez besoin de pouvoir modifier WP Rocket et inspecter les styles dans le navigateur. Le résultat recherché est un affichage complet après génération, avec une exception dont vous pouvez expliquer le rôle. Une amélioration provisoire juste après une purge doit encore être vérifiée.
Préparer l’essai selon les contraintes du service
Conservez les réglages WP Rocket et les exceptions déjà présentes. Choisissez une page témoin et un scénario qui reproduit le défaut. La génération du CSS utilisé repose sur un service qui visite la page. Une copie privée protégée par authentification HTTP ou déclarée locale peut ne pas être traitée comme le site public. Faites préparer par le responsable un environnement de test autorisé qui respecte ces contraintes, avec des données et effets externes neutralisés. La lecture d’une page existante aide au relevé initial, mais ne remplace pas cette répétition de modification.
Relevez aussi les autres couches de cache qui servent la page. Préparez une méthode d’invalidation ciblée et conservez les règles initiales. Les versions connectées peuvent recevoir un traitement différent des visiteurs. Pour la comparaison, utilisez donc un profil de test sans connexion et un état de consentement connu. Gardez le même contenu, les mêmes dimensions et le même geste pendant les essais. Si l’interface ajoute des éléments après ouverture, attendez qu’ils soient présents avant de comparer leurs styles. Notez le moment exact où le rendu attendu disparaît.
Confirmer la fonction responsable par comparaison
Sur l’environnement d’essai, vérifiez la page avec Remove Unused CSS désactivé, puis avec cette fonction seule parmi les transformations suspectes. Conservez les autres valeurs pour les rétablir ensuite. La documentation propose également le paramètre nowprocket pour examiner une réponse qui contourne les effets de WP Rocket. Ce paramètre ne contourne pas nécessairement les caches d’hébergement ou les autres outils du site. Vérifiez la réponse reçue avant d’en tirer une conclusion. Comparez la page publique normale à cette version avec le même geste.
Si le problème existe aussi quand la suppression est désactivée, reprenez le chargement des feuilles ou le script qui ajoute les classes. Si le défaut apparaît seulement après application du CSS utilisé, poursuivez sur la génération et les règles manquantes. Répétez une régénération contrôlée pour écarter un fichier ancien. Gardez l’adresse, le réglage et le résultat de chaque comparaison. Quand plusieurs options ont été changées ensemble, réintroduisez-les progressivement après avoir isolé la suppression. Une option de minification voisine peut aussi modifier le résultat et demande son propre essai.
Attendre le CSS utilisé effectivement appliqué
Dans les réglages de WP Rocket, la fonction se trouve dans l’optimisation des fichiers, dans la partie consacrée au CSS. La génération est asynchrone. Une visite peut déclencher le traitement puis recevoir encore la version précédente ou un rendu de repli. Après une modification d’exception, attendez que le résultat soit généré et réellement intégré à la page publique. La documentation indique le bloc de style portant l’identifiant wpr-usedcss comme repère de cette application. Consultez le code source de la réponse et comparez le résultat sur une nouvelle navigation.
Pour une seule page, utilisez l’action de nettoyage du CSS utilisé de cette URL lorsqu’elle est proposée dans la barre d’administration. Conservez le périmètre d’un éventuel nettoyage plus large. Relevez les avis d’administration et les erreurs de génération. Si le marqueur attendu n’apparaît jamais, vérifiez le déclenchement des tâches et l’accès du service à la page. Ne jugez pas la qualité d’une exception à ce stade. Une page correcte pendant que les feuilles originales sont encore employées peut redevenir incorrecte lorsque le nouveau résultat s’applique.
Retrouver la règle absente dans le navigateur
Ouvrez côte à côte l’état correct et l’état optimisé. Dans chacun, sélectionnez l’élément qui présente le défaut puis inspectez les styles calculés et les règles qui les produisent. Cherchez la propriété qui explique l’écart, par exemple position, display, fond ou police. Relevez le sélecteur et la feuille d’origine de la règle correcte. Si la règle existe aussi dans la version optimisée mais est barrée, cherchez la règle qui la remplace. Une exception de conservation ne corrige pas une priorité CSS déjà différente.
Vérifiez l’élément et ses parents. Le style peut dépendre d’une classe ajoutée à un conteneur lorsque le menu s’ouvre. Comparez cette classe dans les deux états. Si la classe manque entièrement, vérifiez le JavaScript qui doit l’ajouter avant d’agir sur la sélection de CSS. Si elle est présente mais que la règle correspondante a disparu du résultat généré, vous disposez d’une exception candidate. Conservez un sélecteur stable et limité au composant. Un identifiant aléatoire produit à chaque chargement ne donne pas une base fiable pour une règle de conservation permanente.
Ajouter une exception limitée dans CSS Safelist
Dans la zone CSS Safelist associée à Remove Unused CSS, ajoutez le sélecteur identifié en conservant les exceptions existantes. Placez une entrée par ligne selon l’interface de votre version. Le champ accepte notamment des classes, identifiants et références de feuilles. L’exemple ci-dessous suppose que le menu utilise une classe stable menu-ouvert et un panneau menu-panneau. Adaptez ces deux noms aux valeurs réellement observées. Cette ligne se place dans la liste de conservation, et non dans le CSS additionnel du thème.
Enregistrez puis régénérez le résultat pour la page témoin. Attendez son application et vérifiez que la règle utile se retrouve dans le CSS servi. Rejouez ensuite le geste d’ouverture. Si le défaut persiste, comparez la propriété à nouveau. Élargir l’exception à toute la page sans identifier l’écart peut cacher une deuxième cause. Si l’exception fonctionne, vérifiez un autre usage de ce menu et le rendu fermé. Conservez la valeur ajoutée avec sa justification. Pour annuler, retirez cette seule ligne puis répétez la génération et le contrôle dans les mêmes conditions.
.menu-ouvert .menu-panneauVérifier les états dynamiques du même composant
Un menu, un accordéon ou un formulaire peut utiliser plusieurs classes selon son état. Après la première correction, testez l’ouverture, la fermeture, l’erreur de saisie et le succès dans le circuit de test prévu. Vérifiez aussi le focus clavier et les variantes de largeur. Pour chaque état qui reste incorrect, comparez la règle utile dans le rendu de référence et dans celui qui applique le CSS utilisé. Ajoutez seulement les exceptions confirmées. Une liste fondée sur les classes supposées d’un thème peut devenir très large sans couvrir l’état manquant.
Si un nom de classe contient une partie variable, retrouvez la règle stable du composant ou la feuille qui la fournit. La documentation du fournisseur propose des alternatives de conservation lorsque les sélecteurs changent ou qu’un script dépend de la présence d’une feuille. Faites appliquer ces adaptations par le mainteneur du code concerné, après une comparaison ciblée. Si le composant change fréquemment selon les données de la session, une exclusion de page peut mieux correspondre au besoin. Choisissez à partir du coût de maintenance et du résultat fonctionnel, en gardant les autres pages comme témoins.
Exclure une page qui nécessite les feuilles complètes
Pour quelques pages dont les états sont difficiles à couvrir, ouvrez l’écran d’édition WordPress et cherchez le panneau WP Rocket Options. La documentation indique qu’on peut y décocher Remove Unused CSS pour le contenu concerné, puis mettre la page à jour. Relevez la valeur initiale et vérifiez que vous modifiez la page effectivement servie. Un modèle d’archive ou une page générée sans objet éditable peut demander un mécanisme différent. Identifiez le type de document avant de choisir une règle.
Après l’enregistrement, invalidez la réponse concernée selon la procédure du site, puis ouvrez-la comme un visiteur. Vérifiez le chargement des feuilles et le comportement du composant. Ouvrez aussi une autre page qui doit conserver l’optimisation et confirmez qu’elle reçoit encore son résultat généré. Pour revenir, réactivez l’option de cette page et vérifiez après la nouvelle génération. Si vous avez conservé des exceptions globales pendant l’essai, décidez lesquelles restent justifiées pour les autres pages avant de les retirer. Un composant partagé peut encore dépendre d’une exception même après l’exclusion de sa page principale.
Examiner l’accès du générateur quand le défaut revient
Un CSS utilisé anormalement court ou un rendu très dégradé peut venir de la page que le service a réellement analysée. Rapprochez l’heure de génération des journaux de protection et des éventuelles pages de défi. La documentation WP Rocket signale ce cas. Si le service reçoit une page de blocage à la place du document, il peut produire un résultat qui ne correspond pas à la page attendue. Gardez le message d’administration et une preuve de la réponse reçue par le générateur lorsque le responsable peut l’obtenir.
Faites confirmer une règle d’accès limitée au service légitime à partir des informations officielles courantes. La personne qui gère la protection doit conserver la portée et la justification de l’exception. Un nom d’agent utilisateur seul ne suffit pas pour identifier un service. Vérifiez aussi la réponse derrière un éventuel proxy et les paramètres de requête documentés. Si la génération ne progresse pas du tout, examinez les tâches et la joignabilité dans le périmètre autorisé. Le retour attendu est une analyse du vrai document, puis un CSS généré qui correspond à ses composants.
Rétablir l’exception et les réglages d’origine
Gardez le contenu initial de la liste de conservation et les options modifiées pendant le diagnostic. Si la nouvelle exception cause un autre défaut ou n’apporte aucun résultat, retirez-la et régénérez la page témoin. Si vous avez testé une exclusion de page, remettez son état d’origine et attendez que la réponse finale corresponde à cet état. Un retour de réglage sans régénération peut laisser un ancien résultat visible et donner l’impression que l’annulation a échoué.
Si le rendu est critique et que l’exception ciblée ne suffit pas, utilisez l’exclusion documentée du contenu concerné après vérification sur l’environnement d’essai. Notez les éléments qui nécessitent encore une analyse du fournisseur. Pour une correction de règle d’accès au générateur, conservez aussi la règle de protection précédente et son propriétaire. La procédure de retour doit préciser quel résultat généré doit être retiré et quelle réponse publique vérifier après la modification. Cela évite de confondre une ancienne réponse conservée avec le réglage courant. Vérifiez enfin une page voisine afin de détecter une modification trop large.
Valider le résultat après une nouvelle génération
Préparez un petit ensemble de pages et d’états. Incluez la page qui échouait, un autre usage du composant et une page hors de l’exclusion. Vérifiez dans une fenêtre visiteur et à une largeur représentative du défaut. Si le problème apparaissait sur téléphone, refaites aussi le geste sur l’appareil concerné. Gardez les mêmes données de test.
- Confirmez que le CSS utilisé vient d’être généré et qu’il est appliqué dans la réponse reçue.
- Vérifiez la règle utile et le rendu de l’état qui échouait.
- Testez ouverture, fermeture et interaction clavier du composant.
- Contrôlez les variantes mobiles ou les messages d’erreur qui ajoutent des classes.
- Vérifiez le périmètre de l’exclusion et la présence de l’optimisation sur la page témoin.
- Recommencez après une nouvelle invalidation ciblée pour vérifier que la correction survit à la génération. Conservez les réglages d’origine avec la liste des états validés et ceux qui restent à examiner.
Documenter les exceptions avec leur composant
Pour chaque entrée de CSS Safelist, notez le composant, la propriété manquante et une adresse témoin. Indiquez le geste qui rend la règle nécessaire. Lors d’une refonte, vérifiez que la classe existe encore avant de conserver l’exception. Une classe ajoutée pour un ancien module peut devenir inutile après son remplacement. Pour une exclusion de page, notez pourquoi le rendu dynamique exige cette voie et dans quelles conditions l’équipe pourra refaire un essai.
WP Rocket est un produit commercial. Le diagnostic vise une installation qui dispose déjà de la fonction et d’une licence valide, condition indiquée par sa documentation. Vérifiez la version réellement installée lorsque les menus diffèrent. La preuve de correction comprend l’état final généré et les interactions testées. Conservez les sources et la date de contrôle technique avec le dossier afin de reprendre la vérification lorsque l’éditeur modifie le mécanisme de génération. Lorsque le problème touche un seul état, gardez une description précise du geste. Un contrôle qui s’arrête au chargement initial ne couvre pas une classe ajoutée à la première interaction.
