In che modo QuintoAndar ha aumentato i tassi di conversione e le pagine per sessione migliorando il rendimento delle pagine

Un progetto incentrato sull'ottimizzazione di Core Web Vitals e sulla migrazione a Next.js ha comportato un aumento del 5% dei tassi di conversione e dell'87% delle pagine per sessione.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar è un'azienda brasiliana di tecnofinanza i cui prodotti offrono soluzioni end-to-end digitali per il settore immobiliare. Quest'anno abbiamo condotto un progetto incentrato sul miglioramento delle prestazioni di un hub di contenuti nella nostra app, con risultati incoraggianti nell'aumento del traffico degli utenti e delle metriche sulle conversioni.

46%

riduzione della frequenza di rimbalzo

L'87%

aumento delle pagine per sessione

Il 5%

miglioramento della conversione durante la fase di convalida

Sfide

La nostra app ha un hub di contenuti condominiali con oltre 40.000 pagine, in cui gli utenti possono ottenere informazioni sulle loro proprietà, controllare foto delle aree comuni, leggere informazioni sul quartiere e trovare annunci disponibili in affitto o in vendita. Queste pagine sono molto importanti per QuintoAndar:

  • Sono una fonte importante di traffico organico, con un numero sempre crescente di utenti provenienti dai risultati dei motori di ricerca.
  • Hanno tassi di conversione elevati nel medio e lungo termine rispetto ad altre pagine.

Tuttavia, si sono verificati problemi in termini di rendimento e esperienza utente in queste pagine:

  • Le prestazioni, misurate da Core Web Vitals, non erano ottimizzate e si sono verificati problemi noti relativi a caricamenti delle pagine lenti, lenta risposta all'input utente e instabilità del layout.
  • Le frequenze di rimbalzo erano elevate, anche se ci aspettavamo un aumento rispetto ad altre parti dell'app.
  • L'aggiornamento dell'esperienza sulle pagine nella Ricerca Google, che all'epoca non era ancora stato rilasciato, includeva Core Web Vitals nell'algoritmo di ranking, il che significava che il rendimento della pagina poteva influire sulla modalità di visualizzazione dei risultati di ricerca.

Allo stesso tempo, abbiamo identificato alcune opportunità per l'esperienza degli sviluppatori che potrebbero generare utili in altri progetti dell'azienda:

  • La nostra logica di rendering lato server, che esegue il rendering di tutte le pagine con traffico elevato, tra cui quelle dei condomini, è stata creata internamente ed è diventata troppo complessa da gestire e integrare con le nuove assunzioni.
  • Anche le funzionalità essenziali per ottenere un buon rendimento dell'app, come la suddivisione del codice, richiedevano una configurazione personalizzata e il lavoro manuale degli sviluppatori.
  • QuintoAndar ha oltre 30 applicazioni web React. Fornire aggiornamenti a queste applicazioni e gestirle in conformità alle best practice è un'attività ardua.

Approccio

Abbiamo avviato un progetto di ottimizzazione del rendimento dell'hub di contenuti per condomini per migliorare l'esperienza utente, in quanto questi miglioramenti potrebbero portare a un aumento delle conversioni, a una migliore SEO e a una maggiore usabilità. Questa iniziativa è stata anche un'opportunità per migliorare l'esperienza degli sviluppatori.

Migrazione a Next.js

La nuova versione della pagina del condominio è stata implementata con Next.js. Essendo in gran parte indipendente dalle altre parti dell'app, l'hub di contenuti per condomini sembrava una buona scelta per provare un nuovo framework. Potremmo capire l'entità degli sforzi di migrazione e valutare in che modo le sue funzionalità potrebbero essere utili senza influire sulle altre app React in QuintoAndar.

Un requisito fondamentale era garantire che le pagine rimanessero scansionabili dai motori di ricerca. Next.js soddisfa questo requisito supportando il rendering lato server out-of-the-box ed eliminando la necessità di una configurazione personalizzata. La documentazione semplifica notevolmente la condivisione delle conoscenze su come svolgere attività come il recupero dei dati sul server e l'onboarding di nuovi sviluppatori. È noto che il rendering lato server migliora le metriche relative alle prestazioni, come il first contentful paint (FCP).

Il framework fornisce altre funzionalità ottimizzate per le prestazioni, come la suddivisione del codice e il prefetching automatici. Sebbene la struttura esistente fornisse già queste funzionalità, il lavoro aggiuntivo richiesto agli sviluppatori ne ha bloccato l'adozione. Ad esempio, la suddivisione del codice a livello di pagina o componente doveva essere eseguita manualmente.

Ottimizzazione delle risorse JavaScript

Il primo passaggio è stato rimuovere il codice inutilizzato. Abbiamo esaminato i report di Webpack Bundle Analyzer, che mostrano i contenuti di ogni bundle JS, e abbiamo esaminato attentamente tutti gli script di terze parti. Di conseguenza, abbiamo potuto eliminare alcune librerie di monitoraggio che non venivano utilizzate in questa pagina specifica.

