Table des matières
Qu’est-ce que le thread principal ?
L’analyse de votre site web avec PageSpeed Insights peut vous signaler ce problème de performance front-end, assez classique dès qu’on a un peu trop de JS au mètre carré :
Réduisez le travail du thread principal
Envisagez de réduire le temps consacré à l’analyse, la compilation et l’exécution de JavaScript. La livraison de charges utiles JavaScript plus petites peut vous aider
PageSpeed fournit ensuite un lien vers une page qui donne une explication plus détaillée et un poil plus technique de ce problème d’optimisation :
Le processus de rendu du navigateur transforme votre code en une page Web avec laquelle vos utilisateurs peuvent interagir. Par défaut, le thread principal du processus de moteur de rendu gère généralement la plupart des codes : il analyse le code HTML et compile le DOM, analyse le CSS et applique les styles spécifiés, puis analyse, évalue et exécute le code JavaScript.
Le thread principal traite également les événements utilisateur. Par conséquent, chaque fois que le thread principal est occupé à effectuer une autre opération, votre page Web peut ne pas répondre aux interactions utilisateur, ce qui nuit à l’expérience.
On comprend donc que le « thread principal » est en fait la liste de toutes les tâches que le navigateur a à faire quand il calcule le rendu d’une page web, bref : le pipeline critique de rendu qui bosse non-stop.
PageSpeed vous donne une analyse précise de chaque composante du problème, en mesurant le temps de processeur occupé par chaque type de tâche (un peu comme un profiler pour navigateur, mais en version light et automatisée) :
Ici, on voit que c’est la tâche de « Script evaluation« , liée au traitement du JavaScript, qui prend le plus de temps. 1016 millisecondes soit un peu plus d’une seconde, ce qui est énorme à l’échelle d’une interaction utilisateur (et du Time to Interactive).
Vient ensuite le « Style & Layout« , c’est à dire Style et mise en page, le calcul du CSS et du DOM, tout ce qui touche au reflow / repaint et à la construction du rendu visuel.
Puis d’autres tâches moins gourmandes en calcul, mais qui s’additionnent sournoisement : parsing HTML, garbage collector, gestion des events, etc.
Comment optimiser le travail du thread principal ?
Soyons clair. Je n’ai pas de réponse universelle à cette question. Je n’ai que des éléments de réponse. C’est déjà ça ! Et honnêtement, en perfs web, les recettes magiques n’existent pas : c’est toujours du cas par cas.
Pas de plugin
La doc de PageSpeed indique que la technologie des Web Workers permet de décharger le thread principal de tâches lourdes, et donc d’optimiser le temps de chargement et la réactivité globale de l’UI.
J’ai cherché « Web Workers » et « main thread » dans le répertoire des plugins de WordPress. Histoire de voir s’il y avait une solution clé en main, un plugin magique qui ferait tout à ma place (spoiler : non).
Je n’en ai trouvé qu’un : Web Worker Offloading. Mais ce n’est pas un plugin simple d’utilisation, il demande des compétences de codeur JavaScript que je n’ai pas vraiment envie de sous-estimer. Il faut comprendre l’architecture du site, les dépendances, les effets de bord, bref c’est pas plug-and-play.
Conclusion, aucun plugin d’optimisation ne sait réduire le travail du thread principal de façon fiable, générique et sans risque de casser la moitié de votre front.
Je pense que cette situation s’explique par l’impossibilité d’automatiser la création de Web Workers. Cette création implique de modifier le code du JS utilisé par tel site, de réorganiser la logique métier, de gérer la communication via postMessage. Et ne peut donc se faire qu’au cas par cas, à la main, par quelqu’un qui sait ce qu’il fait (un dev front un peu sérieux, disons).
En diminuant le volume de données à traiter
Puisqu’on ne peut pas facilement déléguer le travail du thread principal à des Web Workers, une solution consiste à réduire sa quantité de travail. C’est basique, mais diablement efficace en optimisation de performances.
Il n’y aura toujours qu’un seul fil, mais moins long. Moins de JS, moins de CSS, moins de DOM : moins de boulot pour le navigateur.
Comment faire ? Simplement en supprimant de la complexité. Si PageSpeed se plaint que le JS prend trop longtemps à calculer, alors supprimez du JS. Ça paraît brutal, mais souvent c’est la seule vraie solution durable.
Beaucoup de plugins ont la manie d’ajouter du JS et du CSS, causant souvent un problème de ressources JS inutilisées et de ressources CSS inutilisées. Repérez les plugins qui contribuent le plus à ce problème, et supprimez-les ou remplacez-les par des alternatives plus légères.
Dès lors que vous éliminez certaines bibliothèques de gadgets, utilisées à 1% et qui ajoutent dans les 200-300 ko de JS à calculer (voire plus, avec certaines usines à gaz), vous économisez forcément en temps de calcul et vous améliorez vos Core Web Vitals.
Ex : supprimer les emoji, les intégrations oEmbed et les blocs Gutenberg
WordPress de base est fourni avec certaines ressources qui restent inutilisées sur beaucoup de sites, surtout les sites vitrines un peu simples :
- les emoji, ou émoticones, chargés automatiquement pour pas grand-chose
- les intégrations oEmbed, qui transforment les liens en blocs formatés, pratiques mais pas indispensables
- les styles de blocs Gutenberg, cette horrible usine à gaz (à mon avis) quand on n’utilise pas l’éditeur de blocs
Pour désactiver ces bidules qui en général ne servent à rien et gagner un peu de temps de thread, allez éditer le fichier functions.php de votre thème enfant, et ajoutez du code. Oui, à l’ancienne ; mais au moins vous contrôlez précisément ce qui se charge.
Pour désactiver les emoji :
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
Pour désactiver les blocs Gutenberg :
function custom_cleanup_assets() {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
}
add_action( 'wp_enqueue_scripts', 'custom_cleanup_assets', 100 );
Pour désactiver oEmbed :
remove_action('rest_api_init', 'wp_oembed_register_route');
remove_action('wp_head', 'wp_oembed_add_discovery_links');
remove_action('wp_head', 'wp_oembed_add_host_js');
Minifier et concaténer le JS
Je ne sais pas exactement si minifier et concaténer les fichiers JS peut aider à accélérer leur traitement par le thread. Théoriquement, ça réduit la taille des fichiers, mais ça ne change pas la complexité du code à exécuter, donc l’impact CPU est… disons, discutable.
Ce que je sais, c’est que souvent, ça casse des choses sur le site, donc allez-y avec prudence si vous essayez de le faire sur votre site. Surtout s’il s’agit d’un script e-commerce ! Un checkout qui plante à cause d’une minification foireuse, c’est la pire idée niveau conversion.
Pour vérifier si quelque chose est cassé après minification et / ou concaténation du JS, visitez les principaux types de page de votre site (article, page, produit, catégorie etc), ouvrez l’inspecteur du navigateur et regardez les erreurs dans la console. C’est un réflexe de dev front à garder.
S’il n’y a pas d’erreur nulle part, alors super ! S’il y a des erreurs, désactivez la concaténation et la minification un par un et voyez si l’un des deux cause le problème. Et si vraiment ça continue de bugger, laissez tomber : mieux vaut un JS un peu plus lourd qu’un site inutilisable.
Différer le chargement des scripts
Je ne suis pas non plus sûr que le fait de différer / reporter le chargement de certains scripts aide à réduire le travail du thread principal. En effet, le fait de changer l’ordre de chargement des scripts ne change rien au fait qu’ils devront tous être traités, à un moment ou à un autre.
Mais je sais pour sûr que ce report va économiser des ressources, et faire que les tâches urgentes soient traitées en priorité. Autrement dit : votre above the fold devient plus rapide, la page semble plus réactive, et vos métriques comme le First Input Delay (ou son remplaçant INP) respirent un peu mieux.
J’ai écrit un article détaillé là-dessus : réduire les ressources JS inutilisées. Si vous aimez bidouiller, vous devriez y trouver de quoi vous amuser un moment.
Besoin d’aide ?
Si vous préférez déléguer la prise de tête qu’est l’optimisation des performances, je peux vous aider à améliorer vos Core Web Vitals : franchement, ça évite de passer vos soirées dans l’onglet Network de Chrome DevTools.
Service d’optimisation des performances
