Accélérer WordPress en coupant emojis et wp-embed

Si vous voyez wp-emoji-release.min.js et wp-embed.min.js revenir dans vos rapports Lighthouse ou PageSpeed, vous payez souvent quelques requêtes et du JavaScript… pour des fonctionnalités que beaucoup de sites de blog n’utilisent jamais.

Le problème de performance

Sur WordPress 6.9.4 (avril 2026), deux scripts “historiques” reviennent fréquemment dans les audits :

Les emojis WordPress : un ensemble de hooks qui ajoutent des scripts/styles et des filtres (conversion de caractères, détection, etc.). Sur un blog classique, c’est rarement indispensable.
wp-embed : le script front qui permet certaines fonctionnalités d’oEmbed (intégrations et “embeds” WordPress). Si vous n’intégrez pas de contenus externes (YouTube/Twitter/Instagram…) via simple URL, ou si votre thème/page builder ne s’appuie pas dessus, il est souvent inutile.

Le gain n’est pas “magique” : on parle plutôt de réduction du nombre de requêtes, du JavaScript à parser et parfois de quelques millisecondes sur le INP (Interaction to Next Paint) et le LCP selon le device. Mais sur mobile, j’ai souvent vu ces micro-gains s’additionner quand le site est déjà chargé en scripts (Divi, Elementor, Avada, analytics, pixels…).

Ce point est clé pour les débutants : PageSpeed/Lighthouse vous pénalise rarement “wp-embed” tout seul. Il vous pénalise plutôt pour un “budget JS” trop élevé. Retirer 10–30 Ko par-ci par-là peut suffire à repasser sous certains seuils, surtout sur des téléphones d’entrée de gamme (CPU lent + réseau instable).

Autre réalité terrain : ces scripts sont souvent présents sur toutes les pages (home, archives, pages, articles), alors que vous n’utilisez la fonctionnalité que sur 2% du site. C’est exactement le genre d’optimisation “simple” qui a du sens.

Impact concret :

SEO : des Core Web Vitals plus stables (moins de JS inutile).
Taux de rebond : un site qui répond plus vite sur mobile garde plus de lecteurs.
Expérience : moins de scripts = moins de risques de conflits JS.

À la fin, vous saurez :

mesurer la présence de ces scripts avec du code (sans capture d’écran),
les désactiver proprement via un mu-plugin (plugin “must-use”, chargé automatiquement),
vérifier que vous n’avez rien cassé (embeds, éditeur, page builders),
quantifier le gain (requêtes, taille, timings simples).

Résumé rapide

Désactivez les emojis en retirant les actions/filtres core + en évitant le DNS prefetch associé.
Désactivez wp-embed uniquement si vous n’utilisez pas d’oEmbed sur le front.
Faites-le dans un mu-plugin (plus fiable que functions.php, surtout avec Divi/Elementor/Avada).
Mesurez avant/après : nombre de scripts, taille HTML, et timings (server timing + logs).
Attention aux caches : videz cache page/CDN et cache navigateur avant de conclure.

Variante utile (souvent le meilleur compromis) : désactiver wp-embed partout sauf sur les articles ou sauf sur une liste de pages. J’y reviens plus bas avec du code.

Edge case courant : si vous êtes sur un site multilingue (WPML/Polylang) ou avec un cache agressif, vos tests “avant/après” doivent être faits sur la même URL, la même langue, et idéalement en contournant le cache (ou en le purgeant). Sinon vous comparez des choses différentes.

Diagnostic avec du code

Prérequis :

WordPress 6.9.4+, PHP 8.1+.
Un accès aux fichiers (FTP/SSH) ou au gestionnaire de fichiers de l’hébergeur.
Une sauvegarde (fichiers + base) avant modifications. Ne modifiez jamais le cœur de WordPress.

Où coller le code (recommandé)

Je vous conseille un mu-plugin : un fichier PHP placé dans wp-content/mu-plugins/. Avantage : il se charge avant les plugins classiques et n’est pas désactivable “par accident” depuis l’admin.

Créez le dossier s’il n’existe pas, puis un fichier, par exemple :

wp-content/mu-plugins/perf-disable-emoji-embed.php

Edge case : certains hébergements “managés” verrouillent partiellement wp-content. Si vous ne pouvez pas créer mu-plugins, utilisez un plugin “site-specific” (un plugin maison) dans wp-content/plugins/. C’est un peu moins robuste qu’un mu-plugin, mais nettement plus fiable que functions.php.

Activer un mode debug propre (sans casser la prod)

Un hook est un point d’extension : une action exécute du code, un filtre modifie une valeur. Pour diagnostiquer, on veut des logs, pas des erreurs affichées.

Dans wp-config.php (sur un site en production, évitez d’afficher les erreurs), vous pouvez utiliser :

<?php
// wp-config.php — Sauvegardez avant de modifier.
// Active le debug sans afficher d'erreurs aux visiteurs.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

