Alléger WordPress avec wp_dequeue_script

par | WordPress

Si vous avez déjà ouvert un rapport PageSpeed et vu “Reduce unused JavaScript” alors que votre page n’a “rien de spécial”, il y a de fortes chances que vous chargiez des scripts inutiles partout. Sur WordPress 6.9.4 (avril 2026), le moyen le plus fiable de couper proprement un script sur une page donnée reste wp_dequeue_script(), à condition de le faire au bon moment et avec le bon handle (l’identifiant interne du script).

Prérequis

  • WordPress 6.9.4+ et PHP 8.1+.
  • Une sauvegarde complète (fichiers + base) avant toute modification. Ne testez pas ce type de changements directement en production.
  • Accès au code via un thème enfant, ou mieux : un petit plugin “maison” (recommandé ci-dessous), ou un mu-plugin.
  • Si vous utilisez un cache (page/serveur/CDN), prévoyez de le purger entre chaque test, sinon vous allez “mesurer le cache”, pas votre changement.

Le problème de performance

Le symptôme le plus courant : une page “simple” (accueil, article, page contact) charge 15 à 40 scripts JS, dont une partie ne sert pas. Résultat : un LCP (Largest Contentful Paint) qui se dégrade sur mobile, un INP (Interaction to Next Paint) pénalisé par du JavaScript qui monopolise le thread principal, et parfois un TTFB correct mais une page qui “met longtemps à devenir interactive”.

Le problème vient souvent de plugins qui chargent leurs assets partout “au cas où”. J’ai souvent croisé ça avec des formulaires, des sliders, des bibliothèques d’icônes, des trackers, ou des modules de page builder. Ce n’est pas forcément “mal codé” : c’est juste un choix de compatibilité, payé en performance.

Impact concret :

  • SEO : Core Web Vitals sur mobile qui passent en “Needs improvement”, surtout LCP/INP.
  • Taux de rebond : une page qui met 1–2 secondes de plus à répondre au scroll ou au clic perd des lecteurs.
  • UX : menus qui “saccadent”, formulaires qui laguent, animations qui stutter.

À la fin, vous saurez :

  • Identifier précisément quels scripts sont chargés sur une page, et par qui.
  • Désactiver un script sur certaines pages avec wp_dequeue_script() (et si besoin wp_deregister_script()).
  • Éviter les pièges (hook trop tôt, mauvais handle, dépendances cassées, cache qui masque les changements).

Résumé rapide

  • Mesurez avant : listez les scripts réellement chargés (handles) et leur origine.
  • Dequeue au bon hook : en pratique, wp_enqueue_scripts avec une priorité élevée (ex: 100) est le plus fiable.
  • Dequeue conditionnel : ne coupez un script que là où vous êtes sûr qu’il est inutile (ex: pas sur la page qui contient le formulaire).
  • Vérifiez les dépendances : un script peut en alimenter un autre ; coupez le bon maillon.
  • Testez sans cache : purge + navigation privée + paramètres corrects.
  • Quand ne pas dequeuer : parfois, defer/async ou un chargement conditionnel côté plugin est plus sûr.

Diagnostic avec du code

Comprendre les termes : hook, action, handle

Un hook est un point d’accroche dans WordPress. Il existe deux types : actions (vous exécutez du code à un moment donné) et filtres (vous modifiez une valeur). wp_enqueue_scripts est une action : c’est le moment où WordPress et les plugins enregistrent/ajoutent scripts et styles.

Un handle est le nom interne d’un script (ex: jquery, contact-form-7, elementor-frontend). wp_dequeue_script() ne fonctionne qu’avec ce handle.

Où coller le code (recommandé : plugin “maison”)

Évitez de coller ce code dans le thème parent. Deux options propres :

  • Plugin custom (recommandé) : survivra au changement de thème.
  • mu-plugin : chargé automatiquement, impossible à désactiver depuis l’admin (utile sur des sites gérés).

Créez un fichier : wp-content/plugins/perf-dequeue/perf-dequeue.php, puis activez-le.

