Um projeto focado na otimização das Core Web Vitals e na migração para o Next.js resultou em um aumento de 5% nas taxas de conversão e de 87% nas páginas por sessão.
A 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 nas 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 a 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 médio a longo em comparação com outras páginas.
No entanto, houve desafios em relação ao desempenho 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 forma como os resultados da pesquisa seriam exibidos.
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 em 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 gerar mais conversões, um melhor SEO e uma usabilidade melhor. 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 rastreáveis 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 que otimizam o desempenho, como a divisão automática de código e a 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.
Como otimizar 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.
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 da criação 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.
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 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. Limitar a resolução máxima da imagem melhorou o tamanho da imagem sem comprometer a experiência do usuário. Limitamos a imagem principal para veicular 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.
Redução da 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.
Lançar as mudanças de forma progressiva
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:
- 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.
- Na segunda fase, foi publicado para mais páginas, chegando a alguns milhares de usuários por dia.
- 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 (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% |
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 percentil 75 para usuários de dispositivos móveis, descobrimos que o LCP diminuiu 26% e o FID diminuiu 72%.
O PageSpeed Insights oferece um relatório de dados de campo dos últimos 28 dias. Somente 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".
Durante o lançamento progressivo, notamos uma queda nas taxas de rejeição. Quando terminamos a liberação para todas as páginas, o Google Analytics mostrou uma reduçã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).
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% nas conversões, enquanto as outras páginas tiveram uma ligeira diminuição na mesma métrica.
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 do desenvolvedor. 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.