QuintoAndar booste ses taux de conversion et son nombre de pages par session en améliorant les performances de ses pages

Un projet axé sur l'optimisation des métriques Core Web Vitals et la migration vers Next.js a permis d'augmenter les taux de conversion de 5% et le nombre de pages vues par session de 87 %.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar est une entreprise brésilienne de proptech dont les produits proposent des solutions numériques de bout en bout pour l'immobilier. Cette année, nous avons mené un projet visant à améliorer les performances d'un hub de contenu dans notre application. Nous avons obtenu des résultats encourageants en termes d'augmentation du trafic utilisateur et des métriques de conversion.

46 %

de réduction du taux de rebond

87 %

augmentation du nombre de pages par session

5 %

amélioration des conversions pendant la phase de validation ;

Défis

Notre application propose un hub de contenus sur les condominiums de plus de 40 000 pages, où les utilisateurs peuvent obtenir des informations sur leurs propriétés, consulter des photos des parties communes, en savoir plus sur le quartier et trouver des annonces de location ou de vente disponibles. Ces pages sont très importantes pour QuintoAndar:

  • Elles constituent une source importante de trafic généré par les résultats naturels, avec un nombre croissant d'utilisateurs provenant des résultats de recherche.
  • Elles enregistrent des taux de conversion élevés à moyen et long terme par rapport aux autres pages.

Cependant, les performances et l'expérience utilisateur de ces pages présentaient des difficultés:

  • Leurs performances, mesurées par les Core Web Vitals, n'étaient pas optimisées, et des problèmes connus existaient concernant le chargement lent des pages, la lenteur de la réponse aux entrées utilisateur et l'instabilité de la mise en page.
  • Leurs taux de rebond étaient élevés, même si nous nous attendions à ce qu'ils soient plus élevés que dans d'autres parties de l'application.
  • La mise à jour de l'expérience sur la page dans la recherche Google (qui n'était pas encore disponible à ce moment-là) inclurait les métriques Core Web Vitals dans l'algorithme de classement, ce qui signifie que les performances des pages pourraient avoir un impact sur l'affichage des résultats de recherche.

En parallèle, nous avons identifié des opportunités d'amélioration de l'expérience des développeurs qui pourraient générer des gains dans d'autres projets de l'entreprise:

  • Notre logique de rendu côté serveur, qui génère toutes les pages à fort trafic, y compris les pages de condominiums, a été créée en interne et est devenue trop complexe à gérer et à intégrer pour les nouveaux employés.
  • Les fonctionnalités essentielles pour obtenir de bonnes performances d'application, telles que le fractionnement du code, nécessitaient également une configuration personnalisée et un travail manuel de la part des développeurs.
  • QuintoAndar compte plus de 30 applications Web React. Il est difficile de mettre à jour ces applications et de les gérer conformément aux bonnes pratiques.

Approche

Nous avons lancé un projet d'optimisation des performances du hub de contenus sur les condominiums afin d'améliorer l'expérience utilisateur. Ces améliorations pourraient générer des conversions, améliorer le référencement naturel et l'usabilité. Cette initiative a également été l'occasion d'améliorer l'expérience des développeurs.

Migrer vers Next.js

La nouvelle version de la page du condominium a été implémentée avec Next.js. Étant largement indépendant des autres parties de l'application, le hub de contenu du condominium semblait être un bon candidat pour tester un nouveau framework. Nous pourrions ainsi comprendre l'ampleur des efforts de migration et évaluer comment ses fonctionnalités pourraient nous aider sans affecter les autres applications React de QuintoAndar.

Une exigence stricte consistait à s'assurer que les pages restaient accessibles aux moteurs de recherche. Next.js répond à cette exigence en prenant en charge le rendu côté serveur prêt à l'emploi et en éliminant le besoin d'une configuration personnalisée. La documentation permet de partager plus facilement des connaissances sur des tâches telles que l'extraction de données sur le serveur et l'intégration de nouveaux développeurs. Le rendu côté serveur est également connu pour améliorer les métriques de performances telles que First Contentful Paint (FCP).

Le framework fournit d'autres fonctionnalités favorables aux performances, telles que le fractionnement automatique du code et le préchargement. Même si la structure existante proposait déjà de telles fonctionnalités, le travail supplémentaire requis des développeurs a freiné leur adoption. Par exemple, le fractionnement du code au niveau de la page ou du composant devait être effectué manuellement.

Optimiser les ressources JavaScript

La première étape a consisté à supprimer le code inutilisé. Nous avons examiné les rapports Webpack Bundle Analyzer, qui affichent le contenu de chaque bundle JS, et examiné attentivement tous les scripts tiers. Nous avons ainsi pu nettoyer certaines bibliothèques de suivi qui n'étaient pas utilisées sur cette page spécifique.