// Optionnel : log des requêtes SQL (peut ralentir, à activer temporairement).
// define( 'SAVEQUERIES', true );

Les logs iront dans wp-content/debug.log.

Dans mon expérience, la cause n°1 des “je ne vois rien dans le log” est un fichier debug.log non inscriptible. Vérifiez rapidement les permissions (ou testez en écrivant un error_log('test'); temporaire).

Source officielle : Debugging in WordPress.

Mesurer la présence des scripts (front) via un mini “compteur”

Avant d’optimiser, je veux une preuve. Le code ci-dessous enregistre dans les logs :

si wp-emoji-release est en file,
si wp-embed est en file,
la liste des scripts réellement enqueued.

Collez ce bloc dans votre mu-plugin, temporairement (vous pourrez le commenter ensuite).

<?php
/**
 * Plugin Name: Perf — Désactiver Emojis & wp-embed
 * Description: Optimisations front (WP 6.9.4+) : emojis et wp-embed.
 * Author: Votre Nom
 */

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

/**
 * Log simple des scripts enqueued sur le front.
 * À activer temporairement : utile avant/après.
 */
add_action( 'wp_print_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Évitez de spammer les logs : ne logguez que pour les admins connectés.
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts;

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

	$handles = $wp_scripts->queue;

	error_log( '--- PERF SCRIPTS (front) ---' );
	error_log( 'Total scripts enqueued: ' . count( $handles ) );
	error_log( 'wp-emoji-release present? ' . ( in_array( 'wp-emoji-release', $handles, true ) ? 'YES' : 'NO' ) );
	error_log( 'wp-embed present? ' . ( in_array( 'wp-embed', $handles, true ) ? 'YES' : 'NO' ) );
	error_log( 'Handles: ' . implode( ', ', $handles ) );
}, 999 );

Note : on utilise wp_print_scripts à une priorité élevée pour observer la queue finale. Si vous le mettez trop tôt, vous risquez de “mesurer” avant que le thème/page builder ait ajouté ses scripts.

Edge cases à connaître :

Pages AMP / mode “optimized” : certains plugins AMP changent complètement la gestion des scripts. Dans ce cas, ce log peut montrer une queue différente (ou vide) sur les URLs AMP.
Cache de page : si votre page est servie en HTML statique sans exécuter WordPress (cache full page côté serveur), ce log ne s’écrit pas, parce que WordPress ne tourne pas. Testez en contournant le cache (paramètre “nocache”, cookie admin, purge).
HTTP/2 push / CDN : rare en 2026, mais certains stacks injectent des hints ou des scripts. Ici on mesure ce que WordPress enfile, pas ce que le CDN ajoute.

Query Monitor et WP-CLI (diagnostic rapide)

Pour les débutants, Query Monitor reste la méthode la plus pratique pour voir scripts, hooks, requêtes, timings. Installez-le puis désactivez-le quand vous avez fini (il ajoute du coût en debug).

Query Monitor (wordpress.org)

Si vous avez WP-CLI :

# Vérifier versions (utile en dépannage)
wp core version
wp php version

# Lister les must-use plugins (pour vérifier que votre mu-plugin est bien chargé)
wp plugin list --status=must-use

# Vérifier que les permaliens et la config sont OK
wp option get permalink_structure

Variante WP-CLI utile en perf (quand vous suspectez un plugin) :

# Voir les plugins actifs (et repérer les "gros" habituels)
wp plugin list --status=active

# Vérifier rapidement la taille de l'autoload (souvent cause de TTFB élevé)
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"

Attention : la requête suppose que votre préfixe de table est wp_. Si vous avez un autre préfixe, adaptez (wp-config.php → $table_prefix).

Source officielle WP-CLI : WP-CLI Commands.

Slow query log (quand le site est lent côté serveur)

Désactiver emojis/wp-embed joue surtout côté front (requêtes + JS). Si votre TTFB est élevé, activez plutôt un slow query log MySQL/MariaDB ou PHP-FPM côté serveur. Je reviens sur la partie serveur plus bas.

Étape 1 : Désactiver les emojis WordPress (core)

Voici ce qui se passe en coulisses : WordPress ajoute des actions et filtres pour gérer les emojis, notamment :

un script front wp-emoji-release.min.js,
des filtres sur le contenu et les emails,
un DNS prefetch vers s.w.org (selon configuration).

Traduction “débutant” : WordPress essaie de rendre les emojis cohérents partout, y compris sur des navigateurs anciens. En 2026, sur la majorité des audiences, c’est rarement indispensable. Le bénéfice est donc faible, et le coût (même petit) est constant sur toutes les pages.

AVANT (lent / inutile) : laisser le core tout activer

“Avant” signifie : pas de code, donc WordPress charge ce qu’il juge utile. Sur beaucoup de blogs, c’est du poids gratuit.