<?php
/**
 * Plugin Name: Perf - Dequeue scripts ciblés
 * Description: Désactive des scripts inutiles page par page (WordPress 6.9.4+).
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

Activer des logs utiles (wp-config.php)

Sauvegardez avant de modifier wp-config.php. Sur un site public, évitez d’afficher les erreurs à l’écran.

/**
 * Debug contrôlé (à activer temporairement)
 * Attention : ne laissez pas WP_DEBUG en prod sans surveillance.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Le fichier de log se trouve généralement dans wp-content/debug.log.

Source : Debugging in WordPress

Query Monitor : diagnostic “sans code”, mais indispensable

Pour identifier rapidement les handles et les fichiers chargés, j’utilise Query Monitor. Installez-le depuis le dépôt officiel, puis ouvrez le panneau “Scripts” sur la page lente.

Vous pouvez faire la même chose en code, ce qui est pratique quand vous ne voulez pas dépendre d’un plugin de debug en production.

Liste des scripts chargés (code de diagnostic)

Ce snippet ajoute un en-tête HTTP X-WP-Scripts avec la liste des handles enqueued sur la page. Pratique dans Chrome DevTools > Network > votre document HTML > Headers.

<?php
add_action( 'send_headers', function () {
	if ( is_admin() ) {
		return;
	}

	// Évitez d'exposer ces infos en prod sur un site sensible.
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts;

	if ( ! ( $wp_scripts instanceof WP_Scripts ) ) {
		return;
	}

	$handles = array();
	foreach ( (array) $wp_scripts->queue as $handle ) {
		$handles[] = $handle;
	}

	// Limite de taille d'en-tête : on tronque si trop long.
	$value = implode( ',', array_slice( $handles, 0, 80 ) );
	header( 'X-WP-Scripts: ' . $value );
}, 999 );

Référence : Classe WP_Scripts

WP-CLI : vérifier plugins/thème et environnement

WP-CLI aide à repérer les sources de scripts (plugins lourds, thèmes, versions). Exécutez :

wp core version
wp php version
wp plugin list --status=active
wp theme list
wp option get stylesheet
wp option get template

Source : WP-CLI Commands (developer.wordpress.org)

Slow query log (quand le JS n’est pas le vrai coupable)

Parfois, vous pensez “scripts inutiles”, mais le vrai problème est un TTFB élevé à cause de requêtes SQL lentes. Si vous gérez votre serveur MySQL/MariaDB, activez le slow query log côté base. Côté PHP/WordPress, vous pouvez au moins repérer les requêtes lentes via Query Monitor.

Étape 1 : cartographier les scripts réellement chargés (avant de dequeuer)

La première erreur que je vois : “je dequeue au hasard”. Ça finit en formulaire cassé, menu mobile qui ne s’ouvre plus, ou slider invisible. On commence par cartographier.

Créer une page de test et noter les handles

Choisissez 2 ou 3 pages :

  • Une page “lourde” (accueil avec modules).
  • Une page “simple” (un article sans shortcodes).
  • Une page fonctionnelle (contact / boutique / recherche interne).

Ouvrez Query Monitor > Scripts. Notez :

  • Le handle (c’est celui que vous devrez dequeuer).
  • Le src (URL du fichier).
  • Le plugin ou thème d’origine.
  • Les dépendances si affichées.

Diagnostic “code” : loguer les scripts par type de page

Ce code écrit dans debug.log la liste des handles, avec un contexte (home/single/page). À activer temporairement.

<?php
add_action( 'wp_print_scripts', function () {
	if ( is_admin() ) {
		return;
	}
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}
	if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
		return;
	}

	global $wp_scripts;

	if ( ! ( $wp_scripts instanceof WP_Scripts ) ) {
		return;
	}

	$context = array();
	if ( is_front_page() ) { $context[] = 'front_page'; }
	if ( is_home() ) { $context[] = 'home_blog'; }
	if ( is_singular() ) { $context[] = 'singular'; }
	if ( is_page() ) { $context[] = 'page'; }
	if ( is_single() ) { $context[] = 'single'; }
	if ( is_archive() ) { $context[] = 'archive'; }

	$handles = (array) $wp_scripts->queue;
	error_log( '[Perf Dequeue] Context=' . implode( '|', $context ) . ' Scripts=' . implode( ',', $handles ) );
}, 999 );

Pourquoi wp_print_scripts ? Parce qu’à ce stade, la queue est en général finalisée. Pour dequeuer, on fera plutôt sur wp_enqueue_scripts (étape suivante).

Étape 2 : désactiver (dequeue) les scripts inutiles page par page

wp_dequeue_script( 'handle' ) retire un script de la file d’attente (queue) pour la requête en cours. Le script peut rester enregistré dans WordPress, mais il ne sera pas imprimé dans le HTML.

Référence officielle : wp_dequeue_script()

Choisir le bon hook et la bonne priorité

Si vous dequeuez trop tôt, le plugin va ré-enqueue après vous. Si vous dequeuez trop tard, le script est déjà imprimé. En pratique :

  • Hook : wp_enqueue_scripts
  • Priorité : 100 (ou 999 si un plugin “s’accroche”)

Référence : Action wp_enqueue_scripts

Exemple AVANT (lent) : un plugin charge partout

Cas réel : un plugin de formulaire charge son JS sur toutes les pages, même quand vous n’avez pas de formulaire.

<?php
// Exemple simplifié côté plugin (vous ne le modifiez PAS)
add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'my-form-plugin',
		plugins_url( 'assets/form.js', __FILE__ ),
		array( 'jquery' ),
		'1.2.3',
		true
	);
} );

Effet : +1 requête JS, +parsing/exécution JS, parfois +CSS associé. Sur mobile, ça peut suffire à dégrader l’INP si la page est déjà chargée.

Exemple APRÈS (optimisé) : dequeuer partout sauf sur la page Contact

Vous coupez le script sur toutes les pages, sauf celles où il est nécessaire. Ici, je garde le script uniquement :

  • sur une page ID 42 (Contact)
  • et sur toute page contenant le shortcode [my_form] (au cas où)
<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	$handle = 'my-form-plugin';

	// On garde le script sur la page Contact (ID à adapter).
	if ( is_page( 42 ) ) {
		return;
	}

	// On garde le script si le contenu contient le shortcode.
	// Attention : sur certaines pages builders, le contenu n'est pas dans post_content.
	if ( is_singular() ) {
		$post = get_post();
		if ( $post instanceof WP_Post && has_shortcode( (string) $post->post_content, 'my_form' ) ) {
			return;
		}
	}

	// Sinon, on le retire de la queue.
	wp_dequeue_script( $handle );
}, 100 );

Référence : has_shortcode()

Mesurer l’impact (simple et concret)

Le gain dépend du poids du fichier et surtout de son coût CPU. Une mesure simple :

  • Nombre de requêtes JS en moins (Network).
  • Taille transférée en moins (kB).
  • Temps d’exécution JS (Performance tab) et INP sur mobile.

Pour un blog classique, retirer 3–8 scripts inutiles sur les articles peut faire gagner typiquement :

  • 100 à 400 kB transférés
  • 20 à 150 ms de travail JS (souvent plus sur mobiles d’entrée de gamme)

Je préfère annoncer des fourchettes : le vrai gain se voit sur un profil Performance mobile, pas sur un desktop haut de gamme.

Quand utiliser wp_deregister_script en plus

wp_deregister_script() supprime l’enregistrement du script. C’est utile si un autre bout de code le ré-enqueue plus tard. Attention : si un plugin s’attend à ce qu’il existe, vous pouvez casser des pages.

Référence : wp_deregister_script()

<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Exemple : on veut être sûr qu'il ne reviendra pas sur les articles.
	if ( is_single() ) {
		wp_dequeue_script( 'my-form-plugin' );
		wp_deregister_script( 'my-form-plugin' );
	}
}, 100 );

Cas fréquent : vous n’avez pas le bon handle

Si vous essayez de dequeuer form.js au lieu de my-form-plugin, ça ne fera rien. Le handle n’est pas le nom du fichier. C’est pour ça que l’étape 1 (Query Monitor / log) est non négociable.

Étape 3 : faire la même chose avec les CSS (wp_dequeue_style) et éviter les faux gains

Souvent, les scripts inutiles viennent avec des CSS inutiles. La logique est identique avec wp_dequeue_style().

Référence : wp_dequeue_style()

Exemple : retirer CSS d’un plugin sur les articles

<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Exemple fictif : le plugin charge un CSS partout.
	if ( is_single() ) {
		wp_dequeue_style( 'my-form-plugin' );
	}
}, 100 );

Éviter le “faux gain” : CSS retiré mais JS toujours là

J’ai déjà vu des sites où on dequeuait le CSS, mais le JS continuait à injecter du DOM ou à faire des calculs. Résultat : un peu moins de kB, mais aucun gain INP. Traitez JS et CSS ensemble, puis mesurez.

Attention aux dépendances CSS/JS

Un style peut être dépendance d’un autre (rare, mais possible). Un script peut dépendre de jquery ou d’une lib. Si vous retirez un handle “parent”, vous pouvez casser plusieurs fonctionnalités. Testez toutes les pages clés après chaque changement.

Étape 4 : cas réels (Elementor, Divi 5, Avada) et scripts de plugins fréquents

Avec un page builder, le contenu n’est pas toujours dans post_content. Donc la détection “has_shortcode” peut rater des cas. Je vous conseille une approche pragmatique : ciblez des pages/types de pages, pas uniquement le contenu.

Elementor : garder les assets uniquement là où Elementor est utilisé

Elementor charge des assets sur les pages construites avec Elementor. Selon votre configuration et vos addons, certains fichiers peuvent se retrouver partout.

Une méthode robuste : détecter si la page est “éditée avec Elementor” via la classe du plugin (si présente). On protège le code avec class_exists pour éviter une erreur fatale si Elementor n’est pas installé.

<?php
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Exemple : vous avez identifié un script addon Elementor chargé partout.
	$handle = 'my-elementor-addon-frontend';

	// Si Elementor n'existe pas, on ne fait rien.
	if ( ! class_exists( 'ElementorPlugin' ) ) {
		return;
	}

	// Si ce n'est pas une page singular, on coupe (à adapter selon votre site).
	if ( ! is_singular() ) {
		wp_dequeue_script( $handle );
		return;
	}

	$post_id = get_queried_object_id();

	// Si la page n'est PAS construite avec Elementor, on coupe.
	$is_elementor = ElementorPlugin::$instance->documents->get( $post_id )?->is_built_with_elementor();

	if ( ! $is_elementor ) {
		wp_dequeue_script( $handle );
	}
}, 100 );

Note : l’API interne d’Elementor peut évoluer. Si ce snippet ne passe pas sur votre version, revenez à une règle simple (ex: ne charger l’addon que sur une liste de pages) ou utilisez les réglages de performance du plugin/addon quand disponibles.

Divi 5 : prudence sur les scripts “globaux”

Divi (notamment avec des modules dynamiques) peut dépendre d’assets globaux. Mon expérience : dequeuer “au hasard” un script Divi casse plus vite le menu, les animations ou le chargement des modules.

Approche recommandée :

  • Ne dequeuez pas des handles du cœur Divi sans test complet.
  • Dequeuez plutôt les scripts de plugins tiers (sliders, popups, analytics), et laissez Divi gérer ses optimisations.

Si vous devez absolument couper un script tiers sur des pages Divi, faites-le par type de page (ex: is_single()) et testez les modules interactifs (accordéons, tabs, formulaires).

Avada : scripts Fusion/Theme et plugins d’addons

Avada et Fusion Builder chargent des assets en fonction des éléments utilisés, mais des addons peuvent surcharger. Même stratégie : ciblez les scripts d’addons identifiés via Query Monitor.

Exemples de scripts souvent inutiles sur un blog

  • Scripts de formulaire sur toutes les pages (alors que le formulaire n’est que sur Contact).
  • Scripts de slider/carrousel sur les articles (alors que vous n’avez pas de slider).
  • Scripts de popup/newsletter sur les pages “légales” (CGU, politique de confidentialité).
  • Scripts de partage social lourds sur des pages où vous n’affichez pas les boutons.

Étape 5 : quand ne pas dequeuer (async/defer/preload à la place)

Dequeuer est radical. Parfois, vous avez besoin du script, mais pas “tout de suite”. Dans ce cas, vous gagnez plus en ajoutant defer (ou rarement async) qu’en supprimant.

Sur WordPress moderne, vous pouvez ajouter des attributs aux balises <script> via le filtre script_loader_tag.

Référence : Filtre script_loader_tag

Ajouter defer sur un script non critique

Règle simple : préférez defer pour les scripts qui dépendent de l’ordre d’exécution. async peut casser des dépendances.

<?php
add_filter( 'script_loader_tag', function ( string $tag, string $handle, string $src ) : string {
	// Exemple : on diffère un script analytics non critique.
	$defer_handles = array(
		'my-analytics',
	);

	if ( in_array( $handle, $defer_handles, true ) ) {
		// On injecte defer si absent.
		if ( ! str_contains( $tag, ' defer' ) ) {
			$tag = str_replace( '<script ', '<script defer ', $tag );
		}
	}

	return $tag;
}, 10, 3 );

Pourquoi c’est parfois mieux que dequeuer : vous gardez la fonctionnalité (analytics, tracking, chat), mais vous réduisez l’impact sur le rendu initial.

Précharger un script critique (avec parcimonie)

Le preload peut aider si un script est critique et tardif, mais il peut aussi gaspiller de la bande passante. Utilisez-le seulement après mesure.

<?php
add_action( 'wp_head', function () {
	if ( is_admin() ) {
		return;
	}

	// Exemple : preload d'un script critique sur la home uniquement.
	if ( ! is_front_page() ) {
		return;
	}

	// Remplacez par une URL réelle que vous avez mesurée comme critique.
	$src = content_url( '/mu-plugins/assets/critical.js' );

	echo '<link rel="preload" as="script" href="' . esc_url( $src ) . '" />' . "n";
}, 1 );

Référence : esc_url()

Configuration serveur

wp_dequeue_script() réduit le travail côté navigateur. Mais si votre serveur envoie des assets sans cache HTTP correct, vous perdez une partie du bénéfice. Voici des réglages “copier-coller” courants (à adapter à votre hébergement).

.htaccess (Apache) : cache des fichiers statiques

Ajoutez dans le .htaccess (souvent à la racine). Sauvegardez avant. Sur certains hébergeurs, ces directives sont déjà gérées ailleurs.

# Cache navigateur pour assets statiques
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 30 days"
  ExpiresByType application/javascript "access plus 30 days"
  ExpiresByType text/javascript "access plus 30 days"
  ExpiresByType image/svg+xml "access plus 30 days"
  ExpiresByType image/png "access plus 30 days"
  ExpiresByType image/jpeg "access plus 30 days"
  ExpiresByType image/webp "access plus 30 days"
  ExpiresByType font/woff2 "access plus 180 days"
</IfModule>

php.ini : OPcache (si vous gérez le serveur)

OPcache n’accélère pas le JS front, mais il réduit le CPU PHP et stabilise le TTFB. Vérifiez avec votre hébergeur.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Source : PHP OPcache configuration (php.net)

wp-config.php : limiter les révisions (base plus légère)

Ça ne touche pas directement wp_dequeue_script, mais sur des sites lents, la base surchargée ajoute du bruit dans les mesures.

/** Limiter les révisions d'articles (évite une table postmeta qui gonfle) */
define( 'WP_POST_REVISIONS', 10 );

