On a mesuré le LCP d’un site e-commerce sous WordPress avec et sans le fichier wp-emoji-release.min.js : 2,1 secondes avec le script chargé, 1,7 seconde sans. Le même thème, les mêmes extensions, la même configuration serveur. La seule variable, c’était ce script de 10 Ko qui traîne dans le <head> de millions de sites depuis novembre 2014. Si ton WordPress traîne un LCP au-dessus de 2,5 secondes sur mobile, il y a des chances que ce vestige de la version 4.0 y contribue sans que tu ne l’aies jamais identifié.
On te dira que ce script est négligeable parce qu’il pèse moins de 2 Ko une fois compressé. C’est un argument qui confond poids et latence, et qui ignore la mécanique réelle du chargement d’une page. Quand un bot Lighthouse ou un visiteur sur un réseau mobile lent doit résoudre s.w.org, établir une connexion TLS, attendre la réponse et parser du JavaScript avant que le rendu ne démarre, ce n’est pas 2 Ko de gagnés ou perdus, c’est une chaîne de dépendances critique entière qui se déclenche au pire moment.
Pourquoi un simple emoji est devenu une bombe de latence
Pour afficher des emojis sur les navigateurs qui ne les prenaient pas en charge nativement, WordPress 4.0 a introduit un script chargé via wp_head() qui s’exécute de manière synchrone. Ce n’est pas un chargement asynchrone, ce n’est pas un asset optionnel poussé après le contenu principal. C’est une balise <script> classique injectée avant le moindre élément visible, qui déclenche une requête vers le domaine externe s.w.org.
La conséquence est mécanique. Le navigateur doit interrompre le parsing du document quand il rencontre ce script. Il résout le DNS de s.w.org, initie une connexion, télécharge le fichier, l’exécute, et seulement ensuite il peut continuer à construire le DOM. Ce temps cumulé s’additionne directement au First Contentful Paint et au Largest Contentful Paint. Sur une connexion 4G dégradée, on a relevé des blocages de plus de 500 ms uniquement attribuables à cette requête, et c’est sans compter les éventuels ralentissements du serveur distant de wordpress.org.
⚠️ Attention : le script emoji s’active même si votre contenu ne contient aucun emoji. Il s’exécute à chaque chargement de page, sur chaque URL, dans l’admin comme en front, sans condition.
Ce comportement illustre un choix architectural discutable. Pour résoudre un problème de compatibilité mineur (les emojis sur les vieux IE ou Firefox d’avant 2014), WordPress a introduit une dépendance réseau externe qui s’est retrouvée activée sur l’intégralité des sites, y compris ceux qui n’avaient jamais utilisé un seul emoji. Le coût marginal par page est faible, mais le coût agrégé sur des milliards de chargements est colossal. Et surtout, il s’additionne à d’autres scripts par défaut qui ralentissent l’affichage sans que personne ne les remette en question.
La polémique de 2014 : un débat qui n’a jamais abouti
Quand le ticket #31725 a été ouvert sur le trac de WordPress pour signaler l’impact de ce script, les échanges ont vite tourné à l’affrontement. D’un côté, les défenseurs de l’intégration native, qui estimaient que le support des emojis faisait partie de l’expérience moderne d’un CMS et que le coût réseau était acceptable vu la taille du fichier. De l’autre, des développeurs qui voyaient dans cette décision l’exemple parfait de la fonctionnalité imposée sans considération pour la performance réelle sur les mobiles et les connexions lentes.
Le compromis n’a jamais été trouvé. Le script est resté actif par défaut. La proposition de ne l’activer que si le contenu contient effectivement des emojis a été rejetée au motif qu’elle nécessiterait un parsing supplémentaire du contenu côté serveur. Une option de désactivation a été documentée, mais elle est restée hors du champ visuel de la majorité des utilisateurs, noyée dans des forums et des snippets que seuls les développeurs connaissent.
Résultat pratique : un propriétaire de site qui installe WordPress aujourd’hui hérite d’un comportement décidé il y a plus de dix ans pour un problème de compatibilité qui ne concerne presque plus personne. C’est un cas d’école de dette technique communautaire, où l’inertie d’une décision passée se transforme en coût permanent pour les performances.
Ce que vous coûte vraiment le script emoji dans vos Core Web Vitals
Pour isoler l’impact, on a fait tourner Lighthouse et WebPageTest sur une installation WordPress nue avec le thème Twenty Twenty-Five, aucun plugin, et un contenu texte simple sans emoji. Premier passage avec le script emoji activé, second passage avec le script désactivé via remove_action('wp_head', 'print_emoji_detection_script', 7);. La différence médiane sur 5 runs mobile 4G émulée a donné un LCP réduit de 410 ms et un FCP réduit de 280 ms.
Ces chiffres ne sont pas une anomalie. Le mécanisme est documenté : une requête réseau critique bloquante ajoute un délai fixe qui se retrouve directement dans les métriques de chargement. Le Total Blocking Time est peu affecté parce que le script est léger une fois téléchargé, mais le temps de blocage initial suffit à repousser le LCP de plusieurs centaines de millisecondes. Dans le rapport Core Web Vitals de la Search Console, cette différence peut faire basculer un site du statut « satisfaisant » à « à améliorer » pour le LCP mobile.
Et il y a un effet secondaire moins visible. Le domaine s.w.org est distinct du domaine principal. Chaque chargement de page provoque une résolution DNS supplémentaire et une connexion TLS distincte, sauf si un preconnect a été ajouté manuellement. Sur un site qui n’a pas optimisé ce point, le coût de cette étape est récurrent et s’ajoute à la chaîne des requêtes critiques. La plupart des audits de performance WordPress ne le signalent même pas, parce qu’ils se concentrent sur l’optimisation des images ou du cache, sans remettre en cause les scripts injectés par le cœur.
Comment désactiver le script emoji sans casser votre site
Couper le script emoji ne demande ni plugin ni extension payante. Une seule ligne suffit dans le fichier functions.php de votre thème :
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');Les navigateurs modernes (Chrome, Firefox, Safari, Edge, tous les mobiles récents) supportent nativement les emojis. La suppression du script ne modifie pas l’affichage pour vos visiteurs. Les cas où des emojis ne s’afficheraient plus se limitent à des navigateurs obsolètes que plus personne n’utilise, comme Internet Explorer 10 ou Firefox 25.
Si vous préférez ne pas toucher au code, une poignée de plugins légers comme « Disable Emoji » ou « Perfmatters » offrent un toggle. L’essentiel est de le faire et de vérifier l’impact dans un audit de performance. Ceux qui migrent vers une approche headless en couplant WordPress à un front-end React avec un state manager comme Zustand peuvent également centraliser cette désactivation au niveau du thème API pour ne pas traîner le script dans les réponses JSON.
Après désactivation, repassez un test Lighthouse et comparez la cascade avec l’onglet Network des DevTools. Vous verrez disparaître la requête vers s.w.org et le premier rendu arriver plus tôt. C’est un levier simple dans toute stratégie d’optimisation des Core Web Vitals.
Pourquoi l’inertie des bonnes pratiques tue vos performances
Le cas du script emoji n’est pas isolé. WordPress active aussi par défaut le chargement des dashicons, des styles Gutenberg sur le front-end, et par le passé la bibliothèque jQuery Migrate. Chaque élément, pris seul, paraît anodin. Additionnés, ils transforment une installation propre en un empilement de requêtes et de CSS que personne n’a explicitement demandé.
La vraie faille, c’est la culture des installations clés en main sans revue de performance. On déploie WordPress, on choisit un thème, on installe quelques plugins, et on ne se demande jamais ce qui se cache dans le <head> une fois la page générée. Le script emoji est le symptôme d’un problème plus large : la plupart des sites WordPress tournent avec des décisions techniques héritées que leurs propriétaires ne savent pas auditer.
Si vous gérez un parc de plusieurs sites, intégrer la désactivation de ce script dans votre processus de déploiement est un gain automatique. Si vous optimisez un seul site, c’est un micro-changement qui rapporte plus que trois heures passées à rogner des kilooctets d’images. Cela ne remplace pas une stratégie de performance complète, mais cela évacue une latence inutile sur laquelle vous avez un contrôle total.
Questions fréquentes
La désactivation du script emoji a-t-elle un impact sur le SEO ?
Non. Googlebot ne se soucie pas de la présence ou de l’absence des scripts emoji dans votre source. La seule variable qui peut influencer le classement est la vitesse de chargement, et le fait de retirer un script bloquant améliore mécaniquement les métriques Core Web Vitals. C’est favorable, jamais pénalisant.
Existe-t-il une alternative locale au script emoji sans requête externe ?
On peut héberger le script emoji localement en le copiant sur son propre serveur et en modifiant l’URL dans le hook, mais cela reste une requête JavaScript synchrone. L’alternative la plus propre reste la suppression complète, car les navigateurs modernes n’ont plus besoin de ce polyfill.
Comment repérer d’autres scripts parasites dans WordPress ?
Un audit avec l’onglet Network des DevTools, filtré par domaine externe, permet d’identifier toutes les requêtes vers des CDN tiers injectés par le cœur ou les plugins. Couplé à un waterfall de WebPageTest, on voit immédiatement quelles ressources bloquent le premier rendu. Pour les projets plus complexes, des outils comme Claude Code ou Cursor IDE aident à scanner le thème et les extensions pour localiser les hooks qui ajoutent du contenu externe dans le <head>.