Edge case : si vous avez une audience entreprise avec de vieux navigateurs (intranet, terminaux, etc.), vous pouvez choisir de garder ce support. Dans ce cas, ne désactivez pas les emojis, ou désactivez uniquement le prefetch si c’est votre objectif.

APRÈS (optimisé) : retirer actions/filtres + prefetch

Collez ce code dans votre mu-plugin. Il est compatible WordPress 6.9.4+.

<?php
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Désactive les emojis WordPress (front + admin) en retirant les actions/filtres core.
 * Gain : moins de JS et moins de traitements de contenu.
 *
 * Attention : si vous utilisez des emojis via l'éditeur, ils resteront des caractères Unicode.
 * Ce que vous perdez, c'est surtout la "compatibilité" avec d'anciens navigateurs.
 */
function bpcab_disable_emojis() : void {
	// Front-end.
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );

	// Admin.
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );

	// Emails / flux / contenu.
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

	// Éditeur (TinyMCE historique). Toujours présent pour compat.
	add_filter( 'tiny_mce_plugins', function ( array $plugins ) : array {
		return array_diff( $plugins, array( 'wpemoji' ) );
	} );
}
add_action( 'init', 'bpcab_disable_emojis' );

/**
 * Retire le DNS prefetch vers s.w.org souvent lié aux emojis.
 * Mesurable sur des audits réseau et parfois utile en environnement strict (RGPD/proxy).
 */
add_filter( 'wp_resource_hints', function ( array $urls, string $relation_type ) : array {
	if ( 'dns-prefetch' !== $relation_type ) {
		return $urls;
	}

	// Retire s.w.org si présent.
	return array_values(
		array_filter(
			$urls,
			static function ( $url ) {
				return ! is_string( $url ) || false === strpos( $url, 's.w.org' );
			}
		)
	);
}, 10, 2 );

Détail utile sur le code (ce que beaucoup de snippets n’expliquent pas) :

remove_action() retire une fonction qui était attachée à une action. Ici, WordPress attache print_emoji_detection_script à wp_head, donc vous la retirez du HTML <head>.
La priorité 7 dans remove_action( 'wp_head', ..., 7 ) doit correspondre à celle utilisée lors de l’ajout. Si vous mettez une autre priorité, ça ne retire rien. C’est une erreur classique quand on “réécrit” un snippet de mémoire.
Le filtre wp_resource_hints gère des hints comme dns-prefetch, preconnect, etc. Ici on se limite à dns-prefetch et on enlève uniquement s.w.org si présent.

Variante (edge case) : si vous voulez désactiver les emojis uniquement sur le front (et ne rien toucher à l’admin), vous pouvez entourer la partie “Admin” par un test. Je le fais parfois sur des sites où l’éditeur visuel doit rester “identique” pour les équipes :

<?php
function bpcab_disable_emojis_front_only() : void {
	// Front-end uniquement.
	if ( is_admin() ) {
		return;
	}

	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );

	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
}
add_action( 'init', 'bpcab_disable_emojis_front_only' );

Si vous utilisez cette variante, gardez une seule implémentation (ne laissez pas les deux fonctions actives en même temps).

Pourquoi c’est plus rapide

Moins de JS : vous retirez un fichier chargé sur le front (et parfois en admin).
Moins de filtres : chaque filtre sur le contenu est un passage supplémentaire lors du rendu.
Moins de “bruit” réseau : le prefetch DNS peut être superflu (et parfois indésirable).

Mesure de l’impact (simple et réaliste)

Sur des blogs que je maintiens, le gain typique est :

1 requête en moins (wp-emoji-release) sur le front,
quelques Ko de JS en moins,
parfois 10–30 ms de travail JS en moins sur mobile d’entrée de gamme (ça dépend énormément du reste).

Votre mesure “objective” : relancez votre log PERF SCRIPTS et vérifiez que wp-emoji-release n’est plus listé.

Edge case : si votre thème ou un plugin embarque son propre script “emoji”, vous verrez peut-être un autre handle. Dans ce cas, vous avez bien retiré le core, mais un autre composant en remet. Le log des handles sert précisément à le repérer.

Sources utiles :

Étape 2 : Désactiver wp-embed (oEmbed) quand vous n’en avez pas besoin

wp-embed est un script front utilisé pour certaines intégrations et comportements d’embed. Beaucoup de sites n’en ont pas besoin si :

vous n’intégrez pas de contenu via simple URL collée dans l’éditeur,
vous utilisez uniquement des iframes explicites (YouTube via iframe, par exemple),
votre page builder gère déjà ses propres embeds.

Attention : si vous publiez des articles avec des embeds WordPress (ou si vous utilisez souvent des URLs “magiques” dans Gutenberg), testez sur 2–3 contenus existants avant de déployer partout.

