# Billetterie culturelle : un widget de paiement tiers qui dégrade l’INP

> Pourquoi le clic sur le bouton de paiement d'une billetterie culturelle semblait ignoré pendant une fraction de seconde. Diagnostic via les DevTools et correctif par chargement différé du widget.

- Auteur : Clément Hadrot
- Publié le : 2025-10-27
- Mis à jour le : 2025-10-27
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/billetterie-culturelle-widget-paiement-tiers-inp/

## L’essentiel

- Un widget tiers non optimisé peut occuper le thread principal au pire moment
- L'attribution des tâches longues dans les DevTools révèle précisément le script fautif
- Charger le widget seulement au moment utile redonne un INP correct

Pourquoi un clic sur le bouton « Payer » d'une billetterie culturelle donnait-il parfois l'impression d'être resté sans effet pendant un instant, avant que le formulaire ne réagisse enfin ? C'est la question remontée par plusieurs visiteurs d'un théâtre municipal, sans qu'aucune erreur ne soit visible côté technique.

## Symptôme : une interaction perçue comme lente au moment critique

L'interaction en question se situait précisément à l'étape la plus sensible du parcours d'achat : la validation du panier, juste avant la redirection vers le formulaire de paiement. C'est aussi l'étape où l'abandon d'achat coûte le plus cher, ce qui rendait le signalement particulièrement préoccupant malgré son caractère apparemment mineur.

La métrique INP (Interaction to Next Paint), devenue Core Web Vital officiel en mars 2024 en remplacement du FID, dépassait régulièrement les 300 millisecondes sur cette page précise dans les données de terrain remontées par la Search Console, alors que le reste du site affichait des valeurs largement satisfaisantes.

## Diagnostic : l'attribution des tâches longues dans les DevTools

L'onglet Performance des outils de développement Chrome, avec l'enregistrement d'une interaction réelle sur le bouton de paiement, a permis d'identifier précisément la tâche longue responsable : un script fourni par le widget de paiement tiers intégré sur la page, chargé de manière synchrone dès l'affichage initial de la page, quel que soit le moment où le visiteur cliquerait effectivement sur « Payer ».

> L'essentiel à retenir : Un widget tiers non optimisé peut occuper le thread principal au pire moment ; L'attribution des tâches longues dans les DevTools révèle précisément le script fautif ; Charger le widget seulement au moment utile redonne un INP correct

Ce script initialisait à chaque clic une vérification complète de son état interne, une opération coûteuse en temps processeur, occupant le thread principal pendant plus de 300 millisecondes et empêchant le navigateur de peindre la moindre réponse visuelle à l'interaction du visiteur pendant ce laps de temps.

## Correctif : différer le chargement du widget jusqu'au moment utile

Plutôt que de charger le script du widget dès l'affichage de la page, la solution retenue consiste à ne l'initialiser qu'au moment où le visiteur approche réellement de l'étape de paiement, via un observateur d'intersection sur la zone du formulaire :

```
const zonePaiement = document.querySelector('#zone-paiement');
const observateur = new IntersectionObserver((entrees) => {
    entrees.forEach((entree) => {
        if (entree.isIntersecting) {
            const script = document.createElement('script');
            script.src = 'https://widget-paiement.exemple/sdk.js';
            script.defer = true;
            document.body.appendChild(script);
            observateur.disconnect();
        }
    });
});
observateur.observe(zonePaiement);
```

Ce report du chargement n'élimine pas le coût du script, mais le déplace à un moment où le visiteur n'attend pas encore d'interaction immédiate, réduisant d'autant la probabilité qu'une tâche longue coïncide exactement avec le clic sur le bouton de validation.

## Prévention : un budget de script tiers pour les pages critiques

Au-delà du correctif ponctuel, l'équipe a mis en place un principe simple pour les pages sensibles du parcours d'achat :

- Aucun script tiers ne se charge de façon synchrone sur les pages de panier et de paiement
- Chaque nouveau widget intégré fait l'objet d'une mesure d'impact sur l'INP avant sa généralisation
- Un seuil d'alerte est fixé sur la métrique INP de terrain, remontée via la bibliothèque `web-vitals`

> Un widget de paiement doit être prêt quand le visiteur en a besoin, pas en train de s'installer au moment précis où il clique.

## En résumé

Un clic qui semble ignoré n'est presque jamais un bug d'interface : c'est souvent un script qui occupe le thread principal au pire moment possible. Le diagnostic par attribution des tâches longues dans les DevTools reste, à ce jour, l'outil le plus direct pour localiser ce type de problème. Ce billet ne traite pas du choix du prestataire de paiement lui-même, qui répond à d'autres critères que la seule performance perçue.