Référence : wp-config.php (developer.wordpress.org)

Vérification des résultats

Ne validez jamais un dequeue “juste parce que ça charge”. Validez : performance + absence de régression fonctionnelle.

Vérifier que le script ne sort plus dans le HTML

  • Ouvrez le code source de la page (ou DevTools > Elements).
  • Cherchez l’URL du script (ou son handle si visible via id="handle-js").

Vérifier côté navigateur (Performance) : moins de travail JS

Faites 2 profils (avant/après) sur mobile simulé ou un vrai téléphone :

  • Temps “Scripting” total en baisse.
  • Moins de longues tâches (> 50 ms) au chargement.

Petit outil de mesure “maison” (temps serveur)

Ce code ajoute un header X-WP-Server-Timing avec le temps PHP (approx). Ce n’est pas une mesure front, mais ça aide à voir si le TTFB change (normalement, dequeuer des scripts ne change presque pas le temps PHP).

<?php
add_action( 'send_headers', function () {
	if ( is_admin() ) {
		return;
	}
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}

	// TIMER_START est défini par WordPress très tôt.
	if ( defined( 'TIMER_START' ) ) {
		$ms = ( microtime( true ) - TIMER_START ) * 1000;
		header( 'X-WP-Server-Timing: php;dur=' . round( $ms, 1 ) );
	}
}, 999 );