Ce qui piège souvent : vous pouvez ne plus “utiliser” d’embed aujourd’hui, mais avoir des anciens articles où vous aviez collé une URL YouTube/Spotify. Sans wp-embed, certains comportements associés peuvent changer. Ce n’est pas forcément “cassé”, mais ce n’est plus identique.

AVANT (lent / par défaut) : wp-embed est chargé

Sans optimisation, wp-embed peut être enqueued sur le front.

Edge case : certains thèmes n’enqueue pas wp-embed sur toutes les pages. D’où l’intérêt de mesurer via le log : ne supprimez pas un truc qui n’est pas là (ça ne fait pas de mal, mais vous perdez du temps).

APRÈS (optimisé) : désenregistrer le script wp-embed

Ajoutez ce code dans le même mu-plugin.

<?php
/**
 * Désactive le script wp-embed sur le front.
 * Gain : 1 requête JS en moins (souvent), moins de JS à parser.
 *
 * Risque : certains embeds ou fonctionnalités liées peuvent ne plus fonctionner.
 * Testez sur quelques articles contenant des intégrations avant de généraliser.
 */
add_action( 'wp_enqueue_scripts', function () {
	if ( is_admin() ) {
		return;
	}

	// Désenregistre wp-embed (handle core).
	wp_deregister_script( 'wp-embed' );
}, 100 );

Détail : wp_deregister_script() supprime l’enregistrement d’un script (son “handle”) du registre de WordPress. Si un autre composant tente ensuite de l’enqueue, il peut échouer… ou le ré-enregistrer. C’est pour ça que la priorité et la mesure comptent.

Edge case important : si un plugin ré-enqueue wp-embed après votre code (priorité plus haute), vous verrez encore wp-embed dans la queue. Dans ce cas, augmentez la priorité (ex. 999) ou identifiez le plugin fautif via Query Monitor.

Pourquoi la priorité (100) compte

J’ai souvent croisé le cas où un thème (ou Elementor/Divi/Avada via modules) ré-enqueue des scripts tard. Si vous désenregistrez trop tôt, le script peut revenir. Une priorité élevée rend l’intention plus fiable.

Variante : vous pouvez même aller plus loin et désenqueuer (retirer de la queue) en plus de désenregistrer, si vous tombez sur un cas où le script a déjà été ajouté :

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

	// Retire de la queue si déjà enqueued, puis désenregistre.
	wp_dequeue_script( 'wp-embed' );
	wp_deregister_script( 'wp-embed' );
}, 999 );

Cette variante est utile quand un thème enqueued tôt et qu’un autre plugin ré-enqueue tard. Vous “nettoyez” à la fin.

Compatibilité Divi 5 / Elementor / Avada

Divi 5 : la plupart des modules n’ont pas besoin de wp-embed, mais si vous collez des URLs dans des modules “Texte” en espérant un embed auto, vous pouvez perdre cette conversion.
Elementor : les widgets dédiés (YouTube, Vimeo, etc.) utilisent généralement leurs propres iframes et ne dépendent pas de wp-embed. Les embeds via contenu WYSIWYG peuvent être impactés.
Avada : Fusion Builder a ses éléments d’intégration. Même remarque : testez les pages qui utilisent du contenu collé “en URL brute”.

Dans la pratique : si vous utilisez un widget “Vidéo” (Elementor) ou un module “Vidéo” (Divi/Avada), vous êtes généralement tranquille. Si vous utilisez un bloc “Paragraphe” et que vous collez une URL en espérant que WordPress fasse le reste, testez.

Source : wp_deregister_script() (developer.wordpress.org).

Étape 3 : Nettoyer côté éditeur et côté front (sans casser Gutenberg)

Quand on parle “performance”, beaucoup de débutants désactivent tout partout. Mauvaise idée : l’admin et l’éditeur de blocs (Gutenberg) ont des besoins différents du front.

Objectif : optimiser le front (pages vues par les visiteurs), sans rendre l’édition pénible.

Règle simple : tout ce qui touche à l’expérience visiteur se traite sur le front. Tout ce qui touche au confort d’édition se traite dans l’admin, et on évite de le casser “pour gagner 5 Ko”.

Option : désactiver wp-embed seulement sur certaines pages

Si vous avez un blog avec quelques articles qui utilisent des embeds, vous pouvez conditionner la désactivation. Exemple : on garde wp-embed sur les articles (is_single()), mais on le supprime sur la home, pages, archives.

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

	// Exemple de stratégie : garder wp-embed sur les articles (single).
	if ( is_single() ) {
		return;
	}

	wp_deregister_script( 'wp-embed' );
}, 100 );

C’est moins “agressif”, et ça évite de casser un ancien contenu que vous auriez oublié.

Variantes utiles (edge cases) :

