Como a QuintoAndar aumentou as taxas de conversão e as páginas por sessão ao melhorar o desempenho

Um projeto focado em otimizar as Core Web Vitals e migrar para o Next.js resultou em um aumento de 5% nas taxas de conversão e 87% nas páginas por sessão.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

O QuintoAndar é uma empresa de proptech brasileira que oferece produtos digitais completos para o mercado imobiliário. Este ano, realizamos um projeto focado em melhorar a performance de um hub de conteúdo no nosso app e tivemos resultados encorajadores no aumento do tráfego de usuários e das métricas de conversão.

46%

redução na taxa de rejeição

87%

aumento de páginas por sessão

5%

melhoria na conversão durante a fase de validação

Desafios

Nosso app tem um hub de conteúdo de condomínios com mais de 40.000 páginas, em que os usuários podem receber informações sobre as propriedades, conferir fotos das áreas comuns, ler sobre o bairro e encontrar anúncios disponíveis para aluguéis ou vendas. Estas páginas são muito importantes para o QuintoAndar:

  • Eles são uma fonte importante de tráfego orgânico, com um número cada vez maior de usuários vindos dos resultados do mecanismo de pesquisa.
  • Elas têm taxas de conversão altas em um período de médio a longo prazo em comparação com outras páginas.

No entanto, houve desafios em relação à performance e à experiência do usuário nessas páginas:

  • O desempenho, medido pelas Core Web Vitals, não estava otimizado, e havia problemas conhecidos relacionados a carregamento lento de páginas, resposta lenta à entrada do usuário e instabilidade do layout.
  • As taxas de rejeição eram altas, mesmo que a expectativa fosse que elas fossem maiores do que em outras partes do app.
  • A atualização da experiência na página na Pesquisa Google, que ainda não havia sido lançada, incluiria as Core Web Vitals no algoritmo de classificação, o que significa que a performance da página poderia afetar a exibição dos resultados da pesquisa.

Ao mesmo tempo, identificamos algumas oportunidades de experiência do desenvolvedor que poderiam gerar ganhos em outros projetos da empresa:

  • Nossa lógica de renderização no servidor, que renderiza todas as páginas de alto tráfego, incluindo as de condomínio, foi criada internamente e ficou muito complexa para manter e integrar novos contratados.
  • Recursos essenciais para alcançar uma boa performance do app, como a divisão de código, também exigiam uma configuração personalizada e trabalho manual dos desenvolvedores.
  • A QuintoAndar tem mais de 30 aplicativos da Web React. Fornecer atualizações para esses aplicativos e mantê-los de acordo com as práticas recomendadas é uma tarefa árdua.

Abordagem

Iniciamos um projeto de otimização de performance do hub de conteúdo do condomínio para melhorar a experiência do usuário, já que essas melhorias podem levar a ganhos de conversão, SEO e usabilidade. Essa iniciativa também foi uma oportunidade adequada para melhorar a experiência dos desenvolvedores.

Migrar para o Next.js

A nova versão da página do condomínio foi implementada com o Next.js. Como o hub de conteúdo do condomínio é bastante independente de outras partes do app, ele parecia ser um bom candidato para testar um novo framework. Assim, poderíamos entender a magnitude dos esforços de migração e avaliar como os recursos poderiam ajudar sem afetar os outros apps React no QuintoAndar.

Um requisito difícil era garantir que as páginas continuassem sendo rastreadas pelos mecanismos de pesquisa. O Next.js atende a esse requisito com suporte à renderização no servidor e elimina a necessidade de uma configuração personalizada. A documentação facilita o compartilhamento de conhecimento sobre como realizar tarefas, como busca de dados no servidor e integração de novos desenvolvedores. A renderização do lado do servidor também é conhecida por melhorar as métricas de desempenho, como a First Contentful Paint (FCP).

O framework oferece outros recursos de desempenho, como divisão automática de código e prefetching. Embora a estrutura já oferecesse esses recursos, o trabalho extra necessário dos desenvolvedores atrasou a adoção deles. Por exemplo, a divisão de código no nível da página ou do componente precisava ser feita manualmente.

Otimização de recursos do JavaScript

A primeira etapa foi remover o código não utilizado. Analisamos os relatórios do Webpack Bundle Analyzer, que mostram o conteúdo de cada pacote JS, e analisamos cuidadosamente todos os scripts de terceiros. Como resultado, conseguimos limpar algumas bibliotecas de rastreamento que não foram usadas nessa página específica.

