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 portato a un aumento del 5% dei tassi di conversione e all'87% delle pagine per sessione.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar è una società brasiliana di tecnologia protettiva i cui prodotti offrono soluzioni digitali end-to-end per il settore immobiliare. Quest'anno abbiamo condotto un progetto incentrato sul miglioramento delle prestazioni di un hub di contenuti nella nostra app e i risultati sono stati incoraggianti, grazie all'aumento del traffico degli utenti e delle metriche di conversione.

Il 46%

di 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 di condomini con oltre 40.000 pagine, in cui gli utenti possono ottenere informazioni sulle loro proprietà, controllare le foto degli spazi comuni, leggere informazioni sul quartiere e trovare schede disponibili per l'affitto o la vendita. Queste pagine sono molto importanti per QuintoAndar:

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

Tuttavia, in queste pagine si sono presentate delle difficoltà in termini di rendimento ed esperienza utente:

  • Le prestazioni misurate da Segnali web essenziali non erano ottimizzate ed erano presenti problemi noti relativi a caricamenti di pagine lenti, reattività lenta all'input degli utenti e instabilità del layout.
  • Le loro frequenze di rimbalzo erano elevate, anche se ci aspettavamo che fossero più alte che in altre parti dell'app.
  • L'aggiornamento dell'esperienza sulle pagine nella Ricerca Google, che all'epoca non era ancora stato rilasciato, includeva i Segnali web essenziali nell'algoritmo di ranking, il che significava che le prestazioni delle pagine potevano influire sulla visualizzazione dei risultati di ricerca.

Allo stesso tempo, abbiamo identificato alcune opportunità legate all'esperienza degli sviluppatori che potrebbero generare vantaggi in altri progetti all'interno dell'azienda:

  • La nostra logica di rendering lato server, che esegue il rendering di tutte le pagine a traffico elevato, incluse quelle di condomini, è stata creata internamente ed è diventata troppo complessa per gestire e inserire i nuovi assunti.
  • Le funzionalità essenziali per ottenere buone prestazioni dell'app, come la suddivisione del codice, richiedevano anche una configurazione personalizzata e il lavoro manuale da parte degli sviluppatori.
  • QuintoAndar ha più di 30 applicazioni web React. Fornire aggiornamenti a queste applicazioni e mantenerle in linea con le best practice è un compito arduo.

Approccio

Abbiamo avviato un progetto di ottimizzazione delle prestazioni dell'hub dei contenuti del condominio per migliorarne l'esperienza utente, poiché questi miglioramenti potrebbero portare a un aumento delle conversioni, a una migliore SEO e a una migliore usabilità. Questa iniziativa si è rivelata anche un'opportunità appropriata 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 dei contenuti condominiale ci è sembrato un buon candidato per provare un nuovo framework. Saremmo in grado di comprendere l'entità degli sforzi di migrazione e valutare come le sue funzionalità potrebbero aiutare senza influire sulle altre app React in QuintoAndar.

Un requisito rigido era garantire che le pagine rimanessero sottoponibili a scansione da parte dei motori di ricerca. Next.js soddisfa questo requisito supportando subito il rendering lato server ed elimina la necessità di una configurazione personalizzata. La documentazione semplifica la condivisione di conoscenze su come eseguire attività come il recupero dei dati sul server e l'onboarding di nuovi sviluppatori. È noto anche che il rendering lato server migliora le metriche delle prestazioni come First Contentful Paint (FCP).

Il framework fornisce altre funzionalità ottimizzate per le prestazioni, come la suddivisione automatica del codice e il precaricamento. Anche se la struttura esistente forniva già queste funzionalità, il lavoro aggiuntivo richiesto dagli 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 consisteva nel rimuovere il codice inutilizzato. Abbiamo esaminato i report Webpack Bundle Analyzer, che mostrano i contenuti di ogni bundle JS, e abbiamo esaminato attentamente tutti gli script di terze parti. Di conseguenza, siamo riusciti a eliminare alcune librerie di monitoraggio che non erano state utilizzate in questa pagina specifica.

Il nostro team ha fatto un ulteriore passo avanti e ha valutato il costo del rendimento delle funzionalità esistenti. Ad esempio, il pulsante "Mi piace" richiedeva un certo utilizzo di 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ù spesso in altre parti della nostra app. Dopo una discussione che riguarda sia l'ingegneria che il prodotto, abbiamo deciso di rimuovere questa funzionalità.

Un'animazione che mostra la funzionalità del pulsante "Mi piace". È presente una scheda relativa a un appartamento disponibile in affitto. Nell'angolo in basso a destra della scheda, c'è un pulsante grigio a forma di cuore che diventa blu quando l'utente fa clic.

Altre ottimizzazioni JS erano già state implementate, come la compressione statica con Brotli, eseguita in fase di creazione con BrotliWebpackPlugin, e applicata anche ad altri tipi di risorse statiche. All'inizio, ci affidavamo alla compressione fornita dalla CDN e Brotli ha ridotto le dimensioni JS del 18% rispetto a gzip. Poi, però, siamo passati alla compressione Brotli al momento della creazione e siamo riusciti a ottenere una riduzione del 24%.

Ottimizzazione delle risorse immagine

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

La pagina degli appartamenti di Edifício Copan (San Paolo, Brasile). Una foto scattata dal livello del suolo mostra le curve della struttura dell'edificio.
L'immagine promozionale di una pagina di condomini.

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 configurato la nostra rete CDN per memorizzarle nella cache in modo efficiente.

