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 de 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. Essas 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:

  • A performance, medida pelas Core Web Vitals, não foi otimizada, e havia problemas conhecidos relacionados a carregamentos lentos de páginas, lentidão na resposta à 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 do lado do servidor, que renderiza todas as páginas de alto tráfego, incluindo páginas de condomínios, foi criada internamente e se tornou muito complexa para manter e integrar novas contratações.
  • 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 em React. Fornecer atualizações para esses aplicativos e mantê-los de acordo com as práticas recomendadas é uma tarefa árdua.

Abordagem

Começamos um projeto de otimização de desempenho do hub de conteúdo de condomínios para melhorar a experiência do usuário, já que essas melhorias poderiam levar a ganhos de conversão, melhor SEO e melhor 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. Poderíamos entender a magnitude dos esforços de migração e avaliar como os recursos poderiam ajudar sem afetar os outros aplicativos 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 porque oferece suporte à renderização do lado do servidor e elimina a necessidade de uma configuração personalizada. A documentação facilita muito o compartilhamento de informações sobre como realizar tarefas, como a busca de dados no servidor e a 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 melhor desempenho, como divisão de código e pré-busca automáticas. 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 JavaScript

A primeira etapa foi remover o código não utilizado. Analisamos os relatórios do Analisador de pacotes Webpack, que mostra o conteúdo de cada pacote do JS, e analisamos cuidadosamente todos os scripts de terceiros. Como resultado, pudemos limpar algumas bibliotecas de acompanhamento que não foram usadas nesta 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 nosso app. Após uma discussão envolvendo engenharia e produto, decidimos remover esse recurso.

Uma animação mostrando o recurso do botão "Gostei". 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. Depois, mudamos para a compactação Brotli no tempo de 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, na sigla em inglês) 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 da página de um 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 forma eficiente.

Dispositivos móveis modernos têm telas com densidade de pixels muito alta, o que significa que o navegador renderizaria versões 3x ou 4x da imagem, se disponíveis. À 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.

Para finalizar, 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 o 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 progressivo:

  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 dados de campo coletados com o Monitoramento de site do Instana, 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 de condomínio mais acessada sozinha tinha dados suficientes para gerar um relatório para usuários de dispositivos móveis. Desde novembro de 2021, todas as Core Web Vitals estão no bucket "bom".

Uma 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 o lançamento de todas as páginas, o Google Analytics apresentava uma redução de 46% na taxa de rejeição, um aumento de 87% nas páginas por sessão e 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 uma queda na taxa de rejeição à 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. Embora as melhorias ainda estivessem sendo lançadas, nossa equipe comparou as conversões 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 anterior. A correta é para a nova versão, e a curva de conversão da semana atual está um pouco acima 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, descobrimos 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.