Retarder le JavaScript jusqu’au premier clic

Parmi les optimisations les plus répandues de ces dernières années, il en est une qui promet des résultats spectaculaires avec un seul interrupteur : retarder l’exécution du JavaScript jusqu’à la première interaction de l’utilisateur. Presque tous les plugins de performance pour WordPress la proposent, sous des noms différents, et son effet sur les scores de laboratoire est immédiat : le Total Blocking Time s’effondre, le score Lighthouse monte, le cercle passe au vert.

Le problème, c’est que le JavaScript retardé ne cesse pas d’exister. Le travail qui n’a pas lieu pendant le chargement aura lieu plus tard, et le moment choisi pour l’exécuter est le pire possible : l’instant où l’utilisateur vient de toucher l’écran et attend une réponse. Dans cet article, nous voyons comment fonctionne la technique, pourquoi elle améliore les tests, ce qu’elle casse et quand il est vraiment pertinent de l’utiliser.

Comment fonctionne le delay jusqu’au premier clic

Le principe est simple. Pendant la génération de la page, le plugin réécrit les balises script pour que le navigateur ne les reconnaisse pas comme du code à exécuter : le type devient une valeur inventée et l’adresse du fichier passe de l’attribut src à un attribut de remplacement. Un petit loader, le seul script exécuté immédiatement, écoute des événements comme le mouvement de la souris, le toucher, le défilement ou la frappe d’une touche. À la première interaction, il rétablit les balises d’origine et les exécute, l’une après l’autre, dans l’ordre où elles apparaissaient dans la page.

<!-- comme le thème l’écrit -->
<script src="/wp-content/plugins/slider/slider.js"></script>

<!-- comme le plugin d’optimisation le sert -->
<script type="delayed/javascript" data-src="/wp-content/plugins/slider/slider.js"></script>

Certaines implémentations intègrent un minuteur de sécurité qui charge malgré tout les scripts au bout de quelques secondes, d’autres non : sans interaction, le JavaScript retardé n’est jamais exécuté. C’est un détail qui change beaucoup le comportement du site, et qu’il vaut toujours la peine de vérifier dans votre propre configuration.

Pourquoi les scores s’améliorent autant

Lighthouse charge la page et l’observe, mais ne l’utilise pas : il ne bouge pas la souris, ne fait pas défiler, ne touche ni les menus ni les boutons. Avec le delay activé, pendant toute la durée du test, le JavaScript retardé n’est donc ni téléchargé ni exécuté. Le thread principal reste libre, le Total Blocking Time tombe à des valeurs proches de zéro et, si certains scripts gênaient le rendu, le FCP et le LCP s’améliorent aussi.

Le test mesure correctement ce qu’il voit. Mais ce qu’il voit, c’est une page dans laquelle une partie du code n’est jamais entrée en jeu. C’est un résultat vrai pour le laboratoire et trompeur pour l’entreprise, car aucun utilisateur réel ne se contente de regarder une page sans la toucher.

Le travail ne disparaît pas : il se déplace vers l’INP

Depuis 2024, la réactivité d’une page est mesurée par l’INP (Interaction to Next Paint), qui détecte le temps écoulé entre une interaction de l’utilisateur et la mise à jour suivante de l’écran, et retient la valeur de l’une des pires interactions de la visite. C’est exactement la métrique sur laquelle le delay jusqu’au premier clic reporte son coût.

Quand l’utilisateur touche la page pour la première fois, le navigateur doit tout faire d’un coup : télécharger les scripts retardés, les analyser, les compiler et les exécuter en séquence, en initialisant souvent sliders, widgets, tracking et bibliothèques dans un seul bloc de travail. Sur un ordinateur récent, cela peut représenter quelques centaines de millisecondes ; sur un smartphone milieu de gamme, avec une connexion mobile, une seconde ou plus. Pendant ce temps, la page ne répond pas : le menu ne s’ouvre pas, le bouton ne réagit pas, le texte saisi n’apparaît pas.

Le résultat, sur les données d’utilisateurs réels, est un INP dégradé précisément sur les pages qui paraissent parfaites en laboratoire. Et comme l’INP est l’un des trois Core Web Vitals que Google évalue sur les données du Chrome UX Report, l’amélioration du score de laboratoire peut coexister avec une dégradation de l’évaluation qui compte vraiment.

Ce qui casse

Outre la réactivité, le delay généralisé a des effets secondaires fonctionnels qui n’apparaissent qu’à l’usage réel :

• Le premier toucher est perdu. Si le menu mobile, un filtre ou un bouton « ajouter au panier » dépend d’un script retardé, la première interaction ne sert qu’à le charger. L’utilisateur touche, rien ne se passe, il touche à nouveau. Certains loaders essaient de rejouer le clic, mais n’y parviennent pas toujours.
• Des composants qui changent d’aspect. Sliders, carrousels, onglets et accordéons apparaissent dans leur forme « sans JavaScript » et se transforment au premier mouvement de la souris, avec des sauts de mise en page qui dégradent le CLS.
• Un consentement aux cookies tardif. Si le bandeau de consentement fait partie des scripts retardés, il n’apparaît qu’après la première interaction, avec des problèmes évidents pour l’expérience comme pour la conformité.
• Des fonctionnalités qui dépendent de l’ordre. Des scripts inline qui attendent qu’une bibliothèque soit déjà chargée, du code lié à l’événement DOMContentLoaded qui est entre-temps déjà passé, des intégrations qui s’initialisent deux fois : ce sont les bugs les plus difficiles à reproduire, car ils dépendent de la manière et du moment où l’utilisateur interagit.