Garder wp-embed sur un CPT (Custom Post Type = type de contenu personnalisé) : remplacez is_single() par is_singular( 'votre_cpt' ) ou is_singular() selon votre besoin.
Garder wp-embed uniquement si le contenu contient un embed : c’est plus précis, mais ça demande de détecter. Je montre un exemple “pragmatique” juste après.
WooCommerce : si vous avez des pages produit avec des contenus intégrés, testez is_product() (fonction WooCommerce) avant de désactiver globalement.

Option : journaliser les pages qui enqueued wp-embed

Pratique quand vous voulez savoir où le script est réellement utilisé.

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

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

	if ( in_array( 'wp-embed', $wp_scripts->queue, true ) ) {
		error_log( '[PERF] wp-embed enqueued on URL: ' . home_url( add_query_arg( null, null ) ) );
	}
}, 999 );

Dans mon expérience, vous découvrez souvent qu’un plugin “social” ou un bloc spécifique l’ajoute alors que vous ne l’utilisez plus.

Edge case : home_url( add_query_arg( null, null ) ) est pratique, mais si votre site est derrière un proxy/CDN avec des réécritures, l’URL logguée peut être différente de ce que vous voyez en navigateur. Ce n’est pas grave : l’important est d’identifier le template / la route (home, archive, single…).

Exemple de code supplémentaire (concret) : désactiver wp-embed seulement si la page n’en a pas besoin

Quand je veux un compromis propre, j’utilise une règle simple : si on est sur une page “singular” (article/page) et que le contenu contient des URLs susceptibles d’être auto-embeddées, je garde wp-embed. Sinon je le retire.

Ce n’est pas une science exacte (oEmbed dépend aussi des providers), mais c’est efficace pour éviter de casser des contenus existants tout en supprimant wp-embed sur la majorité des pages.

Ajoutez ce code dans votre mu-plugin à la place de la désactivation globale de wp-embed (ne gardez pas deux stratégies en parallèle).

<?php /** * Désactive wp-embed de façon "intelligente". * - On ne garde wp-embed que si on est sur un contenu singular (page/article) * ET que le contenu semble contenir une URL qui pourrait déclencher un oEmbed. * * Objectif : éviter de casser d'anciens articles où vous aviez collé une URL (YouTube, etc.) * tout en supprimant wp-embed sur home/archives/pages "listing". */ add_action( 'wp_enqueue_scripts', function () { if ( is_admin() ) { return; } // Par défaut : on retire. $keep = false; if ( is_singular() ) { $post = get_post(); if ( $post instanceof WP_Post ) { $content = (string) $post->post_content; // Détection simple : présence d'une URL sur une ligne seule (cas courant de l'auto-embed). // On couvre http/https + www. $has_standalone_url = (bool) preg_match( '~(^|R)s*(https?://S+|www.S+)s*(R|$)~i', $content ); // Détection d'un shortcode embed explicite (rare mais existe). $has_embed_shortcode = ( false !== stripos( $content, '.

Vous évitez la situation “j’ai désactivé wp-embed et un vieux contenu a changé”.

Limites (à connaître) :

Si votre contenu contient une URL au milieu d’un paragraphe (pas sur une ligne seule), ce test peut ne pas la détecter, alors que votre thème/plugin pourrait quand même en faire quelque chose.
Certains page builders stockent des données d’embed dans des métas (postmeta) plutôt que dans post_content. Dans ce cas, cette détection ne les verra pas. C’est rare pour les embeds “classiques”, mais ça arrive.

Configuration serveur

Désactiver emojis/wp-embed réduit surtout des requêtes et du JS. Le serveur peut amplifier le gain si vous servez ces pages avec de bons en-têtes cache et de la compression.

Point débutant : si votre site a un cache de page (plugin de cache, cache serveur, cache CDN), le “ressenti” peut être excellent même avec beaucoup de JS. Mais les Core Web Vitals (LCP/INP) restent sensibles au poids front. D’où l’intérêt de faire les deux : cache + nettoyage.

.htaccess (Apache) : compression et cache navigateur

Si vous êtes sur Apache avec .htaccess actif, vous pouvez ajouter (ou vérifier) ces règles. Sauvegardez votre fichier avant : une faute de syntaxe peut mettre le site en 500.

# .htaccess — exemple (Apache)
# Active la compression (si mod_deflate est disponible)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>

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

Pourquoi c’est pertinent ici : si vous retirez des scripts, vous réduisez des requêtes. Avec un cache navigateur correct, le reste coûte encore moins aux visiteurs récurrents.

Edge case : si vous utilisez déjà un plugin de cache (ou un CDN type Cloudflare), vous avez peut-être déjà des règles équivalentes. Ne dupliquez pas sans vérifier, sinon vous pouvez vous retrouver avec des en-têtes contradictoires.

wp-config.php : object cache et limites mémoire (diagnostic)

Je ne vous conseille pas de “tuner au hasard”, mais deux constantes reviennent souvent en dépannage :

<?php
// wp-config.php — exemples.
// Augmenter la mémoire PHP côté WordPress si vous êtes trop bas (évite des lenteurs/erreurs).
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si votre hébergeur limite PHP à 128M, ces constantes ne feront pas de miracle, mais elles évitent un plafond trop bas sur certains environnements.

Edge case : si vous voyez des erreurs du type “Allowed memory size exhausted” dans les logs, augmentez d’abord la mémoire, puis cherchez la cause (plugin lourd, requête massive, autoload énorme). Augmenter la mémoire sans diagnostiquer ne règle pas le fond.

php.ini / PHP-FPM : OPcache (si vous avez la main)

OPcache accélère PHP en évitant de recompiler les scripts à chaque requête. Ce n’est pas spécifique à emojis/wp-embed, mais si votre TTFB est instable, c’est un gros suspect.

; php.ini — exemples (les valeurs exactes dépendent du serveur)
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 (php.net).

Edge case : sur certains hébergements, OPcache est activé mais sous-dimensionné (trop peu de mémoire, trop peu de fichiers). Résultat : “cache misses” fréquents et TTFB irrégulier. Si vous avez accès aux métriques OPcache (phpinfo ou status), c’est vite visible.

Vérification des résultats

Vous voulez vérifier sans “ressenti”. Faites simple : mesurez ce qui change réellement.

1) Vérifier que les scripts ont disparu (logs)

Après déploiement, rechargez 2–3 pages en étant connecté admin, puis ouvrez wp-content/debug.log. Vous devez voir :

wp-emoji-release present? NO
wp-embed present? NO (si vous l’avez désactivé)

Si vous voyez encore “YES”, c’est généralement :

vous avez collé le code dans functions.php du thème parent (et le thème a été mis à jour),
un plugin ré-enqueue le script après vous,
vous regardez une page servie par cache/CDN qui n’a pas été purgé.

Edge case : si vous utilisez un cache “HTML statique” qui ne laisse pas passer le cookie de session admin, vous pouvez être connecté dans WordPress mais voir une page cachée. Dans ce cas, faites un test sur une URL exclue du cache (ou désactivez le cache 2 minutes).

2) Mesurer le nombre de scripts et le temps PHP (mini-instrumentation)