Commandes utiles : purge de cache (si vous avez un plugin)

Selon votre stack, vous pouvez avoir :

  • Un cache plugin (purge depuis l’admin ou WP-CLI si supporté).
  • Un cache serveur (Nginx/FastCGI, LiteSpeed).
  • Un CDN (purge).

Sans purge, vous risquez de croire que “rien ne marche” alors que vous voyez une version HTML mise en cache.

Si les performances ne s’améliorent pas

Quand vous retirez 5 scripts et que le score ne bouge pas, ça arrive. Voici une checklist qui marche en conditions réelles.

1) Vous avez amélioré le réseau, mais pas le CPU

Sur mobile, le problème est souvent le CPU (parsing/exécution JS) plus que le poids. Si vous avez retiré des petits fichiers, le gain sera faible. Cherchez plutôt :

  • Un gros bundle JS (200–800 kB).
  • Un script qui fait du travail au chargement (carrousel, popup, tracking lourd).

2) Votre script “inutile” était en cache et déjà rapide

Si le navigateur avait déjà le fichier en cache, retirer le script réduit peu le temps réseau, mais peut réduire le coût CPU. Mesurez avec un profil Performance, pas seulement “kB transférés”.

3) Le problème est ailleurs : images, polices, LCP

Si votre LCP est une image héro non optimisée, dequeuer du JS aide peu. À ce stade, traitez :

  • Compression WebP/AVIF
  • Dimensions explicites
  • Lazy-load intelligent (pas sur l’image LCP)
  • Préchargement de la police critique

