Date de publication : 14 octobre 2025
L'Interaction to Next Paint (INP) est une métrique Core Web Vitals essentielle pour mesurer la réactivité. Chez Fotocasa, la Google Search Console a mis en évidence un nombre important de pages qui sont passées à "Nécessite des améliorations" et "Mauvais" lorsque l'INP a remplacé le First Input Delay (FID) en 2024. Cette étude de cas décrit les outils et les stratégies utilisés pour diagnostiquer et résoudre ces problèmes, ce qui a permis d'améliorer considérablement l'INP.
Point de départ de l'équipe Fotocasa
Avant le passage du FID à l'INP, presque toutes les pages sur ordinateur et sur mobile se trouvaient dans la catégorie "Bon", ce qui signifie que tous les Core Web Vitals de l'époque (LCP, CLS et FID) étaient performants. Toutefois, après le passage à l'INP, presque toutes les pages sont passées à "Nécessite des améliorations", et certaines même à "Mauvais", car les valeurs INP dépassaient systématiquement 200 millisecondes pour la plupart des interactions utilisateur.
Ce changement a permis à l'équipe Fotocasa de se rendre compte qu'elle négligeait un aspect crucial de l'expérience utilisateur. Alors que le FID ne mesurait que le délai de la toute première interaction, l'INP évalue la réactivité de toutes les interactions, en tenant compte des délais de traitement et de présentation des entrées. Cette mesure plus large est un bien meilleur indicateur de l'interactivité réelle (comme l'a indiqué Google) et a mis en évidence les opportunités manquées.
Bien que la Google Search Console fournisse des données sur les performances sur le terrain, elle ne fournit pas d'insights en temps réel. Ses données sont agrégées sur une période de 28 jours, ce qui rend difficile d'identifier précisément les interactions qui posaient problème à un moment donné.
Il fallait un moyen de suivre l'INP en temps réel afin d'identifier les interactions les plus lentes et les plus fréquemment utilisées par les utilisateurs, et de les reproduire de manière fiable dans les environnements de développement de l'équipe. Il était tout aussi important de comprendre l'impact des modifications apportées, et pas seulement de savoir quelles corrections avaient aidé, mais aussi quels ajustements avaient involontairement empiré la situation.
Pour ces raisons, un ensemble d'outils a été utilisé pour diagnostiquer et résoudre les problèmes. Voici les plus importants :
- Les outils pour les développeurs Google Chrome, plus précisément l'onglet "Performances".
- Système RUM (Real User Monitoring) personnalisé créé par l'équipe Fotocasa dans Datadog à l'aide de la bibliothèque web-vitals.
- Outils de développement React.
Outils pour diagnostiquer le problème
Les outils suivants ont été utilisés pour diagnostiquer et déboguer les problèmes de performances INP.
Outils pour les développeurs Google Chrome
Pour détecter et reproduire les problèmes liés aux Core Web Vitals dans une application Web, le meilleur moyen est d'utiliser l'onglet "Performances" des outils pour les développeurs Google Chrome. L'onglet "Performances" mesure automatiquement les métriques Core Web Vitals, ce qui vous permet d'obtenir un retour instantané sur les métriques de chargement, d'interactivité et de décalage de mise en page. Elle est globalement cohérente avec la façon dont ces métriques sont communiquées aux autres outils Google.
Pour identifier et résoudre les problèmes d'INP, l'équipe Fotocasa a commencé par limiter la fréquence du processeur afin de simuler les performances des appareils bas et milieu de gamme. L'équipe Fotocasa a ainsi pu observer le comportement de la page dans des conditions plus contraignantes. La session a ensuite été enregistrée à l'aide du profileur, et les traces ont été analysées avec soin, en se concentrant sur l'interaction utilisateur pour identifier les problèmes de performances.
Lorsque vous identifiez des goulots d'étranglement, il est particulièrement utile d'examiner les sous-parties de l'INP et les tâches que le navigateur effectue dans chacune d'elles. Par exemple, dans l'image suivante, on peut voir que l'INP est assez élevé en raison de deux recalculs de style causés par des modifications de style dans le corps du document.
Fotocasa a mis en place un système pour suivre l'INP et les autres métriques des Core Web Vitals, ce qui permet d'identifier et de résoudre rapidement les problèmes de performances. Lorsqu'une métrique dépasse un seuil spécifique (en fonction des plages définies par Google), l'attribution est enregistrée afin que le problème puisse être analysé et résolu.
Pour ce système, la bibliothèque web-vitals a été utilisée pour capturer ces métriques auprès de vrais utilisateurs de manière à correspondre précisément à la façon dont elles sont mesurées par Chrome et communiquées à d'autres outils Google (comme le rapport sur l'expérience utilisateur Chrome, PageSpeed Insights, le rapport sur la vitesse de la Search Console, etc.).
Pour obtenir une vue complète et un suivi centralisé, Fotocasa a utilisé Datadog pour collecter et visualiser les données, ce qui a permis à l'équipe de prendre des décisions éclairées basées sur les données. Les métriques personnalisées permettent de réduire les coûts et de mieux suivre presque tous les utilisateurs sur le site Web Fotocasa.
Ce système permet à l'équipe Fotocase de surveiller rapidement si ses modifications affectent les métriques ou si des altérations imprévues se produisent, ce qui pourrait les compromettre. La métrique INP peut ensuite être décomposée en plusieurs parties (délai d'entrée, durée de traitement et délai de présentation, par exemple) pour identifier précisément la partie de l'interaction qui est principalement responsable des longs temps d'interaction.
Après avoir détecté des anomalies, comme celles illustrées dans les figures 7 et 8, Fotocasa a réagi rapidement et utilisé OpenSearch, un autre outil qui a permis d'identifier l'emplacement de l'altération. Les données fournies par la bibliothèque web-vitals ont permis d'identifier la cible (l'élément DOM potentiellement responsable d'une valeur métrique élevée) et ont aidé l'équipe à se concentrer davantage sur la résolution du problème.
De plus, vous pouvez définir différents filtres (type de page, appareil ou état de chargement, par exemple) pour simplifier les scénarios et mieux comprendre l'impact de l'INP.
Outils pour les développeurs React
Les outils de développement React ont été utilisés pour améliorer les capacités de débogage de Fotocasa. Ils offrent une fonctionnalité puissante qui vous permet de mettre en évidence visuellement les composants qui ont été rendus à nouveau.
Pour activer cette fonctionnalité, accédez à l'onglet Profiler. Cliquez ensuite sur l'icône en forme de roue dentée à droite de la barre supérieure, accédez à l'onglet Général, puis cochez la case Mettre en surbrillance les mises à jour lors du rendu des composants. Lorsque cette option est activée, les composants sont mis en surbrillance lorsqu'ils sont réaffichés, ce qui fournit une représentation visuelle dynamique.
Déterminer la cause d'un nouveau rendu
Une fois qu'un composant qui a été réaffiché a été identifié, la question suivante est "pourquoi cela s'est-il produit ?". React DevTools répond à cette question avec une info-bulle utile dans la vue du graphique en flammes.
Pour accéder à ces informations, enregistrez une session de profilage. L'analyse de la sortie du profileur vous permet d'obtenir des informations utiles :
- En haut à droite, le nombre de commits React s'affiche.
- Le graphique en flammes représente visuellement l'arborescence des composants, le gris indiquant les composants qui n'ont pas été réaffichés. Chaque barre représente un moment où l'arborescence des composants React a changé et où une modification correspondante a été appliquée au DOM.
- En pointant sur chaque composant du graphique en flammes, vous verrez la raison de son rendu sous le sous-titre Pourquoi ce rendu ?.
Voici quelques raisons pour lesquelles un composant peut être rendu à nouveau :
- C'est la première fois que le composant a été rendu.
- Le contexte a changé
- Crochets modifiés
- Accessoires modifiés
- La valeur État a été modifiée
- Composant parent affiché
Déterminer le temps de rendu
Les couleurs du graphique en flammes transmettent des informations importantes. Les couleurs telles que les différentes nuances de bleu indiquent qu'un composant a nécessité un temps de rendu relativement court par rapport aux autres composants. À l'inverse, les couleurs orange et rouge indiquent qu'un composant a nécessité plus de temps de rendu.
Comment l'équipe Fotocasa a résolu le problème
Supprimer les rendus inutiles
Les rendus se produisent chaque fois que React doit mettre à jour l'UI avec de nouvelles données. Cela provient généralement d'une action de l'utilisateur, d'une réponse de l'API ou d'autres événements importants qui nécessitent une mise à jour de l'interface utilisateur. Étant donné que chaque rendu exécute JavaScript, un trop grand nombre de rendus à la fois, en particulier dans un grand arbre de composants, peut bloquer le thread principal et entraîner des problèmes de performances.
Il existe deux types de réaffichage :
- Rendus nécessaires : lorsqu'un composant doit réellement être mis à jour, car il possède ou utilise des données récentes.
- Rendus inutiles : lorsqu'un composant est mis à jour sans changement significatif, souvent en raison d'une gestion d'état inefficace ou d'une gestion incorrecte des propriétés.
Quelques rendus inutiles ne sont généralement pas un problème, car React est suffisamment rapide pour que les utilisateurs ne s'en rendent pas compte. Toutefois, si elles se produisent trop souvent ou dans un arbre de composants volumineux, elles peuvent nuire à l'expérience utilisateur et avoir un impact négatif sur l'INP de la page.
C'est ce qui s'est passé pour l'équipe Fotocasa. Ils ont réalisé que le site Web effectuait de nombreux rendus inutiles. Ces erreurs se sont produites dans deux scénarios principaux :
- Pendant le chargement de la page : augmentation du nombre de tâches longues sur le thread principal et retard de la première interaction, ce qui a eu un impact négatif sur l'INP de la page.
- Lors des interactions utilisateur : le temps de traitement de la plupart des interactions a été augmenté, ce qui a également nui à l'INP.
De nombreux rendus inutiles ont été optimisés sur le site Web de Fotocasa. L'une des optimisations les plus importantes a été réalisée sur la page de recherche. Trois rendus inutiles ont été effectués lors du chargement de la page. Une fois ces éléments supprimés, les résultats suivants ont été observés :
- Moins de tâches longues (voir l'illustration ci-dessous)
- Temps de blocage total plus court (comparez les figures 14 et 15)
Colocation d'état
Un placement incorrect de l'état React peut ralentir une application et rendre l'UI peu réactive. Lorsqu'un état de composant change, ses composants enfants sont rendus à nouveau par défaut, sauf si un mécanisme d'échappement est utilisé (par exemple, memo).
Comme expliqué dans la section précédente, les réaffichages ne sont pas intrinsèquement mauvais, mais le réaffichage de l'intégralité de la page en raison d'une mise à jour d'état spécifique peut entraîner des interactions plus lentes, car les mises à jour du DOM se produisent après le rendu.
Par exemple, sur la page de recherche, une boîte de dialogue affiche tous les filtres lorsqu'un bouton est cliqué.
Dans ce cas, l'état qui contrôle l'état ouvert de la boîte de dialogue a été placé sur la page de recherche. Lorsque cet état changeait, toute la page était rendue à nouveau, ce qui entraînait un mauvais INP, en particulier sur les appareils plus lents, comme on peut le voir lorsque la limitation du processeur était utilisée dans les outils de développement :
Pour résoudre ce problème, modifiez l'état le plus près possible du composant qui déclenche la modification. Dans ce cas précis, l'état peut être placé dans le composant de bouton des filtres. Ainsi, lorsque l'état change, seul le bouton est réaffiché.
Supprimer les états inutiles
Les états ne doivent pas contenir d'informations redondantes ou en double. Sinon, cela pourrait entraîner des rendus inutiles et des problèmes.
Par exemple, dans la barre de filtres Fotocasa, un texte indique le nombre de filtres appliqués à une recherche donnée :
Le nombre de filtres appliqués est calculé à partir de l'état de l'application. Toutefois, cela a non seulement entraîné un rendu inutile de l'ensemble du composant, mais a également entraîné un décalage de la mise en page dans certains cas, car ce composant est rendu côté serveur :
const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)
useEffect(() => {
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER
setFiltersCount(counter)
}, [searchParams]);
Pour résoudre ce problème, la valeur a été dérivée de l'objet de filtres à l'aide d'une variable au lieu d'un état :
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER;
Réduire les rendus coûteux
Lorsqu'une interaction se produit dans une application React, elle déclenche normalement un changement d'état. Comme expliqué précédemment, lorsque l'état d'un composant change, le composant est rendu à nouveau avec tous ses enfants.
Si l'une de ces fonctions de rendu de composants est lente, cela aura un impact négatif sur l'INP de la page, car une tâche longue sera probablement générée et la mise à jour du DOM prendra plus de temps.
L'équipe Fotocasa a essayé de minimiser autant que possible les calculs chronophages dans la fonction de rendu des composants. Les outils pour les développeurs Chrome et React ont été très utiles pour détecter les opérations de rendu lentes.
Retarder l'exécution du code
En plus d'optimiser la fonction de rendu des composants, d'autres fonctions ont été optimisées pour minimiser autant que possible les tâches longues. Toutefois, certaines tâches n'ont pas pu être optimisées, car elles dépendaient d'un code tiers.
L'analyse en est un exemple. Dans ce cas, il a été décidé de retarder l'exécution du code Analytics et de donner la priorité aux mises à jour du DOM lorsque des interactions utilisateur se produisaient. Pour ce faire, l'équipe Fotocasa a utilisé une bibliothèque appelée idlefy, qui garantissait également que le code d'analyse s'exécuterait même si le navigateur était fermé immédiatement après.
Culture de la performance
L'optimisation des performances n'est pas une tâche ponctuelle. Elle doit être prise en compte pour chaque fonctionnalité déployée en production. Tous les membres de l'équipe doivent être sur la même longueur d'onde, sinon des régressions dans les Core Web Vitals sont presque inévitables.
Pour y remédier, l'équipe Fotocasa a activement partagé ses connaissances en interne et établi un cadre clair pour identifier les problèmes de performances en fonction des données RUM de Datadog, y compris la façon de les reproduire. Des alertes pour les métriques Core Web Vitals, en particulier l'INP, ont été configurées dans le système RUM pour avertir directement l'équipe Fotocasa dans Slack. Cette approche a permis de garder les performances à l'esprit et d'identifier les problèmes avant qu'ils ne se transforment en régressions.
Résultats
Pour améliorer l'INP sur Fotocasa, il a fallu combiner des optimisations techniques et des changements culturels. En éliminant les rendus inutiles, en optimisant l'emplacement des états, en réduisant les rendus coûteux et en différant le code non critique, l'équipe Fotocasa a réussi à faire passer toutes les pages pour ordinateur de bureau de la catégorie "À améliorer" à la catégorie "Bon". Elle a également amélioré de manière significative les pages pour mobile en faisant passer presque toutes les pages "Mauvais" et "À améliorer" à la catégorie "Bon".
Ces modifications ont amélioré l'expérience utilisateur globale de Fotocasa et, associées à d'autres initiatives, ont entraîné une augmentation de 27 % des annonces axées sur les contacts et les prospects téléphoniques, ce qui a directement renforcé les métriques métier clés de l'entreprise.
La surveillance en temps réel avec Datadog a permis à l'équipe Fotocasa de valider les améliorations de l'INP, de détecter rapidement les anomalies et d'éviter les régressions. Au-delà de ces réussites, Fotocasa a également réussi à intégrer les performances Web dans sa culture de développement, en veillant à ce que l'INP et les Core Web Vitals restent une priorité dans chaque version.