Introduction à la gestion d’actifs WordPress
La gestion d’actifs WordPress est un aspect essentiel pour garantir la performance de votre site. De nombreux plugins WordPress choisissent la voie de la facilité en chargeant leurs fichiers CSS et JavaScript de manière globale. Bien que cette approche soit sécurisée pour le développeur, elle n’est pas idéale pour la performance du site. Chaque octet de JavaScript inutilisé augmente le temps d’exécution du navigateur, ce qui impacte négativement le Total Blocking Time (TBT) et le Largest Contentful Paint (LCP).
Les bases : Chargement contextuel
La première ligne de défense consiste à s’assurer que votre propre code ne se charge que lorsque cela est nécessaire. N’oubliez pas que le hook wp_enqueue_scripts est simplement une action. Vous pouvez envelopper vos enqueues dans une logique pour les restreindre à des contextes spécifiques. L’utilisation de Conditional Tags empêche les scripts de se charger là où ils ne sont pas nécessaires. Par exemple, si vous avez un script lourd qui ne fonctionne que sur une page « Contact », il n’est pas utile de le charger partout ailleurs.
Examiner l’objet $wp_scripts
Le véritable goulet d’étranglement de performance provient souvent des plugins tiers. Pour les arrêter, vous devez d’abord identifier leurs handles. Vous pouvez passer beaucoup de temps à chasser dans les fichiers source des plugins, mais il est probablement plus rapide de regarder l’état interne du gestionnaire de scripts de WordPress. WordPress utilise la classe WP_Scripts pour gérer la file d’attente. Pendant le cycle de vie de la page, une variable globale appelée $wp_scripts contient chaque script enregistré et enqueued.
Identifier le bloat
Vous pouvez interroger cet objet global pour voir exactement quels handles sont enqueued pour la demande actuelle. Pour utiliser le snippet suivant, vous pouvez l’ajouter à un plugin personnalisé utilisé sur un site de staging ou dans un environnement de développement local. Il est important d’utiliser le hook wp_print_scripts. Ce hook se déclenche juste avant que WordPress ne commence à imprimer les scripts dans l’en-tête, ce qui garantit que chaque plugin a terminé sa logique d’enqueueing, vous donnant une vue complète de la file d’attente finale.
Exécution dans des environnements locaux ou de staging
Vous ne devez exécuter ce code que dans un environnement non productif, comme une installation locale ou un site de staging. Un site local est « sûr », mais un site de staging est souvent supérieur pour cet audit car il reflète parfaitement votre configuration de plugin de production et l’état de votre base de données.
Pourquoi pas en production ?
Ce snippet sort des données directement dans le code source HTML de votre site. Sur un site en direct, cela semble peu professionnel pour les visiteurs et peut révéler votre pile de plugins spécifique à des acteurs malveillants. De plus, l’exécution de la logique de débogage à chaque chargement de page ajoute une surcharge inutile à la performance de votre serveur.
Déqueuing programmatique : La frappe chirurgicale
Une fois que vous avez identifié vos handles cibles, vous pouvez utiliser wp_dequeue_script() pour les supprimer. Cependant, le succès dépend beaucoup de la priorité. Dans WordPress, les priorités des hooks agissent comme une liste d’attente où un nombre plus élevé s’exécute plus tard. Étant donné que la plupart des plugins enqueue des actifs à la priorité par défaut de 10, vous devez vous accrocher à wp_enqueue_scripts avec un nombre beaucoup plus élevé (comme 100) pour vous assurer que votre logique de suppression s’exécute après la logique de chargement du plugin.
Exemple : Élagage du bloat des plugins
Supposons qu’un plugin de « Reviews » charge un fichier JavaScript de 150 Ko sur votre page d’accueil. Si les avis n’existent que sur vos pages de produit, vous pouvez supprimer ce script partout ailleurs.
Le piège des dépendances
Avant de commencer à débrancher chaque script que vous voyez, vous devez vérifier les dépendances. La fonction wp_enqueue_script() vous permet de définir une liste d’autres scripts qui doivent se charger en premier. Vous casserez la fonctionnalité du site si vous déqueuez un script dont d’autres scripts enqueued dépendent. Le navigateur affichera des erreurs « non défini » dans la console. Vérifiez toujours la propriété enregistrée dans le global $wp_scripts pour voir le tableau des dépendances pour un handle spécifique avant de le supprimer.
Conclusion
La gestion avancée des actifs est un jeu de soustraction. En auditant le global WP_Scripts et en mettant en œuvre un déqueuing conditionnel à haute priorité, vous pouvez réduire considérablement le poids de votre frontend. Cette approche chirurgicale garantit que votre site reste rapide et léger sans sacrifier la fonctionnalité des plugins dont vous avez besoin.