« Comment ajouter defer à une balise script sans passer par un filtre sur script_loader_tag ? » Pendant longtemps, la seule réponse native consistait justement à intercepter la balise générée par wp_enqueue_script() et à y injecter l’attribut manuellement, une solution qui fonctionnait mais restait fragile : elle dépendait d’une manipulation de chaîne de caractères sur du HTML déjà généré.
Depuis la version 6.3 de WordPress, sortie en août 2023, wp_enqueue_script() accepte un tableau d’arguments en cinquième paramètre, remplaçant l’ancien booléen $in_footer. Ce tableau permet notamment de déclarer une stratégie de chargement defer ou async directement, sans filtre.
L’ancienne méthode, et sa fragilité
Avant cette évolution, ajouter defer à un script enregistré demandait un filtre de ce type :
add_filter( 'script_loader_tag', function( $tag, $handle ) {
if ( 'mon-script' === $handle ) {
$tag = str_replace( ' src', ' defer src', $tag );
}
return $tag;
}, 10, 2 );
Cette approche fonctionne, mais elle repose sur une modification de chaîne appliquée après coup, sensible au moindre changement dans le format de la balise générée par WordPress d’une version à l’autre.
La nouvelle syntaxe avec le tableau d’arguments
wp_enqueue_script(
'mon-script',
get_stylesheet_directory_uri() . '/js/mon-script.js',
array(),
'1.0',
array(
'strategy' => 'defer',
'in_footer' => true,
)
);
Le cinquième argument accepte désormais soit un simple booléen, pour rester rétrocompatible avec le comportement précédent, soit un tableau contenant les clés strategy et in_footer. La clé strategy accepte les valeurs defer ou async.
Différence entre defer et async
| Stratégie | Comportement | Cas d’usage typique |
|---|---|---|
defer | Exécution après le parsing du HTML, dans l’ordre de déclaration | Scripts qui dépendent de l’ordre ou du DOM complet |
async | Exécution dès le téléchargement terminé, sans ordre garanti | Scripts indépendants, sans dépendance d’ordre |
Un point de vigilance sur les dépendances
- WordPress applique automatiquement une stratégie compatible sur l’ensemble du graphe de dépendances : un script dépendant d’un autre chargé sans
deferne peut pas être différé lui-même sans casser l’ordre d’exécution attendu. - Si une incompatibilité est détectée entre les stratégies déclarées sur des scripts liés par dépendance, WordPress retombe silencieusement sur un chargement classique, sans erreur bloquante.
- Cette fonctionnalité ne concerne que
wp_enqueue_script(); les feuilles de style enregistrées viawp_enqueue_style()n’ont pas ce concept de stratégie de chargement différé.
Vérifier la version avant d’utiliser cette syntaxe
Un thème ou une extension qui doit rester compatible avec des installations plus anciennes que la version 6.3 ne peut pas utiliser ce tableau d’arguments sans condition : sur une version antérieure, le cinquième paramètre attend un simple booléen, et un tableau y serait interprété de façon incorrecte.
Avant d’adopter cette syntaxe sur un projet distribué à plusieurs clients, vérifiez la version minimale de WordPress annoncée dans l’en-tête de l’extension ou du thème. Un simple test sur
get_bloginfo( 'version' )ou une déclaration claire de compatibilité minimale évite une erreur sur un site resté en version plus ancienne.
En résumé
La stratégie de chargement introduite avec le tableau d’arguments de wp_enqueue_script() remplace avantageusement les filtres sur script_loader_tag pour les besoins courants de différé de script. Elle reste toutefois réservée aux projets qui peuvent exiger WordPress 6.3 ou une version plus récente comme prérequis minimal.