Il nostro team è andato oltre e ha valutato il costo in termini di prestazioni delle funzionalità esistenti. Ad esempio, il pulsante "Mi piace" richiedeva molto codice JS per funzionare. Tuttavia, nella pagina del condominio meno dello 0, 5% degli utenti ha interagito con il pulsante, che è disponibile e utilizzato più di frequente in altre parti della nostra app. Dopo una discussione che ha coinvolto sia il team di ingegneria che quello di prodotto, abbiamo deciso di rimuovere questa funzionalità.

Un'animazione che mostra la funzionalità del pulsante "Mi piace". C'è una scheda che pubblicizza un appartamento in affitto. Nell'angolo in basso a destra della scheda è presente un pulsante a forma di cuore grigio che diventa blu quando viene fatto clic.

Erano già state implementate altre ottimizzazioni JS, come la compressione statica con Brotli, eseguita in fase di compilazione utilizzando BrotliWebpackPlugin, che è stata applicata anche ad altri tipi di risorse statiche. All'inizio, ci basavamo sulla compressione fornita dalla CDN e Brotli ha ridotto le dimensioni del codice JS del 18% rispetto a gzip. Tuttavia, abbiamo poi adottato la compressione Brotli in fase di compilazione e siamo riusciti a ottenere una riduzione del 24%.

Ottimizzazione delle risorse per le immagini

Nella versione mobile è presente un'immagine hero che occupa la maggior parte dell'area above the fold. Si tratta anche della Largest Contentful Paint (LCP) della pagina.

La pagina del condominio di Edifício Copan (San Paolo, Brasile). Una foto scattata a livello del suolo mostra le curve della struttura dell'edificio.
L'immagine hero di una pagina di condominio.

In precedenza, tutte le immagini avevano già gli attributi srcset e sizes per pubblicare immagini adattabili. Abbiamo anche utilizzato Thumbor per ridimensionare le immagini on demand e abbiamo configurato la nostra CDN per memorizzarle nella cache in modo efficiente.

I dispositivi mobili moderni hanno display con una densità di pixel molto elevata, il che significa che il browser eseguirà il rendering di versioni 3x o 4x dell'immagine, se disponibili. Con l'aumento della risoluzione, diventa più difficile per l'occhio umano percepire le differenze, ma le dimensioni dei file aumenteranno comunque. Il limite alla risoluzione massima delle immagini ha migliorato le dimensioni delle immagini senza compromettere l'esperienza utente. Abbiamo limitato la pubblicazione dell'immagine hero alla versione 2x al massimo, che è circa il 35% più piccola della versione 3x e il 50% più piccola della versione 4x.

Per finire, abbiamo utilizzato una strategia di precaricamento per scaricarla e visualizzarla il prima possibile, con l'obiettivo di migliorare la metrica LCP.

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

Il componente immagine integrato di Next.js include molte di queste ottimizzazioni, come il ridimensionamento responsive e il caricamento con priorità. Durante questo progetto, non abbiamo eseguito la migrazione delle immagini esistenti per utilizzare questo componente, ma prevediamo di adottarlo nelle nuove funzionalità.

Ridurre la variazione del layout

La pagina del condominio ha riscontrato alcuni problemi con la variazione layout cumulativa (CLS). Gli elementi responsabili dei cambiamenti di layout sono stati visualizzati solo nel client, ad esempio l'idratazione del markup lato server con componenti visualizzati dal client o immagini senza attributi width e height definiti.

Per risolvere questi problemi, se possibile, impostiamo dimensioni esatte per questi elementi o valori stimati con min-height. Esistono altre opzioni, ad esempio l'utilizzo della proprietà CSS aspect-ratio. Abbiamo anche creato segnaposto per impedire che i componenti visualizzati in modo dinamico causino cambiamenti di layout.

Un&#39;immagine che mostra un&#39;area urbana in Google Maps con un indicatore rosso al centro.
La definizione delle dimensioni per elementi come l'immagine della mappa riduce il valore CLS.

Implementazione graduale delle modifiche

Il nostro team voleva convalidare la versione ottimizzata della pagina dell'hub condominio per assicurarsi che l'esperienza utente fosse migliore. Per raggiungere questo obiettivo, abbiamo adottato una strategia di implementazione progressiva:

  1. Nella prima fase, la nuova versione è stata pubblicata per alcuni URL selezionati, quindi solo poche centinaia di utenti al giorno li vedevano.
  2. Nella seconda fase, è stata pubblicata per più pagine, raggiungendo alcune migliaia di utenti al giorno.
  3. Nella terza e ultima fase, è stata pubblicata per tutte le pagine e l'implementazione è stata completata per tutti gli utenti.

Durante questo periodo, il team di tecnici ha misurato continuamente le prestazioni delle pagine in produzione e ha continuato a impegnarsi per migliorare. Inoltre, il team ha confrontato le metriche aziendali tra la nuova e la versione precedente. I risultati di questo periodo di convalida sono stati promettenti.

Risultati

Il team ha utilizzato SpeedCurve per eseguire continuamente test di laboratorio sulla pagina del condominio. Ecco i risultati per la versione mobile:

Metrica del lab Prima Dopo Differenza
Largest Contentful Paint (LCP) 2,41 secondi 1,48 secondi -39%
Tempo all'interattività (TTI) 12,16 secondi 7,48 secondi 39%
Tempo di blocco totale (TBT) 1124 millisecondi 1056 millisecondi 4%
Cumulative Layout Shift (CLS) 0,0402 0,0093 -77%
Risultati delle metriche di laboratorio raccolti con SpeedCurve.

Volevamo anche verificare l'impatto sui nostri utenti reali. Utilizzando i dati sul campo raccolti con Instana Website Monitoring, abbiamo esaminato il periodo di un mese prima e dopo l'implementazione. Confrontando il 75° percentile per gli utenti di dispositivi mobili, abbiamo riscontrato che il LCP è diminuito del 26% e il FID del 72%.

Un grafico a linee con i valori LCP che confrontano le versioni nuove e precedenti durante il mese corrente e quello precedente. La curva della nuova versione è mobile tra 2 e 4 secondi e rimane sotto la curva della versione precedente per la maggior parte del tempo.
Un grafico a linee con valori FID che confronta la nuova versione con quella precedente durante il mese in corso e quello precedente. La curva della nuova versione rimane al di sotto di 100 ms per la maggior parte del tempo, mentre nella curva della versione precedente sono presenti alcuni picchi che superano i 250 ms.
Risultati delle metriche dei campi raccolti con Instana.

PageSpeed Insights fornisce un report sui dati sul campo relativi agli ultimi 28 giorni. Solo la pagina del condominio più visitata conteneva dati sufficienti per generare un report per gli utenti di dispositivi mobili. A partire da novembre 2021, tutti i Core Web Vitals sono nel bucket "valido".

Uno screenshot del report PageSpeed Insights incentrato sulla sezione Dati sul campo. Tutte le metriche di Core Web Vitals (FCP, FID, LCP, CLS) rientrano nel bucket Buono.
PageSpeed Insights mostra che gli utenti di dispositivi mobili stanno vivendo un'esperienza positiva nella pagina del condominio più visitata.

Durante il graduale implementazione, abbiamo notato un calo dei tassi di rimbalzo. Al termine del rilascio per tutte le pagine, Google Analytics ha mostrato una diminuzione del 46% della frequenza di rimbalzo, un aumento dell'87% delle pagine per sessione e un aumento del 49% della durata media della sessione. La riduzione del tasso di abbandono è stata ancora maggiore per le ricerche a pagamento, raggiungendo un calo del 59%, un segnale positivo per gli investimenti negli annunci pay-per-click (PPC).

Screenshot di un grafico di Google Analytics. Confronta i tassi di abbandono tra due periodi distinti a marzo 2021. A partire dal 17 marzo, si è verificata una leggera diminuzione della frequenza di rimbalzo. Il calo si accentua il 24 marzo.
Google Analytics mostra la diminuzione della frequenza di rimbalzo man mano che introduciamo la nuova versione in più pagine.

Per quanto riguarda l'impatto sulle metriche aziendali, abbiamo analizzato le percentuali di conversione per transazioni come la pianificazione di un tour e la richiesta di affitto o acquisto di una proprietà. Mentre i miglioramenti erano ancora in fase di implementazione, il nostro team ha confrontato la conversione tra la versione precedente e la nuova. Nella stessa settimana, il gruppo di pagine con la nuova versione ha registrato un aumento delle conversioni del 5%, mentre le altre pagine hanno registrato una lieve diminuzione della stessa metrica.

Due grafici a linee affiancati, ciascuno dei quali confronta le conversioni tra la settimana corrente e quella precedente. Quello a sinistra è per la versione precedente della pagina e mostra che la curva di conversione della settimana corrente è leggermente inferiore a quella della settimana precedente. Quella giusta è per la nuova versione e la curva di conversione per la settimana corrente è leggermente superiore a quella della settimana precedente.
Nella stessa settimana, la conversione per la nuova versione è aumentata, mentre la versione precedente ha registrato una lieve diminuzione.

Conclusione

Questo progetto è la prima parte di un impegno di migrazione a lungo termine da React senza framework a Next.js. I team che hanno lavorato alla pagina dei condomini da allora hanno dato un feedback positivo sull'esperienza dello sviluppatore migliorata. Altri team che dovevano eseguire il bootstrap di nuove app web lo hanno già fatto con Next.js. Riteniamo che Next.js semplificherà le attività di manutenzione e stabilirà un terreno comune tra le diverse app.

Nel complesso, l'hub di contenuti per condomini è in continua crescita in termini di numero assoluto di utenti e transazioni. Nell'analisi a lungo termine, molti fattori contribuiscono a questo risultato, come l'espansione delle operazioni e delle iniziative SEO di QuintoAndar, ad esempio il miglioramento dell'indicizzazione delle pagine. Durante questo progetto, abbiamo riscontrato che anche il rendimento della pagina è uno di questi fattori con un grande potenziale di impatto positivo sulle conversioni.

Un ringraziamento speciale a Pedro Carmo, Product Manager del team SEO, per aver esaminato i dati utente e creato tutte le analisi delle conversioni riportate in questo case study.