Un audit de performance mené récemment sur un site associatif chargé de douze extensions actives a révélé un problème banal mais coûteux : neuf de ces extensions chargeaient leur CSS et leur JavaScript sur absolument toutes les pages du site, admin comme front, alors que la plupart n’étaient utiles que sur un écran de réglages ou un shortcode spécifique. Résultat, une page d’accueil qui n’utilisait aucune des fonctionnalités correspondantes chargeait tout de même une dizaine de fichiers superflus.
Le réflexe à corriger est simple à énoncer et trop souvent ignoré : un wp_enqueue_script() ou wp_enqueue_style() ne devrait jamais s’exécuter sans condition. Voici, problème par problème, les vérifications à mettre en place selon le contexte.
Problème : un script d’admin chargé sur tous les écrans
Une extension de gestion de stock, par exemple, n’a besoin de son JavaScript que sur son propre écran de réglages, jamais sur l’écran des articles ou le tableau de bord. La fonction get_current_screen(), disponible depuis l’action admin_enqueue_scripts, permet de cibler précisément l’écran :
add_action( 'admin_enqueue_scripts', function( $hook ) {
$ecran = get_current_screen();
if ( ! $ecran || 'toplevel_page_mon-extension-stock' !== $ecran->id ) {
return;
}
wp_enqueue_script(
'mon-extension-stock-admin',
plugins_url( 'assets/admin.js', __FILE__ ),
array( 'wp-api-fetch' ),
MON_EXTENSION_VERSION,
true
);
} );
Le paramètre $hook transmis par admin_enqueue_scripts donne une alternative plus simple pour les écrans standards, mais get_current_screen()->id reste préférable pour les écrans personnalisés dont l’identifiant dépend de la structure du menu d’admin, en particulier pour les sous-menus.
Problème : un style chargé sur chaque écran d’édition, même sans le bon post type
Une metabox spécifique à un CPT « événement » n’a aucune raison de charger son CSS sur l’écran d’édition d’une page ou d’un article standard :
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( ! in_array( $hook, array( 'post.php', 'post-new.php' ), true ) ) {
return;
}
$ecran = get_current_screen();
if ( ! $ecran || 'evenement' !== $ecran->post_type ) {
return;
}
wp_enqueue_style( 'mon-extension-evenement', plugins_url( 'assets/evenement.css', __FILE__ ), array(), MON_EXTENSION_VERSION );
} );
Problème : un script front chargé même sans le shortcode ou le bloc correspondant
Côté front, la question à se poser avant chaque wp_enqueue_script() systématique sur wp_enqueue_scripts : la page affichée contient-elle réellement l’élément qui a besoin de ce script ? Deux fonctions natives répondent à cette question sans avoir à parser le contenu soi-même :
has_shortcode( $post->post_content, 'mon_shortcode' )pour un shortcode classique.has_block( 'mon-extension/carte-interactive' )pour un bloc, y compris dans les modèles FSE depuis WordPress 5.9.
add_action( 'wp_enqueue_scripts', function() {
if ( ! is_singular() ) {
return;
}
global $post;
$utilise_shortcode = $post && has_shortcode( $post->post_content, 'carte_interactive' );
$utilise_bloc = has_block( 'mon-extension/carte-interactive' );
if ( ! $utilise_shortcode && ! $utilise_bloc ) {
return;
}
wp_enqueue_script( 'mon-extension-carte', plugins_url( 'assets/carte.js', __FILE__ ), array(), MON_EXTENSION_VERSION, true );
wp_enqueue_style( 'mon-extension-carte', plugins_url( 'assets/carte.css', __FILE__ ), array(), MON_EXTENSION_VERSION );
} );
Le piège des contenus assemblés dynamiquement
Cette vérification a une limite connue : elle inspecte $post->post_content, donc elle ne détecte pas un shortcode inséré dynamiquement par un widget, un composeur de page tiers, ou un contenu injecté via un filtre. Pour ces cas, une alternative plus robuste consiste à enregistrer le script normalement mais sans l’enqueuer, puis à l’ajouter réellement au moment du rendu du shortcode ou du bloc lui-même :
add_action( 'wp_enqueue_scripts', function() {
wp_register_script( 'mon-extension-carte', plugins_url( 'assets/carte.js', __FILE__ ), array(), MON_EXTENSION_VERSION, true );
} );
add_shortcode( 'carte_interactive', function( $atts ) {
wp_enqueue_script( 'mon-extension-carte' ); // enqueue au moment du rendu réel
return '<div class="mon-extension-carte" data-lat="' . esc_attr( $atts['lat'] ?? '' ) . '"></div>';
} );
Cette technique fonctionne parce que WordPress accepte un wp_enqueue_script() tardif tant qu’il intervient avant l’impression des scripts dans le pied de page — utile aussi pour un widget ou un bloc dynamique dont le rendu final n’est connu qu’au moment de l’exécution.
Mesurer le gain
Sur le site associatif audité, l’application de ces vérifications sur les neuf extensions concernées a supprimé une quarantaine de requêtes de fichiers par page en moyenne, sans aucune perte fonctionnelle puisque les scripts restent chargés exactement là où ils sont utiles. Le gain le plus net se voit sur les pages qui n’utilisent aucune extension à fonctionnalité front, où le nombre de requêtes JS/CSS a été divisé par deux.
La question à se poser avant chaque enqueue : si je supprimais cette ligne de condition, qui s’en apercevrait ? Si la réponse est « personne, sur la plupart des pages », c’est le signe qu’une condition manque.
En résumé
Charger un script ou un style sans condition est le choix le plus simple à écrire, mais le plus coûteux à l’échelle d’un site avec plusieurs extensions actives. get_current_screen() en admin, has_shortcode() et has_block() en front, et l’enqueue tardif au moment du rendu pour les cas dynamiques : ces trois techniques suffisent à couvrir la quasi-totalité des situations, pour un coût de développement minime face au gain de performance cumulé sur l’ensemble du site.