Ce bloc ajoute un en-tête HTTP Server-Timing avec le temps de génération côté WordPress et le nombre de scripts/styles. C’est très pratique avec les DevTools réseau, et ça ne nécessite pas de plugin.

Ajoutez-le dans votre mu-plugin (et gardez-le si vous voulez un monitoring léger).

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

	// Uniquement pour les admins connectés (évite de divulguer des métriques à tout le monde).
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wp_scripts, $wp_styles;

	$script_count = ( $wp_scripts instanceof WP_Scripts ) ? count( $wp_scripts->queue ) : 0;
	$style_count  = ( $wp_styles instanceof WP_Styles ) ? count( $wp_styles->queue ) : 0;

	// timer_stop() renvoie le temps depuis le début du chargement WP (en secondes).
	$php_seconds = function_exists( 'timer_stop' ) ? (float) timer_stop( 0, 3 ) : 0.0;

	header(
		sprintf(
			'Server-Timing: wp;dur=%.3f, scripts;desc="scripts";dur=%d, styles;desc="styles";dur=%d',
			$php_seconds * 1000,
			$script_count,
			$style_count
		)
	);
}, 999 );

Comment lire ça (débutant) : dans l’onglet Réseau de votre navigateur, cliquez la requête HTML principale, puis cherchez Server-Timing. Vous verrez un temps “wp” (durée PHP approximative) et deux compteurs “scripts/styles”. Si vous retirez wp-embed, le compteur scripts baisse souvent de 1.

Source : timer_stop() (developer.wordpress.org).

3) Refaire un test Core Web Vitals

Pour rester “code-first”, vous pouvez automatiser une mesure Lighthouse en CLI (si vous avez Node sur votre machine locale). Exemple :

# Exemple local (nécessite Node + Lighthouse)
lighthouse https://votre-site.tld/ --only-categories=performance --output=json --output-path=./lh.json

Vous cherchez surtout : baisse du JS total, moins de requêtes, et parfois un petit mieux sur INP.

Edge case : Lighthouse est sensible aux variations réseau/CPU. Faites 3 runs et comparez une médiane. Et comparez la même page (par exemple la home) avant/après.

Si les performances ne s’améliorent pas

Ça arrive souvent : vous retirez 1–2 scripts, mais le site reste lent. Dans ce cas, le goulot n’est pas là.

Étape A : distinguer TTFB (serveur) vs rendu (front)

TTFB élevé : problème PHP/MySQL, cache page absent, thème lourd, requêtes lentes.
TTFB correct mais LCP/INP mauvais : trop de JS/CSS, images, polices, scripts tiers.