L’effet caché sur les données marketing

Il y a aussi une conséquence que l’on considère rarement en activant le delay : les outils d’analytics et les pixels publicitaires sont des scripts comme les autres. S’ils sont retardés, une visite sans interaction n’est pas enregistrée du tout. Qui arrive d’une campagne, lit le haut de la page et repart sans rien toucher n’existe tout simplement pas dans les rapports.

Les conséquences se propagent en chaîne. Le taux de rebond paraît meilleur que le réel, car les rebonds les plus rapides disparaissent. Les taux de conversion ressortent gonflés, car le dénominateur diminue. Les plateformes publicitaires reçoivent moins de signaux et optimisent les campagnes sur des données partielles. Une optimisation née pour améliorer un score finit par altérer les métriques sur lesquelles se prennent les décisions budgétaires.

Quand le delay est pertinent

Le delay n’est pas une technique à diaboliser, mais à utiliser de façon sélective. Il fonctionne bien pour le code qui n’est pas nécessaire à la première interaction et que l’utilisateur peut attendre sans gêne :

• les chats de support et les widgets de messagerie ;
• les outils d’enregistrement de sessions et de heatmaps ;
• les widgets sociaux, les avis intégrés et les contenus tiers sous la ligne de flottaison ;
• les vidéos et les cartes intégrées, idéalement remplacées par un aperçu statique qui ne charge le lecteur qu’au clic.

Tout ce qui concerne la navigation, le consentement, la mesure de base et les principales fonctions commerciales doit en revanche être exclu. En pratique, cela revient à inverser l’approche par défaut de nombreux plugins : non pas « je retarde tout sauf les exceptions », mais « je ne retarde que ce que j’ai vérifié être superflu au premier contact ».

Les alternatives qui réduisent vraiment le travail

Le moyen le plus efficace de ne pas payer le coût du JavaScript, c’est de ne pas avoir à l’exécuter. Avant de retarder, il vaut la peine de se demander quelle quantité de code est vraiment nécessaire, et où :

1. Supprimer. Plugins inutilisés, bibliothèques en double, fonctionnalités activées « au cas où » et jamais utilisées : c’est le gain le plus important et le plus stable.
2. Charger seulement là où c’est nécessaire. Le script du configurateur de produits ne doit pas être présent sur les articles du blog, le script du formulaire de contact ne doit pas apparaître sur les fiches produit.
3. Utiliser defer et async correctement. Les scripts avec defer ne bloquent pas le rendu et s’exécutent dans l’ordre une fois le document prêt, sans attendre une interaction qui ne viendra peut-être jamais.
4. Charger selon la visibilité. Avec IntersectionObserver, un composant situé sous la ligne de flottaison peut s’initialiser quand il est sur le point d’entrer à l’écran, et non au premier mouvement de la souris.
5. Fractionner les tâches longues. Le travail inévitable peut être découpé en morceaux plus petits, en rendant périodiquement la main au navigateur, pour que les interactions de l’utilisateur ne restent pas en file d’attente.

Comment mesurer l’effet réel

Comme le coût du delay n’apparaît que lorsque quelqu’un utilise la page, il faut le mesurer sur des utilisateurs réels ou en simulant une interaction. En laboratoire, le panneau Performance de Chrome DevTools, avec le CPU ralenti quatre fois, permet d’enregistrer le premier toucher sur un bouton et d’observer la durée du bloc de travail qui suit.

Sur le terrain, la bibliothèque open source web-vitals, dans sa version attribution, indique quelle interaction a produit le pire INP, sur quel élément et combien de temps a été passé à attendre, à traiter et dans l’affichage qui suit :

import { onINP } from 'web-vitals/attribution';

onINP( ( { value, attribution } ) => {
	console.log( 'INP', Math.round( value ), 'ms', {
		element: attribution.interactionTarget,
		inputDelay: attribution.inputDelay,
		processing: attribution.processingDuration,
		presentation: attribution.presentationDelay,
	} );
} );

Si le premier clic montre un temps d’attente très long et que l’élément concerné est toujours le premier que l’utilisateur a touché, le coupable est presque certainement le chargement en bloc des scripts retardés. La comparaison définitive vient alors des données CrUX : l’INP au 75e percentile, avant et après l’activation du delay, sur deux fenêtres complètes de 28 jours.

En résumé

Retarder le JavaScript jusqu’au premier clic améliore fortement les scores de laboratoire parce que le test n’interagit pas avec la page. Pour les utilisateurs réels, en revanche, le travail différé se concentre au moment du premier toucher, dégrade l’INP, peut rendre inopérants menus et boutons, faire apparaître tardivement le consentement aux cookies et retirer des rapports les visites les plus courtes.

Utilisé avec discernement, sur des scripts tiers non essentiels et avec des exclusions bien définies, cela reste un outil utile. Mais cela ne remplace pas le travail qui produit des résultats durables : supprimer le code superflu, ne le charger que là où il est nécessaire et s’assurer que le code indispensable ne bloque pas le thread principal. Repousser le travail ne veut pas dire l’éliminer, et au bout du compte quelqu’un le paie : l’utilisateur.