Configurer le CSS critique

Ce que fait le module — et ce qu'il ne fait pas

Pour chaque modèle de page, Kakapo récupère via HTTP une véritable page d'exemple de votre site (uniquement dans l'administration ou par cron, jamais pendant la construction de page d'un visiteur), lit directement sur le disque les feuilles de style locales qui y sont liées et confronte chaque règle au document avec DOMXPath. Il en résulte deux choses : le CSS critique, placé en ligne dans le head, et la liste des règles qui n'ont touché aucun élément sur ce modèle.

Rien n'est rendu au passage. Il n'y a ni navigateur, ni fenêtre d'affichage, ni position de défilement. « Visible en haut » est une approximation suivant une règle rendue publique : tous les éléments situés sous body sont numérotés, les 30 premiers pour cent (valeur par défaut, réglable entre 5 et 90) comptent comme étant en haut, auxquels s'ajoute tout ce qui se trouve à l'intérieur des repères saisis. Sont toujours repris html, body, :root et @font-face ainsi que les @keyframes qu'une règle critique désigne via animation. Les règles qui n'agissent que par des états (:hover, :focus, :active) restent dehors, tout comme @media print. Là où le procédé atteint sa limite, il arrondit vers le haut : la règle est considérée comme touchée. Quelques kilo-octets de trop coûtent moins cher qu'une règle manquante et un scintillement.

Vérifier les conditions préalables avant d'analyser

Deux choses doivent être en place. Premièrement l'extension PHP dom/libxml — le module ne la vérifie pas via class_exists(), il construit un document miniature et l'interroge réellement. La raison : certains hébergeurs définissent disable_classes=DOMDocument, class_exists() continue alors de répondre « oui », mais le new échoue. Si l'extension manque, « Analyser » et « Rafraîchir quotidiennement » sont bloqués et la raison est indiquée à côté.

Deuxièmement, le loopback : le site doit pouvoir s'atteindre lui-même via HTTP. C'est à cela que sert le bouton « Vérifier le loopback » dans la zone Conditions préalables ; il retient le code HTTP, la taille de la réponse et la durée. S'il échoue, toute analyse échoue — les causes typiques sont un pare-feu devant le site, une protection Basic Auth sur l'environnement de préproduction ou un nom d'hôte qui ne se résout pas en interne.

Ce que l'analyse ne peut pas lire n'est pas différé non plus : les feuilles de style provenant d'hôtes tiers, d'un CDN ou de Google Fonts restent bloquantes pour le rendu, sans changement. C'est la voie lente, mais sûre.

Procéder modèle par modèle

Il existe sept modèles : Accueil, Page du blog, Article seul, Page statique, Archive, Résultats de recherche et Page d'erreur 404. Chacun est analysé et validé séparément. Si votre page d'accueil affiche la liste des articles, « Page du blog » n'est pas applicable — l'interrupteur reste bloqué parce qu'il serait sans effet. S'il n'existe aucun article publié ou aucune page, la page d'exemple manque et le modèle reste bloqué lui aussi.

La voie recommandée : d'abord « Tout analyser » ou une analyse individuelle. Ensuite, vous ouvrez pour un modèle « Aperçu » et « sans » dans deux onglets — c'est la même page réelle, une fois avec et une fois sans traitement, visible uniquement pour les administrateurs connectés et uniquement avec une clé à usage unique valide dans l'adresse. L'interrupteur principal n'a pas besoin d'être activé pour cela. Le scintillement pendant la construction se voit le plus sûrement dans un onglet à part avec une connexion bridée, pas dans le cadre intégré.

Ce n'est que lorsque la comparaison paraît propre que vous validez le modèle et que vous activez l'interrupteur principal. Il démarre en mode test : là, seuls les administrateurs connectés voient le traitement, pour tous les autres la page reste inchangée. Vous ne passez sur « actif » qu'une fois que vous avez examiné plusieurs modèles.

Les quatre freins et les listes d'exceptions

« Charger les feuilles de style analysées en différé » est le véritable gain de temps. Désactivé signifie : le CSS critique s'ajoute en ligne, pour le reste tout demeure tel quel — sans risque, mais sans gain. Activé signifie : les feuilles de style analysées se chargent via media="print" plus un réinitialiseur onload, avec un duplicata noscript pour les visiteurs sans JavaScript. Seul ce qui a réellement été lu est différé, et uniquement si le handle et l'adresse du fichier correspondent encore à ce qui a été analysé.

« Suspendre si les fichiers source changent » retient pour chaque fichier analysé sa date de modification et sa taille ainsi que le thème actif. Si quelque chose change, rien n'est traité du tout plutôt que de l'être avec un CSS critique peut-être erroné — le code source contient alors une note avec la raison.

Trois champs de texte constituent la sortie de secours. URL d'exclusion : une ligne par chemin, « * » comme caractère générique, ces pages ne sont jamais traitées (typiquement /checkout*, /mein-konto*). Feuilles de style à ne jamais différer : un handle WordPress par ligne, admin-bar et dashicons par défaut. Repères : un sélecteur par ligne, tout ce qui s'y trouve compte comme étant en haut — les valeurs par défaut sont header, [role="banner"], .site-header, #masthead, nav, .main-navigation, .site-branding, .hero et h1. Les lignes non exploitables sont refusées plutôt qu'enregistrées en silence.

Une modification de la proportion « en haut » ou des repères n'agit qu'après une nouvelle analyse. Tout le reste vide immédiatement le cache de pages, car celui-ci contient du HTML déjà généré avec l'ancien état.

Quand quelque chose tourne mal

« Budget de temps épuisé » : l'exécution a atteint 25 secondes ou la limite de temps de PHP. Le rapport est enregistré, le CSS critique sciemment pas — un CSS critique incomplet provoquerait un scintillement. Le message nomme le fichier sur lequel cela s'est arrêté. Relance l'analyse ou retire une feuille de style très volumineuse via la liste d'exceptions.

« A répondu avec HTTP … » : la page d'exemple n'a pas renvoyé le code attendu (200, et 404 pour la page d'erreur). Rien n'est enregistré. Vérifie si la page est accessible dans le navigateur et si une protection se trouve devant.

Un modèle est marqué « obsolète » : un fichier CSS analysé a changé ou le thème a été remplacé. Relance l'analyse. S'il indique « autre proportion », le modèle a été créé avec un pourcentage différent de celui réglé actuellement — relance l'analyse également.

Pour que cela ne reste pas un travail manuel, il y a « Vérifier et rafraîchir quotidiennement ». L'exécution cron n'analyse que les modèles déjà validés et obsolètes ; elle n'active jamais rien et ne crée aucune analyse pour un modèle non validé. Son dernier résultat figure sous forme de note dans la zone Ceinture de sécurité.

Si une page reste malgré tout instable, un coup d'œil au code source aide : il contient un commentaire indiquant le modèle traité et l'état (aperçu, mode test, actif) ou la raison pour laquelle le traitement a été sciemment écarté.