Notre équipe est allée plus loin et a évalué le coût des performances des fonctionnalités existantes. Par exemple, le bouton "J'aime" nécessitait beaucoup de code JavaScript pour fonctionner. Toutefois, sur la page des condominiums, moins de 0,5% des utilisateurs ont interagi avec le bouton, qui est disponible et utilisé plus fréquemment dans d'autres parties de notre application. Après une discussion entre les équipes Engineering et Product, nous avons décidé de supprimer cette fonctionnalité.

Une animation montrant la fonctionnalité du bouton "J'aime". Une fiche présente un appartement à louer. En bas à droite de la fiche, un bouton en forme de cœur gris devient bleu lorsque vous cliquez dessus.

D'autres optimisations JavaScript étaient déjà en place, comme la compression statique avec Brotli, qui était effectuée au moment de la compilation à l'aide de BrotliWebpackPlugin et qui était également appliquée à d'autres types de ressources statiques. Au début, nous nous appuyions sur la compression fournie par le CDN. Brotli a réduit la taille du code JavaScript de 18% par rapport à gzip. Nous avons ensuite passé à la compression Brotli au moment de la compilation et avons pu réduire la taille de 24 %.

Optimiser les ressources d'image

Dans la version mobile, une image hero occupe la majeure partie de la zone au-dessus de la ligne de flottaison. Il s'agit également du Largest Contentful Paint (LCP) de la page.

Page du condominium Edifício Copan (São Paulo, Brésil). Une photo prise au niveau du sol montre les courbes de la structure du bâtiment.
Hero image d'une page de condominium.

Auparavant, toutes les images disposaient déjà des attributs srcset et sizes pour diffuser des images responsives. Nous avons également utilisé Thumbor pour redimensionner les images à la demande et configuré notre CDN pour les mettre en cache efficacement.

Les appareils mobiles modernes sont dotés d'écrans à très haute densité de pixels. Par conséquent, le navigateur affiche des versions 3 x ou 4 x de l'image, le cas échéant. À mesure que la résolution augmente, il devient plus difficile pour l'œil humain de percevoir les différences, mais la taille des fichiers augmente quoi qu'il en soit. Limiter la résolution d'image maximale a amélioré la taille des images sans compromettre l'expérience utilisateur. Nous avons limité l'image hero à la version 2x au maximum, qui est environ 35% plus petite que la version 3x et 50% plus petite que la version 4x.

Pour finir, nous avons utilisé une stratégie de préchargement pour télécharger et afficher l'image dès que possible, dans l'espoir d'améliorer la métrique LCP.

<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">

Le composant d'image intégré Next.js inclut de nombreuses optimisations, telles que le redimensionnement responsif et le chargement prioritaire. Au cours de ce projet, nous n'avons pas migré les images existantes pour utiliser ce composant, mais nous prévoyons de l'adopter dans de nouvelles fonctionnalités.

Réduire le décalage de mise en page

La page du condominium présentait quelques problèmes de décalage de mise en page cumulatif (CLS). Les éléments responsables des décalages de mise en page n'étaient affichés que dans le client (par exemple, l'hydratation du balisage côté serveur avec des composants affichés côté client ou des images sans attributs width et height définis).

Pour résoudre ces problèmes, nous définissons des dimensions exactes pour ces éléments lorsque cela est possible, ou des valeurs estimées avec min-height. Il existe d'autres options, comme l'utilisation de la propriété CSS aspect-ratio. Nous avons également créé des espaces réservés pour éviter que les composants affichés de manière dynamique ne provoquent des décalages de mise en page.

Image montrant une zone urbaine dans Google Maps avec un repère rouge au centre.
La définition de dimensions pour des éléments tels que l'image de la carte a réduit le CLS.

Déploiement progressif des modifications

Notre équipe voulait vérifier que la version optimisée de la page du hub de condominiums améliorerait l'expérience utilisateur. Pour ce faire, nous avons adopté une stratégie de déploiement progressive:

  1. Lors de la première phase, la nouvelle version a été publiée pour quelques URL sélectionnées manuellement. Ainsi, seuls quelques centaines d'utilisateurs par jour pouvaient la voir.
  2. Lors de la deuxième phase, il a été publié sur davantage de pages, ce qui représente quelques milliers d'utilisateurs par jour.
  3. Lors de la troisième et dernière phase, il a été publié pour toutes les pages et le déploiement a été finalisé pour tous les utilisateurs.

Pendant cette période, l'équipe d'ingénieurs a mesuré en permanence les performances des pages en production et a continué à travailler sur des améliorations. L'équipe a également comparé les métriques commerciales entre la nouvelle version et la précédente. Les résultats de cette période de validation étaient prometteurs.

Résultats

L'équipe a utilisé SpeedCurve pour exécuter en continu des tests en laboratoire sur la page du condominium. Voici les résultats pour la version mobile:

Métrique de l'atelier Avant Après Différence
Largest Contentful Paint (LCP) 2,41 secondes 1,48 secondes -39%
Délai avant interactivité (TTI) 12,16 secondes 7,48 secondes -39%
Total Blocking Time (TBT) 1 124 millisecondes 1 056 millisecondes -4%
Cumulative Layout Shift (CLS) 0,0402 0,0093 -77%
Résultats des métriques de test collectés avec SpeedCurve.

Nous voulions également vérifier l'impact sur nos utilisateurs réels. À l'aide des données sur le terrain collectées avec Instana Website Monitoring, nous avons examiné la période d'un mois avant et après le déploiement. En comparant le 75e centile pour les utilisateurs mobiles, nous avons constaté que le LCP a diminué de 26 % et le FID de 72%.

Graphique linéaire avec des valeurs de LCP comparant les nouvelles et anciennes versions au cours du mois en cours et du mois précédent. La courbe de la nouvelle version oscille entre 2 et 4 secondes, et reste en dessous de celle de la version précédente la plupart du temps.
Graphique linéaire avec des valeurs de FID comparant les nouvelles et anciennes versions au cours du mois en cours et du mois précédent. La courbe de la nouvelle version reste en dessous de 100 ms la plupart du temps, tandis que celle de l&#39;ancienne version présente quelques pics dépassant 250 ms.
Résultats des métriques de champ collectées avec Instana.

PageSpeed Insights fournit un rapport sur les données sur le terrain pour les 28 derniers jours. Seule la page de la copropriété la plus consultée disposait de suffisamment de données pour générer un rapport sur les utilisateurs mobiles. Depuis novembre 2021, toutes les métriques Core Web Vitals sont classées dans la catégorie "Bon".

Capture d&#39;écran du rapport PageSpeed Insights, axée sur la section &quot;Données de champ&quot;. Toutes les métriques Core Web Vitals (FCP, FID, LCP et CLS) se trouvent dans la catégorie &quot;Bon&quot;.
PageSpeed Insights indique que les utilisateurs mobiles bénéficient d'une bonne expérience sur la page de la copropriété la plus consultée.

Lors du déploiement progressif, nous avons constaté une baisse des taux de rebond. Lorsque nous avons terminé la publication sur toutes les pages, Google Analytics a indiqué une diminution de 46% du taux de rebond, une augmentation de 87% du nombre de pages vues par session et une augmentation de 49% de la durée moyenne des sessions. La réduction du taux de rebond a été encore plus importante pour les recherches sponsorisées, atteignant 59 %. C'est un signe positif pour les investissements dans les annonces au coût par clic (CPC).

Capture d&#39;écran d&#39;un graphique Google Analytics. Il compare les taux de rebond entre deux périodes distinctes en mars 2021. À partir du 17 mars, le taux de rebond a légèrement baissé. La baisse est accentuée le 24 mars.
Google Analytics indique que le taux de rebond diminue à mesure que nous déployons la nouvelle version sur davantage de pages.

Pour évaluer l'impact sur les métriques commerciales, nous avons analysé les taux de conversion pour des transactions telles que la planification d'une visite et la demande de location ou d'achat d'un bien immobilier. Pendant le déploiement des améliorations, notre équipe a comparé les conversions entre l'ancienne et la nouvelle version. Au cours de la même semaine, le groupe de pages avec la nouvelle version a enregistré une augmentation de 5% des conversions, tandis que les autres pages ont enregistré une légère baisse de cette métrique.

Deux graphiques linéaires côte à côte, chacun comparant les conversions entre la semaine en cours et la semaine précédente. Celle de gauche correspond à la version précédente de la page. Elle montre que la courbe des conversions pour la semaine en cours est légèrement inférieure à celle de la semaine précédente. La courbe de conversion de la semaine en cours est légèrement supérieure à celle de la semaine précédente.
La même semaine, le nombre de conversions pour la nouvelle version a augmenté, tandis que celui de la version précédente a légèrement diminué.

Conclusion

Ce projet est la première partie d'un effort de migration à long terme de React sans framework vers Next.js. Les équipes qui ont travaillé sur la page des immeubles de logements collectifs depuis ont donné un avis positif sur l'amélioration de l'expérience pour les développeurs. D'autres équipes qui ont dû démarrer de nouvelles applications Web l'ont déjà fait avec Next.js. Nous pensons que Next.js simplifiera les efforts de maintenance et établira un terrain d'entente entre les différentes applications.

Globalement, le hub de contenus sur les copropriétés a connu une croissance continue en termes de nombre absolu d'utilisateurs et de transactions. Sur le long terme, de nombreux facteurs contribuent à cette évolution, comme l'expansion des activités de QuintoAndar et les initiatives de référencement naturel, comme l'amélioration de l'indexation des pages. Au cours de ce projet, nous avons constaté que les performances des pages sont également l'un de ces facteurs qui ont un fort potentiel d'impact positif sur les conversions.

Un merci tout particulier à Pedro Carmo, responsable produit de l'équipe SEO, pour avoir exploré les données utilisateur et créé toutes les analyses de conversion présentées dans cette étude de cas.