4) Le TTFB est mauvais : cache serveur/objet manquant

Un TTFB à 1s+ ne vient pas de scripts front. Regardez :

  • OPcache
  • Cache page (serveur ou plugin)
  • Cache objet persistant (Redis/Memcached)

Pièges et erreurs courantes

Erreurs que je vois tout le temps (et comment les éviter)

  • Copier le code au mauvais endroit : un snippet collé dans le thème parent disparaît à la mise à jour. Préférez un plugin custom.
  • Oublier le point-virgule : une simple erreur de syntaxe met le site en erreur 500. Testez sur staging.
  • Utiliser le mauvais hook : sur init, vous êtes souvent trop tôt. Utilisez wp_enqueue_scripts priorité 100.
  • Mauvais handle : vous dequeuez “le nom du fichier”. Ça ne marche pas. Récupérez le handle via Query Monitor.
  • Conflit cache : vous changez le code, mais vous voyez l’ancienne page. Purgez cache plugin + CDN + navigateur.
  • Tester sur production sans sauvegarde : un dequeue peut casser une page de vente. Faites une sauvegarde et un plan de rollback.
  • Priorité trop basse : un plugin enqueue après vous. Montez à 999 si nécessaire.
  • Confusion action/filtre : add_action pour exécuter, add_filter pour modifier une valeur.