Dans mon expérience, beaucoup de débutants confondent les deux. Retirer wp-embed ne fera presque rien sur un TTFB à 1,5s. À l’inverse, un cache page excellent ne réglera pas un INP dégradé par 700 Ko de JS tiers.

Étape B : activer temporairement SAVEQUERIES + log des requêtes lentes

Attention : SAVEQUERIES ralentit. Activez-le 5 minutes, sur un environnement de staging si possible.

<?php
// wp-config.php (temporaire)
define( 'SAVEQUERIES', true );

Puis logguez les requêtes les plus longues en fin de requête :

<?php
add_action( 'shutdown', function () {
	if ( ! defined( 'SAVEQUERIES' ) || true !== SAVEQUERIES ) {
		return;
	}
	if ( is_admin() ) {
		return;
	}
	if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
		return;
	}

	global $wpdb;
	if ( empty( $wpdb->queries ) || ! is_array( $wpdb->queries ) ) {
		return;
	}

	$slow = array();

	foreach ( $wpdb->queries as $q ) {
		// Format: [ query, time, caller ]
		$sql  = $q[0] ?? '';
		$time = (float) ( $q[1] ?? 0 );
		$from = $q[2] ?? '';

		if ( $time >= 0.05 ) { // 50ms
			$slow[] = array( 'time' => $time, 'sql' => $sql, 'caller' => $from );
		}
	}

	usort( $slow, static fn( $a, $b ) => $b['time'] <=> $a['time'] );

	error_log( '--- PERF SLOW QUERIES (top 10) ---' );
	foreach ( array_slice( $slow, 0, 10 ) as $row ) {
		error_log( sprintf( '%.4fs | %s | %s', $row['time'], $row['caller'], $row['sql'] ) );
	}
}, 999 );

Si vous voyez des requêtes lentes, le gain de retirer emojis/wp-embed sera noyé. Il faudra traiter la base, le thème, ou ajouter un cache objet.

Edge case : si vous êtes derrière un cache page, vous ne verrez pas ces logs sur les pages servies par cache (WordPress ne s’exécute pas). Testez sur une page exclue du cache ou videz le cache avant chaque test.

Étape C : vérifier les scripts tiers

Dans la vraie vie, le “gros” vient souvent de :

Google Tag Manager + tags multiples,
pixels publicitaires,
chat widgets,
polices externes non optimisées.

Votre log des scripts (Handles:) est un bon point de départ pour identifier qui charge quoi.

Variante “code only” utile : si vous repérez un handle tiers (ex. un plugin social) et que vous voulez mesurer son coût, vous pouvez temporairement le désenqueuer sur une page test et comparer vos en-têtes Server-Timing + vos runs Lighthouse CLI.

Pièges et erreurs courantes

Les erreurs ci-dessous sont celles que je vois le plus souvent quand quelqu’un “colle un snippet” trouvé sur un vieux tutoriel.

Erreurs fréquentes (et comment les éviter)

Coller le code dans le mauvais fichier : functions.php du thème parent au lieu d’un thème enfant ou d’un mu-plugin. Résultat : tout disparaît à la prochaine mise à jour.
Oublier un point-virgule : écran blanc / erreur 500. Testez d’abord sur staging, ou activez les logs.
Mauvais hook : désenregistrer wp-embed sur init peut fonctionner… ou pas, selon l’ordre d’enqueue. Préférez wp_enqueue_scripts avec priorité élevée.
Conflit de cache : vous mesurez une page servie par cache/CDN d’avant la modif. Purgez le cache page et le CDN.
Tester sur production sans sauvegarde : un snippet mal copié peut bloquer l’admin. Ayez un accès FTP/SSH prêt.
Code d’ancien tutoriel : certains snippets retirent des hooks qui ont bougé selon versions. Sur WP 6.9.4, utilisez des références officielles et testez.

Pièges que je vois spécifiquement avec Divi/Elementor/Avada :

Optimisation “globale” dans un plugin de perf : vous désactivez wp-embed via un toggle, puis votre page builder met à jour et change la façon dont il gère certains contenus. Résultat : vous ne savez plus si c’est le builder ou le toggle qui casse. Le mu-plugin rend le comportement explicite et versionnable.
Minification/déferrement agressif : certains outils appliquent defer à tous les scripts, y compris ceux que WordPress attend “bloquants”. Ça peut dégrader l’INP ou casser des interactions. Ici, on supprime d’abord l’inutile, ce qui évite d’avoir à “défer” n’importe quoi.
Tester uniquement la home : votre home peut ne pas charger wp-embed, alors qu’un article le charge. Testez au moins : home + une archive + un article + une page builder “lourde”.

Tableau de diagnostic