Nossa equipe foi além e avaliou o custo de desempenho dos recursos atuais. Por exemplo, o botão "gostei" exigia muito JS para funcionar. No entanto, na página do condomínio, menos de 0,5% dos usuários interagiram com o botão, que está disponível e é usado com mais frequência em outras partes do app. Depois de uma discussão envolvendo engenharia e produto, decidimos remover esse recurso.

Uma animação mostrando o recurso do botão "Curtir". Há um cartão sobre um apartamento disponível para alugar. No canto inferior direito do card, há um botão cinza em forma de coração que fica azul quando clicado.

Outras otimizações do JS já estavam em vigor, como a compressão estática com Brotli, que foi feita no momento do build usando BrotliWebpackPlugin e também foi aplicada a outros tipos de recursos estáticos. No início, dependíamos da compactação fornecida pelo CDN, e o Brotli reduziu o tamanho do JS em 18% em comparação com o gzip. No entanto, mudamos para a compactação Brotli no momento do build e conseguimos uma redução de 24%.

Como otimizar recursos de imagem

Há uma imagem principal ocupando a maior parte da área acima da dobra na versão para dispositivos móveis. Ela também é a maior exibição de conteúdo (LCP) da página.

Página do condomínio Edifício Copan (São Paulo, Brasil). Uma foto tirada do nível do solo mostra as curvas da estrutura do edifício.
A imagem principal de uma página de condomínio.

Antes, todas as imagens já tinham os atributos srcset e sizes para veicular imagens responsivas. Também usamos o Thumbor para redimensionar imagens sob demanda e configuramos nossa CDN para armazená-las em cache de maneira eficiente.

Dispositivos móveis modernos têm telas com densidade de pixels muito alta, o que significa que o navegador renderiza versões 3x ou 4x da imagem, se disponível. À medida que a resolução aumenta, fica mais difícil para o olho humano perceber as diferenças, mas o tamanho dos arquivos aumenta de qualquer maneira. O limite máximo de resolução da imagem melhorou o tamanho da imagem sem comprometer a experiência do usuário. Limitamos a imagem principal para exibir no máximo a versão 2x, que é aproximadamente 35% menor que a versão 3x e 50% menor que a 4x.

Por fim, usamos uma estratégia de pré-carregamento para fazer o download e exibir o conteúdo o mais rápido possível, com o objetivo de melhorar a métrica LCP.

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

O componente de imagem integrado do Next.js inclui muitas dessas otimizações, como redimensionamento responsivo e carregamento priorizado. Durante esse projeto, não migramos as imagens existentes para usar esse componente, mas planejamos adotá-lo em novos recursos.

Reduzir a mudança de layout

A página do condomínio teve alguns problemas com o Cumulative Layout Shift (CLS). Os elementos responsáveis pelas mudanças de layout foram renderizados apenas no cliente, por exemplo, hidratando a marcação do lado do servidor com componentes renderizados pelo cliente ou imagens sem atributos width e height definidos.

Para resolver esses problemas, definimos dimensões exatas para esses elementos sempre que possível ou valores estimados com min-height. Há mais opções, como usar a propriedade CSS aspect-ratio. Também criamos marcadores de posição para evitar que componentes renderizados dinamicamente causem mudanças de layout.

Uma imagem mostrando uma área urbana no Google Maps com um marcador vermelho no centro.
Definir dimensões para elementos como a imagem do mapa reduziu a CLS.

Implementar mudanças progressivamente

Nossa equipe queria validar a versão otimizada da página do hub de condomínios para garantir que a experiência do usuário fosse melhor. Para isso, adotamos uma estratégia de lançamento progressiva:

  1. Na primeira fase, a nova versão foi publicada para alguns URLs selecionados, de modo que apenas algumas centenas de usuários por dia teriam acesso a ela.
  2. Na segunda fase, foi publicado para mais páginas, chegando a alguns milhares de usuários por dia.
  3. Na terceira e última fase, a página foi publicada e o lançamento foi concluído para todos os usuários.

Durante esse período, a equipe de engenharia mediu continuamente a performance da página em produção e continuou trabalhando em melhorias. Além disso, a equipe comparou as métricas de negócios entre a nova e a versão anterior. Os resultados desse período de validação foram promissores.

Resultados

A equipe usou o SpeedCurve para executar continuamente testes de laboratório na página do condomínio. Estes são os resultados da versão para dispositivos móveis:

Métrica do laboratório Antes Depois Diferença
Maior exibição de conteúdo (LCP) 2,41 segundos 1,48 segundo -39%
Tempo para interação da página (TTI) 12,16 segundos 7,48 segundos -39%
Tempo total de bloqueio (TBT) 1.124 milissegundos 1.056 milissegundos -4%
Cumulative Layout Shift (CLS) 0,0402 0,0093 -77%
Resultados das métricas do laboratório coletadas com o SpeedCurve.

Também queríamos verificar o impacto nos nossos usuários reais. Usando os dados de campo coletados com o Instana Website Monitoring, analisamos o período de um mês antes e depois do lançamento. Comparando o 75º percentil para usuários de dispositivos móveis, descobrimos que o LCP diminuiu 26% e a FID diminuiu 72%.

Um gráfico de linhas com valores de LCP comparando as versões nova e anterior durante o mês atual e o anterior. A curva da nova versão flutua entre 2 e 4 segundos, ficando abaixo da curva da versão anterior na maior parte do tempo.
Um gráfico de linhas com valores de FID que comparam as versões nova e anterior durante o mês atual e o anterior. A curva da nova versão fica abaixo de 100 ms na maior parte do tempo, enquanto na curva da versão anterior há alguns picos que ultrapassam 250 ms.
Resultados das métricas de campo coletados com o Instana.

O PageSpeed Insights oferece um relatório de dados de campo dos últimos 28 dias. A página do condomínio mais acessada tinha dados suficientes para gerar um relatório para usuários de dispositivos móveis. Em novembro de 2021, todas as Core Web Vitals estavam no bucket "bom".

Captura de tela do relatório do PageSpeed Insights com foco na seção &quot;Dados de campo&quot;. Todas as métricas das Core Web Vitals (FCP, FID, LCP, CLS) estão no intervalo &quot;bom&quot;.
O PageSpeed Insights mostra que os usuários de dispositivos móveis estão tendo uma boa experiência na página mais acessada do condomínio.

Durante o lançamento progressivo, notamos uma queda nas taxas de rejeição. Quando terminamos a versão para todas as páginas, o Google Analytics mostrou uma diminuição de 46% na taxa de rejeição, um aumento de 87% nas páginas por sessão e um aumento de 49% na duração média da sessão. A redução da taxa de rejeição foi ainda maior para as pesquisas pagas, chegando a uma queda de 59%, um sinal positivo em relação aos investimentos em anúncios pay-per-click (PPC).

Captura de tela de um gráfico do Google Analytics. Ela compara as taxas de rejeição entre dois períodos distintos em março de 2021. A partir de 17 de março, há uma ligeira queda na taxa de rejeição. A queda é acentuada em 24 de março.
O Google Analytics mostra que a taxa de rejeição diminuiu à medida que lançamos a nova versão em mais páginas.

Quanto ao impacto nas métricas de negócios, analisamos as taxas de conversão de transações como agendar uma visita e se inscrever para alugar ou comprar um imóvel. Enquanto as melhorias ainda estavam sendo lançadas, nossa equipe comparou a conversão entre a versão anterior e a nova. Na mesma semana, o grupo de páginas com a nova versão mostrou um aumento de 5% na conversão, enquanto as outras páginas tiveram uma ligeira diminuição na mesma métrica.

Dois gráficos de linhas lado a lado, cada um comparando a conversão entre a semana atual e a anterior. A da esquerda é da versão anterior da página, mostrando que a curva de conversão da semana atual está um pouco abaixo da semana anterior. A correta é para a nova versão, e a curva de conversão da semana atual está um pouco acima da da semana anterior.
Na mesma semana, a conversão da nova versão aumentou, enquanto a anterior teve uma pequena diminuição.

Conclusão

Esse projeto é a primeira parte de um esforço de migração de longo prazo do React sem framework para o Next.js. As equipes que trabalharam na página do condomínio desde então deram feedback positivo sobre a experiência aprimorada para desenvolvedores. Outras equipes que precisaram inicializar novos apps da Web já fizeram isso com o Next.js. Acreditamos que o Next.js vai simplificar os esforços de manutenção e estabelecer um ponto comum entre diferentes apps.

No geral, o hub de conteúdo do condomínio tem crescido continuamente em termos de número absoluto de usuários e transações. Na análise de longo prazo, muitos fatores contribuem para isso, como a expansão das operações da QuintoAndar e iniciativas de SEO, como a melhoria da indexação de páginas. Durante esse projeto, observamos que a performance da página também é um desses fatores com grande potencial de impacto positivo na conversão.

Agradecemos especialmente a Pedro Carmo, gerente de produto da equipe de SEO, por analisar os dados dos usuários e criar toda a análise de conversão apresentada neste estudo de caso.