Un projet axé sur l'optimisation des Core Web Vitals et la migration vers Next.js a entraîné une augmentation de 5% des taux de conversion et de 87% du nombre de pages par session.
QuintoAndar est une entreprise brésilienne de proptech dont les produits offrent des solutions numériques de bout en bout pour l'immobilier. Cette année, nous avons mené un projet axé sur l'amélioration des performances d'un centre 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%
d'augmentation du nombre de pages par session
5%
d'amélioration du nombre de conversions au cours de la phase de validation
Difficultés
Notre application dispose d'un centre de contenu relatif aux copropriétés avec plus de 40 000 pages. Les utilisateurs peuvent y trouver des informations sur leurs biens immobiliers, consulter des photos des espaces communs, en savoir plus sur le quartier et trouver des annonces à louer ou à vendre. Ces pages sont très importantes pour QuintoAndar:
- Ils constituent une source importante de trafic naturel, avec un nombre croissant d'utilisateurs provenant des résultats des moteurs de recherche.
- Elles enregistrent des taux de conversion élevés à moyen et long terme par rapport aux autres pages.
Cependant, ces pages ont rencontré des difficultés en termes de performances et d'expérience utilisateur:
- Les performances mesurées par le rapport Core Web Vitals n'ont pas été optimisées, et des problèmes connus comme la lenteur du chargement des pages, la lenteur de la réponse aux entrées utilisateur et l'instabilité de la mise en page étaient connus.
- 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, à l'époque, n'était pas encore disponible), incluait les Core Web Vitals dans l'algorithme de classement. Les performances des pages pouvaient donc avoir un impact sur l'affichage des résultats de recherche.
Parallèlement, nous avons identifié des opportunités d'expérience développeur qui pourraient profiter d'avantages dans d'autres projets de l'entreprise:
- Notre logique de rendu côté serveur, qui affiche toutes les pages enregistrant un trafic élevé, y compris les pages d'appartements, a été créée en interne. Elle est devenue trop complexe pour gérer et intégrer les nouvelles recrues.
- Les fonctionnalités essentielles permettant d'optimiser les performances des applications, comme la scission du code, nécessitaient également une configuration personnalisée et des interventions manuelles de la part des développeurs.
- QuintoAndar propose plus de 30 applications Web React. La mise à jour de ces applications et leur maintenance dans le respect des bonnes pratiques sont des tâches ardues.
Approche
Nous avons commencé un projet d'optimisation des performances du centre de contenu de copropriétés afin d'améliorer l'expérience utilisateur. En effet, ces améliorations pourraient se traduire par une augmentation des conversions, un meilleur SEO et une meilleure facilité d'utilisation. 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 des copropriétés a été implémentée avec Next.js. En grande partie indépendant des autres parties de l'application, le hub de contenu relatif aux copropriétés semblait idéal pour tester un nouveau cadre. Nous serions en mesure de comprendre l'ampleur des efforts de migration et d'évaluer comment ses fonctionnalités pourraient l'aider sans affecter les autres applications React de QuintoAndar.
Il fallait impérativement que les pages puissent continuer à être explorées par les moteurs de recherche. Next.js répond à cette exigence en prenant en charge le rendu côté serveur prêt à l'emploi et élimine la nécessité d'une configuration personnalisée. Cette documentation facilite le partage des connaissances sur la façon d'effectuer des tâches telles que l'extraction de données sur le serveur et l'intégration de nouveaux développeurs. L'affichage 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 offrant des performances optimales, telles que le répartition du code et le préchargement automatiques. Même si la structure existante proposait déjà de telles fonctionnalités, le travail supplémentaire requis de la part des développeurs a entravé leur adoption. Par exemple, la division du code au niveau de la page ou du composant devait être effectuée manuellement.
Optimiser les ressources JavaScript
La première étape a consisté à supprimer le code inutilisé. Nous avons examiné les rapports de l'analyseur de bundle Webpack, qui affiche le contenu de chaque bundle JS, et examiné attentivement l'ensemble des scripts tiers. Nous avons ainsi pu supprimer certaines bibliothèques de suivi qui n'étaient pas utilisées sur cette page spécifique.
Notre équipe a continué d'évaluer le coût de performances des fonctionnalités existantes. Par exemple, le bouton "J'aime" a nécessité beaucoup de code JS pour fonctionner. Toutefois, sur la page des copropriétés, moins de 0,5% des utilisateurs ont interagi avec le bouton, qui est disponible et utilisé plus fréquemment dans d'autres parties de l'application. Après avoir discuté à la fois de l'ingénierie et des produits, nous avons décidé de supprimer cette fonctionnalité.
D'autres optimisations JS étaient déjà en place, telles que la compression statique avec Brotli, effectuée lors de la compilation à l'aide de BrotliWebpackPlugin, et appliquée à d'autres types de ressources statiques. Au début, nous nous appuyions sur la compression fournie par le CDN, et Brotli a réduit la taille JS de 18% par rapport à gzip. Nous avons ensuite opté pour la compression Brotli au moment de la compilation, ce qui nous a permis d'obtenir une réduction de 24 %.
Optimiser les ressources d'image
Dans la version mobile, une image héros 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.
Auparavant, toutes les images comportaient déjà les 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 disposent d'écrans avec une densité de pixels très élevée, ce qui signifie que le navigateur affiche des versions 3 ou 4x de l'image, si possible. À mesure que la résolution augmente, l'œil humain a plus de mal à percevoir les différences, mais la taille des fichiers augmente malgré tout. Limiter la résolution d'image maximale a permis d'améliorer la taille de l'image sans compromettre l'expérience utilisateur. Nous avons limité l'affichage de l'image héros à sa version 2x au maximum, qui est environ 35% plus petite que la version 3x et 50% plus petite que la version 4x.
Pour terminer, nous avons utilisé une stratégie de préchargement pour télécharger et afficher l'image dès que possible, dans l'attente d'améliorer la métrique LCP.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
Le composant image intégré à Next.js inclut bon nombre de ces optimisations, comme 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'intégrer à de nouvelles fonctionnalités.
Réduire le décalage de mise en page
La page des copropriétés présentait quelques problèmes avec le Cumulative Layout Shift (CLS). Les éléments responsables des décalages de mise en page n'étaient affichés que dans le client (par exemple, hydratation du balisage côté serveur avec des composants affichés par le client, ou images sans attributs width et height définis).
Pour résoudre ces problèmes, nous définissons les dimensions exactes de ces éléments lorsque cela est possible, ou des valeurs estimées avec min-height. D'autres options sont disponibles, comme utiliser la propriété CSS aspect-ratio. Nous avons également créé des espaces réservés pour empêcher les composants affichés dynamiquement de provoquer des décalages de mise en page.
Déploiement progressif des modifications
Notre équipe souhaitait valider la version optimisée de la page du hub des copropriétés afin d'améliorer l'expérience utilisateur. Pour y parvenir, nous avons adopté une stratégie de déploiement progressif:
- Lors de la première phase, la nouvelle version a été publiée pour quelques URL soigneusement sélectionnées, afin que seuls quelques centaines d'utilisateurs par jour puissent les voir.
- Lors de la seconde phase, elle a été publiée sur davantage de pages, soit quelques milliers d'utilisateurs par jour.
- Dans la troisième et dernière phase, elle a été publiée pour toutes les pages, et le déploiement s'est fait pour tous les utilisateurs.
Au cours de cette période, l'équipe d'ingénieurs a mesuré en continu les performances des pages en production et a continué à chercher des améliorations. De plus, l'équipe a comparé les métriques métier de la nouvelle et de l'ancienne version. Les résultats obtenus au cours de cette période de validation se sont révélés prometteurs.
Résultats
L'équipe a utilisé SpeedCurve pour exécuter en continu des tests en laboratoire sur la page des copropriétés. 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 seconde | -39% |
| Délai avant interactivité (TTI) | 12,16 secondes | 7,48 secondes | -39% |
| Temps de blocage total (TBT) | 1 124 millisecondes | 1 056 millisecondes | -4% |
| Cumulative Layout Shift (CLS) | 0,0402 | 0,0093 | -77% |
Nous voulions également vérifier l'impact sur nos utilisateurs réels. En nous appuyant sur les données réelles collectées via la surveillance du site Web d'Instana, nous avons étudié la période d'un mois avant et après le déploiement. En comparant le 75e centile pour les mobinautes, nous avons constaté que le LCP a diminué de 26 % et le FID de 72%.
PageSpeed Insights fournit un rapport de données réelles sur les 28 derniers jours. À elle seule, la page des copropriétés la plus consultée contenait suffisamment de données pour générer un rapport destiné aux mobinautes. Depuis novembre 2021, toutes les métriques Core Web Vitals se trouvent dans le bucket "bon".
Lors du déploiement progressif, nous avons constaté une baisse des taux de rebond. Lorsque nous avons terminé la version pour toutes les pages, Google Analytics a enregistré une diminution de 46% du taux de rebond, une augmentation de 87% du nombre de pages 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 payantes, avec une baisse de 59 %, signe positif pour les investissements dans les annonces au paiement par clic (PPC).
Concernant l'impact sur les métriques commerciales, nous avons analysé les taux de conversion pour des transactions telles que la planification d'une tournée et les demandes de location ou d'achat de propriété. Malgré le déploiement des améliorations, notre équipe a comparé la conversion entre l'ancienne et la nouvelle version. Au cours de la même semaine, le groupe de pages proposant la nouvelle version a enregistré une augmentation de 5% du nombre de conversions, tandis que les autres pages ont enregistré une légère diminution au niveau de la même métrique.
Conclusion
Ce projet est la première partie d'un effort de migration à long terme de React sans framework vers Next.js. Depuis, les équipes qui ont travaillé sur la page des copropriétés ont formulé des commentaires positifs sur l'amélioration de l'expérience des 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 permettra d'établir un terrain d'entente entre les différentes applications.
Dans l'ensemble, la plate-forme de contenu relatif aux copropriétés n'a cessé de se développer en termes de nombre absolu d'utilisateurs et de transactions. Dans l'analyse à long terme, de nombreux facteurs contribuent à ce résultat, comme l'expansion des activités de QuintoAndar et les initiatives de SEO telles que l'amélioration de l'indexation des pages. Au cours de ce projet, nous avons constaté que les performances des pages font également partie de ces facteurs, et qu'elles peuvent potentiellement avoir un impact positif sur les conversions.
Un grand merci à Pedro Carmo, responsable produit de l'équipe SEO, pour avoir examiné les données utilisateur et créé toute l'analyse de conversion présentée dans cette étude de cas.