Symptôme	Cause probable	Vérification	Solution
wp-emoji-release est encore chargé	Snippet non exécuté / mauvais emplacement	Vérifier `wp plugin list --status=must-use` et `debug.log`	Mettre le code dans un mu-plugin, vérifier le chemin `wp-content/mu-plugins/`
wp-embed revient après purge	Un plugin/thème ré-enqueue tard	Logger `$wp_scripts->queue` à priorité 999	Désenregistrer à priorité 100+, ou conditionner selon pages
Des embeds (URL collées) ne s’affichent plus	wp-embed/oEmbed nécessaire	Tester un article avec intégration via URL brute	Réactiver wp-embed sur `is_single()` ou uniquement sur certains templates
Pas de gain visible sur PageSpeed	Le goulot est ailleurs (scripts tiers / images / TTFB)	Comparer TTFB vs LCP/INP, inspecter scripts tiers	Optimiser images, fonts, cache page, scripts tiers, DB
Erreur 500 après ajout du code	Erreur PHP (syntaxe, PHP trop ancien)	Consulter logs serveur + `wp-content/debug.log`	Corriger la syntaxe, vérifier PHP 8.1+, restaurer sauvegarde

Conseils de maintenance

Gardez vos optimisations dans un mu-plugin : plus simple à auditer et plus robuste qu’un plugin de snippets.
Documentez vos conditions : si vous gardez wp-embed sur is_single(), notez pourquoi dans un commentaire.
Surveillez les regressions : après ajout d’un plugin social ou d’un nouveau module Divi/Elementor/Avada, re-logguez la queue des scripts 1 minute.
Automatisez un mini-check : une fois par mois, lancez un Lighthouse CLI ou un test de requêtes sur 2–3 pages clés.
Évitez les “optimizers” agressifs qui combinent/déférent tout sans contrôle : j’ai vu des pages builders casser à cause d’un defer global mal appliqué.

Variante utile : gardez votre mu-plugin en “modules” (fonctions séparées, commentaires, et un switch en haut). Quand vous dépannez, vous pouvez activer/désactiver une optimisation proprement sans supprimer du code.

Ressources

FAQ

Est-ce que désactiver les emojis supprime les emojis de mes contenus ?

Non. Vos emojis restent des caractères Unicode dans la base et dans le HTML. Vous retirez surtout le script de détection et les filtres de compatibilité. Sur des navigateurs modernes, c’est généralement sans impact visible.

Est-ce que c’est compatible avec WordPress 6.9.4 ?

Oui, les approches via remove_action/remove_filter et wp_deregister_script restent compatibles. Évitez les vieux snippets qui modifient des fichiers core.

Pourquoi utiliser un mu-plugin plutôt que functions.php ?

Parce que functions.php dépend du thème actif. Un changement de thème (ou une mise à jour du thème parent) peut faire disparaître vos optimisations. Un mu-plugin est chargé automatiquement et reste en place.

Est-ce que wp-embed est nécessaire pour YouTube ?

Pas si vous utilisez un iframe (ou un widget de page builder qui génère un iframe). Il peut être nécessaire si vous comptez sur l’auto-embed en collant simplement une URL dans l’éditeur, selon les cas.

Je désactive wp-embed et certaines intégrations ne marchent plus : que faire ?

Réactivez-le uniquement là où nécessaire (ex. is_single()), ou sur un modèle de page spécifique. C’est souvent le meilleur compromis.

Pourquoi je vois encore les scripts après la modification ?

Trois causes classiques : cache page/CDN non purgé, code collé au mauvais endroit, ou un plugin ré-enqueue le script après vous. Utilisez le logging de la queue des scripts à priorité 999 pour trancher.

Est-ce que ça améliore vraiment les Core Web Vitals ?

Parfois un peu, surtout sur mobile. Le gain est rarement spectaculaire seul, mais c’est un nettoyage “à faible risque” (surtout emojis) qui réduit le JS total et le nombre de requêtes.

Est-ce que je dois aussi minifier/concaténer les scripts ?

Pas automatiquement. Sur WordPress moderne + HTTP/2/3, la concaténation n’est pas toujours bénéfique. Commencez par supprimer l’inutile (comme ici), puis déférer/retarder les scripts tiers lourds.

Que faire si mon site est lent malgré tout ?

Traitez d’abord : cache page, images (LCP), scripts tiers, requêtes lentes (SAVEQUERIES temporaire), et mettez en place un cache objet (Redis/Memcached) si votre site est dynamique.

Est-ce que ces optimisations affectent l’admin WordPress ?

Le snippet emojis retire aussi les styles/scripts en admin. En pratique, c’est rarement gênant. Si vous voulez être prudent, vous pouvez limiter la désactivation emojis au front uniquement.

Puis-je faire ça via un plugin de cache ?

Certains plugins proposent des toggles “Disable Emojis” et “Disable Embeds”. C’est pratique, mais j’ai vu des options changer lors d’une mise à jour de plugin. Le mu-plugin reste la méthode la plus prévisible et auditable.