I dispositivi mobili moderni dispongono di display con una densità di pixel molto elevata, il che significa che il browser eseguirebbe il rendering di versioni 3x o 4x dell'immagine, se disponibili. All'aumentare della risoluzione, diventa più difficile per l'occhio umano percepire le differenze, ma le dimensioni dei file aumenteranno in ogni caso. Ridurre la risoluzione massima delle immagini ha consentito di migliorare le dimensioni delle immagini senza compromettere l'esperienza utente. Abbiamo limitato l'immagine hero al massimo per la sua versione 2x, che è circa il 35% più piccola della versione 3x e il 50% più piccola della versione 4x.

Per concludere, abbiamo utilizzato una strategia di precaricamento per scaricarla e visualizzarla il prima possibile, in attesa di migliorare la metrica LCP.

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

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

Riduzione della variazione del layout

La pagina del condominio presenta alcuni problemi con la metrica Cumulative Layout Shift (CLS). Gli elementi responsabili delle variazioni del layout sono stati visualizzati solo nel client, ad esempio idratazione del markup lato server con componenti visualizzati dal client oppure immagini senza attributi width e height definiti.

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

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

Implementazione progressiva delle modifiche

Il nostro team voleva verificare la versione ottimizzata della pagina dell'hub condominiale, per garantire un'esperienza utente migliore. Per raggiungere questo obiettivo, abbiamo adottato una strategia di lancio progressivo:

  1. Nella prima fase, la nuova versione è stata pubblicata per alcuni URL selezionati manualmente, quindi solo poche centinaia di utenti al giorno li avrebbero visti;
  2. Nella seconda fase, è stato pubblicato per più pagine, che contava alcune migliaia di utenti al giorno;
  3. Nella terza e ultima fase, è stato pubblicato 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 lavorare per apportare miglioramenti. Inoltre, il team ha confrontato le metriche aziendali tra la nuova versione e quella 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. Questi sono 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 del lab raccolti con SpeedCurve.

Volevamo anche verificare l'impatto sui nostri utenti reali. Utilizzando i dati dei campi raccolti con il monitoraggio del sito web di Instana, abbiamo esaminato il periodo di un mese precedente e successivo all'implementazione. Confrontando il 75° percentile per gli utenti di dispositivi mobili, abbiamo riscontrato che la LCP è diminuita del 26% e il FID è diminuito del 72%.

Un grafico a linee con valori LCP che confronta la nuova e la versione precedente nel mese corrente e in quello precedente. La curva per la nuova versione fluttua tra 2 e 4 secondi, rimanendo sotto la curva per la versione precedente per la maggior parte delle volte.
Un grafico a linee con valori FID che confronta la nuova e la versione precedente nel mese corrente e in quello precedente. La curva per la nuova versione rimane al di sotto di 100 ms la maggior parte delle volte, mentre nella curva per la versione precedente ci sono alcuni picchi che superano i 250 ms.
Risultati delle metriche sul campo raccolti con Instana.

PageSpeed Insights fornisce un report sui dati dei campi per gli ultimi 28 giorni. La sola pagina dei condomini più visitata aveva dati sufficienti per generare un report per gli utenti di dispositivi mobili. A partire da novembre 2021, tutti i Segnali web essenziali si trovano nel bucket "Buono".

Uno screenshot del report PageSpeed Insights che mette in evidenza la sezione Dati sul campo. Tutte le metriche di Core Web Vitals (FCP, FID, LCP, CLS) si trovano nel bucket valido.
PageSpeed Insights mostra che gli utenti di dispositivi mobili stanno avendo un'esperienza positiva nella pagina di condomini più accessibile.

Durante l'implementazione progressiva, abbiamo notato un calo della frequenza di rimbalzo. Al termine del rilascio di tutte le pagine, Google Analytics ha registrato 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 della frequenza di rimbalzo è stata ancora maggiore per le ricerche a pagamento, raggiungendo un calo del 59%, un segno positivo per quanto riguarda gli investimenti negli annunci pay-per click (PPC).

Uno screenshot di un grafico di Google Analytics. Confronta le frequenze di rimbalzo tra due periodi distinti di marzo 2021. A partire dal 17 marzo c&#39;è un leggero calo della frequenza di rimbalzo. Il calo è accentuato il 24 marzo.
Google Analytics mostra che la frequenza di rimbalzo diminuisce man mano che abbiamo implementato la nuova versione in più pagine.

Per quanto riguarda l'impatto sulle metriche aziendali, abbiamo analizzato i tassi di conversione relativi a transazioni quali la pianificazione di un tour e la richiesta di affitto o acquisto di una tenuta. Mentre i miglioramenti venivano ancora implementati, il nostro team ha confrontato la conversione tra la versione precedente e quella 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 leggera diminuzione nella stessa metrica.

Due grafici a linee affiancati, ognuno dei quali confronta la conversione tra la settimana in corso e quella precedente. Quella a sinistra si riferisce alla versione precedente della pagina e la curva di conversione per la settimana corrente è leggermente inferiore a quella della settimana precedente. Quella giusta è riferita alla 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 piccola diminuzione.

Conclusione

Questo progetto è la prima parte di un'iniziativa a lungo termine per la migrazione da React senza framework a Next.js. I team che hanno lavorato sulla pagina del condominio da allora hanno fornito un feedback positivo in merito alla migliore esperienza degli sviluppatori. Altri team che hanno dovuto 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 dei contenuti condominiali è in continua crescita in termini di numero assoluto di utenti e transazioni. Nell'analisi a lungo termine, ci sono molti fattori che contribuiscono a questo, come l'espansione delle operazioni di QuintoAndar e le iniziative di SEO come il miglioramento dell'indicizzazione delle pagine. Durante questo progetto, abbiamo visto che anche le prestazioni delle pagine sono 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 l'analisi dei dati utente e la creazione di tutte le analisi delle conversioni viste in questo case study.