Tableau de diagnostic

Symptôme Cause probable Vérification Solution
Le script est toujours chargé Dequeue trop tôt / priorité trop faible Query Monitor > Scripts, regardez l’ordre d’enqueue Déqueue sur wp_enqueue_scripts priorité 100–999
Rien ne change dans le navigateur Cache page/CDN Tester en navigation privée + désactiver cache DevTools Purger cache plugin + CDN + serveur
Fonctionnalité cassée (menu, slider, formulaire) Script nécessaire ou dépendance cassée Console JS (erreurs), Query Monitor (dépendances) Ne dequeuez pas ce handle, ou coupez plutôt un addon, ou utilisez defer
Erreur 500 après ajout du snippet Erreur PHP (syntaxe, version PHP) Logs serveur + wp-content/debug.log Corriger la syntaxe, vérifier PHP 8.1+, restaurer sauvegarde
Gain faible malgré plusieurs dequeues Le vrai problème est LCP images/polices ou TTFB Profil Performance + rapport CWV Optimiser images/polices, activer cache serveur/objet

Conseils de maintenance

  • Documentez vos handles : dans votre plugin perf, commentez pourquoi vous dequeuez tel script, et sur quelles pages. Dans 6 mois, vous aurez oublié.
  • Rétestez après mises à jour : un plugin peut changer de handle (ou ajouter un nouveau bundle). Après une grosse mise à jour, passez 10 minutes sur Query Monitor.
  • Gardez un mode “diagnostic” : les headers X-WP-Scripts et X-WP-Server-Timing sont très utiles, mais limitez-les aux admins.
  • Ne faites pas du “dequeue massif” : retirez 1–2 scripts, testez, mesurez, puis continuez. C’est plus lent, mais vous évitez les régressions.
  • Préférez le chargement conditionnel à la source quand possible : certains plugins ont des réglages “Load assets only on pages where used”. C’est souvent plus stable qu’un dequeue externe.

Ressources

FAQ

Quelle différence entre wp_dequeue_script et wp_deregister_script ?

wp_dequeue_script() retire le script de la file d’attente pour la page courante. wp_deregister_script() supprime l’enregistrement du script (il “n’existe plus” pour WordPress), ce qui peut empêcher un ré-enqueue mais augmente le risque de casse si un autre code le réclame.

Pourquoi mon wp_dequeue_script ne marche pas ?

Dans 90% des cas : mauvais handle, mauvais hook, ou priorité trop faible. Vérifiez le handle via Query Monitor, puis faites le dequeue sur wp_enqueue_scripts avec priorité 100 (ou 999).

Est-ce que je peux mettre ce code dans functions.php ?

Oui, mais uniquement dans un thème enfant. Un plugin custom reste plus propre, surtout si vous changez de thème (Divi/Elementor/Avada).

Est-ce risqué pour la sécurité ?

Dequeuer un script n’ouvre pas directement une faille, mais vous pouvez casser des protections (ex: un script anti-spam sur un formulaire). Testez toutes les pages sensibles (login, formulaire, paiement) après modification.

Comment trouver le handle exact d’un script ?

Le plus rapide : Query Monitor > Scripts. Sinon, utilisez le header X-WP-Scripts fourni plus haut (réservé admin) ou cherchez dans le HTML un id="HANDLE-js" sur la balise script (souvent présent).

Dois-je dequeuer jQuery pour gagner du temps ?

Sur beaucoup de sites, retirer jQuery casse des plugins. Je ne le recommande pas pour débutants. Commencez par les scripts de plugins clairement inutiles page par page. Si vous voulez aller plus loin, faites un audit de dépendances et remplacez les plugins qui l’imposent.

Pourquoi has_shortcode ne détecte rien sur une page Elementor/Divi ?

Parce que le contenu du builder n’est pas toujours stocké comme un shortcode dans post_content. Dans ce cas, utilisez une règle par page/type de page, ou une détection spécifique au builder (quand fiable), ou les réglages internes du plugin.

Que faire si un plugin ré-enqueue le script après mon dequeue ?

Montez la priorité (999). Si ça ne suffit pas, vous pouvez tenter wp_deregister_script(), mais testez davantage. Autre option : désactiver le chargement global via un filtre du plugin (si disponible).

Est-ce que ça améliore le TTFB ?

Peu. Dequeuer des scripts améliore surtout le rendu et l’interactivité côté navigateur (LCP/INP). Le TTFB se traite plutôt via cache serveur, OPcache, cache objet, requêtes SQL.

Comment revenir en arrière rapidement si j’ai cassé le site ?

Désactivez le plugin custom depuis l’admin si possible. Sinon, via FTP/SSH, renommez le dossier wp-content/plugins/perf-dequeue/. Si vous avez mis le code en mu-plugin, renommez le fichier dans wp-content/mu-plugins/. Puis purgez les caches.

Est-ce compatible avec un CDN et un plugin de minification ?

Oui, mais attention : certains plugins de minification “fusionnent” les scripts. Dans ce cas, dequeuer un handle peut ne plus retirer grand-chose car le fichier final est un bundle. Désactivez temporairement la minification pour diagnostiquer, puis réactivez et re-mesurez.

Articles connexes

Envoyer Un Commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *