Cómo QuintoAndar mejoró el rendimiento de las páginas para aumentar los porcentajes de conversiones y las páginas por sesión

Un proyecto enfocado en optimizar las métricas web esenciales y migrar a Next.js generó un aumento del 5% en los porcentajes de conversiones y un aumento del 87% en las páginas por sesión.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar es una empresa brasileña de proptech cuyos productos ofrecen soluciones digitales de extremo a extremo para bienes raíces. Este año, llevamos a cabo un proyecto enfocado en mejorar el rendimiento de un centro de contenido en nuestra aplicación y obtuvimos resultados alentadores en el aumento del tráfico de usuarios y las métricas de conversión.

46%

reducción del porcentaje de rebote

87%

aumento de las páginas por sesión

Un 5%

mejora en la conversión durante la fase de validación

Desafíos

Nuestra app tiene un centro de contenido de condominios con más de 40,000 páginas, en el que los usuarios pueden obtener información sobre sus propiedades, ver fotos de las áreas comunes, leer sobre el vecindario y encontrar fichas disponibles para alquiler o venta. Estas páginas son muy importantes para QuintoAndar:

  • Son una fuente importante de tráfico orgánico, con una cantidad cada vez mayor de usuarios que provienen de los resultados de los motores de búsqueda.
  • Tienen porcentajes de conversiones altos a mediano y largo plazo en comparación con otras páginas.

Sin embargo, hubo desafíos en cuanto al rendimiento y la experiencia del usuario en estas páginas:

  • Su rendimiento, medido por las Métricas web esenciales, no estaba optimizado y había problemas conocidos relacionados con cargas de página lentas, baja capacidad de respuesta a las entradas del usuario y baja estabilidad del diseño.
  • Sus tasas de rebote fueron altas, aunque esperábamos que fueran más altas que en otras partes de la aplicación.
  • La actualización de la experiencia de página en la Búsqueda de Google, que en ese momento aún no se había lanzado, incluiría las Métricas web esenciales en el algoritmo de clasificación, lo que significaba que el rendimiento de la página podría afectar la forma en que se mostrarían los resultados de la búsqueda.

Al mismo tiempo, identificamos algunas oportunidades de experiencia del desarrollador que podrían generar ganancias en otros proyectos de la empresa:

  • Nuestra lógica de renderización del servidor, que renderiza todas las páginas de alto tráfico, incluidas las páginas de condominios, se creó de forma interna y se volvió demasiado compleja para mantenerla y integrar a los nuevos empleados.
  • Las funciones esenciales para lograr un buen rendimiento de la app, como la división de código, también requerían una configuración personalizada y trabajo manual por parte de los desarrolladores.
  • QuintoAndar tiene más de 30 aplicaciones web de React. Proporcionar actualizaciones a estas aplicaciones y mantenerlas de acuerdo con las prácticas recomendadas es una tarea ardua.

Enfoque

Comenzamos un proyecto de optimización del rendimiento del centro de contenido de condominios para mejorar la experiencia del usuario, ya que estas mejoras podrían generar ganancias de conversiones, un mejor SEO y una mejor usabilidad. Esta iniciativa también fue una oportunidad adecuada para mejorar la experiencia de los desarrolladores.

Cómo migrar a Next.js

La nueva versión de la página del condominio se implementó con Next.js. Dado que es bastante independiente de otras partes de la app, el centro de contenido del condominio parecía un buen candidato para probar un nuevo framework. Podríamos comprender la magnitud de los esfuerzos de migración y evaluar cómo sus funciones podrían ayudar sin afectar a las otras apps de React en QuintoAndar.

Un requisito estricto era garantizar que los motores de búsqueda pudieran seguir rastreando las páginas. Next.js cumple con este requisito, ya que admite la renderización del servidor de forma predeterminada y elimina la necesidad de una configuración personalizada. La documentación facilita mucho el intercambio de conocimientos sobre cómo realizar tareas como la recuperación de datos en el servidor y la integración de desarrolladores nuevos. También se sabe que la renderización del servidor mejora el rendimiento de las métricas, como el primer procesamiento de imagen con contenido (FCP).

El framework proporciona otras funciones que favorecen el rendimiento, como la división de código y la prefetching automáticas. Si bien la estructura existente ya proporcionaba esas funciones, el trabajo adicional que se les exigía a los desarrolladores detuvo su adopción. Por ejemplo, la división de código a nivel de la página o del componente debía realizarse de forma manual.

Cómo optimizar los recursos de JavaScript

El primer paso fue quitar el código que no se usaba. Analizamos los informes del Webpack Bundle Analyzer, que muestran el contenido de cada paquete JS, y revisamos cuidadosamente todas las secuencias de comandos de terceros. Como resultado, pudimos limpiar algunas bibliotecas de seguimiento que no se usaban en esta página específica.

Nuestro equipo fue más allá y evaluó el costo de rendimiento de las funciones existentes. Por ejemplo, el botón “Me gusta” requería bastante código JS para funcionar. Sin embargo, en la página del condominio, menos del 0.5% de los usuarios interactuaron con el botón, que está disponible y se usa con más frecuencia en otras partes de nuestra app. Después de una discusión con Ingeniería y Producto, decidimos quitar esta función.

Una animación que muestra la función del botón “me gusta”. Hay una tarjeta sobre un departamento disponible para alquilar. En la esquina inferior derecha de la tarjeta, hay un botón gris en forma de corazón que se vuelve azul cuando se hace clic en él.

Ya se habían implementado otras optimizaciones de JS, como la compresión estática con Brotli, que se realizó en el momento de la compilación con BrotliWebpackPlugin y también se aplicó a otros tipos de recursos estáticos. Al principio, dependíamos de la compresión que proporcionaba la CDN, y Brotli redujo el tamaño de JS en un 18% en comparación con gzip. Sin embargo, luego cambiamos a la compresión Brotli en el tiempo de compilación y logramos una reducción del 24%.

Cómo optimizar los recursos de imagen

Hay una imagen hero que ocupa la mayor parte del área superior de la mitad inferior de la página en la versión para dispositivos móviles. También es el procesamiento de imagen con contenido más grande (LCP) de la página.

Página del condominio Edifício Copan (São Paulo, Brasil). Una foto tomada desde el nivel del suelo muestra las curvas de la estructura del edificio.
La imagen hero de una página de condominio.

Anteriormente, todas las imágenes ya tenían los atributos srcset y sizes para publicar imágenes responsivas. También usamos Thumbor para cambiar el tamaño de las imágenes a pedido y configuramos nuestra CDN para almacenarlas en caché de manera eficiente.

Los dispositivos móviles modernos tienen pantallas con una densidad de píxeles muy alta, lo que significa que el navegador renderizaría versiones 3 o 4 veces de la imagen, si está disponible. A medida que aumenta la resolución, es más difícil que el ojo humano perciba las diferencias, pero los tamaños de los archivos aumentarán de todos modos. Limitar la resolución máxima de las imágenes mejoró el tamaño de las imágenes sin comprometer la experiencia del usuario. Limitamos la imagen hero para que publique su versión 2x como máximo, que es aproximadamente un 35% más pequeña que la versión 3x y un 50% más pequeña que la versión 4x.

Para finalizar, usamos una estrategia de precarga para descargarla y mostrarla lo antes posible, con la esperanza de mejorar la métrica de LCP.

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

El componente de imagen integrado de Next.js incluye muchas de estas optimizaciones, como el cambio de tamaño responsivo y la carga priorizada. Durante este proyecto, no migramos las imágenes existentes para usar este componente, pero planeamos adoptarlo en funciones nuevas.

Cómo reducir el cambio de diseño

La página del condominio tuvo algunos problemas con el cambio de diseño acumulado (CLS). Los elementos responsables de los cambios de diseño se renderizaron solo en el cliente; por ejemplo, la hidratación del marcado del servidor con componentes renderizados por el cliente o imágenes sin atributos width y height definidos.

Para resolver estos problemas, configuramos dimensiones exactas para estos elementos cuando es posible o valores estimados con min-height. Hay más opciones, como usar la propiedad CSS aspect-ratio. También creamos marcadores de posición para evitar que los componentes renderizados de forma dinámica provoquen cambios de diseño.

Una imagen que muestra un área urbana en Google Maps con un marcador rojo en el centro.
Definir dimensiones para elementos como la imagen del mapa redujo el CLS.

Lanzamiento progresivo de cambios

Nuestro equipo quería validar la versión optimizada de la página principal del condominio para asegurarse de que la experiencia del usuario fuera mejor. Para lograrlo, adoptamos una estrategia de lanzamiento progresivo:

  1. En la primera fase, la versión nueva se publicó para algunas URLs seleccionadas a mano, de modo que solo unas pocas centenas de usuarios por día las vieron.
  2. En la segunda fase, se publicó en más páginas, lo que representó unos pocos miles de usuarios por día.
  3. En la tercera y última fase, se publicó para todas las páginas y se completó el lanzamiento para todos los usuarios.

Durante este período, el equipo de Ingeniería midió continuamente el rendimiento de la página en producción y siguió trabajando en mejoras. Además, el equipo comparó las métricas empresariales entre la versión nueva y la anterior. Los resultados de este período de validación fueron prometedores.

Resultados

El equipo usó SpeedCurve para ejecutar pruebas de lab de forma continua en la página del condominio. Estos son los resultados de la versión para dispositivos móviles:

Métrica del lab Antes Después Diferencia
Largest Contentful Paint (LCP) 2.41 segundos 1.48 segundos -39%
Tiempo hasta que es interactiva (TTI) 12.16 segundos 7.48 segundos -39%
Tiempo de bloqueo total (TBT) 1,124 milisegundos 1,056 milisegundos -4%
Cumulative Layout Shift (CLS) 0.0402 0.0093 -77%
Resultados de las métricas de lab recopiladas con SpeedCurve.

También queríamos verificar el impacto en nuestros usuarios reales. Con los datos de campo recopilados con la supervisión de sitios web de Instana, analizamos el período de 1 mes anterior y posterior al lanzamiento. Al comparar el percentil 75 de los usuarios de dispositivos móviles, descubrimos que la LCP disminuyó un 26% y la FID un 72%.

Un gráfico de líneas con valores de LCP que comparan las versiones nuevas y anteriores durante el mes actual y el anterior. La curva de la versión nueva oscila entre 2 y 4 segundos, y se mantiene por debajo de la curva de la versión anterior la mayor parte del tiempo.
Un gráfico de líneas con valores de FID que comparan las versiones nuevas y anteriores durante el mes actual y el anterior. La curva de la versión nueva se mantiene por debajo de 100 ms la mayor parte del tiempo, mientras que en la curva de la versión anterior hay algunos picos que superan los 250 ms.
Resultados de las métricas de campo recopiladas con Instana.

PageSpeed Insights proporciona un informe de datos de campo de los últimos 28 días. Solo la página del condominio a la que se accedió más tenía datos suficientes para generar un informe para los usuarios de dispositivos móviles. A partir de noviembre de 2021, todas las Métricas web esenciales se encuentran en el bucket "óptimo".

Captura de pantalla del informe PageSpeed Insights en la que se enfoca la sección Datos de campo. Todas las métricas de las Métricas web esenciales (FCP, FID, LCP y CLS) se encuentran en el bucket bueno.
En PageSpeed Insights, se muestra que los usuarios de dispositivos móviles tienen una buena experiencia en la página del condominio a la que se accede más.

Durante el lanzamiento progresivo, notamos una disminución en los porcentajes de rebote. Cuando terminamos el lanzamiento para todas las páginas, Google Analytics mostró una disminución del 46% en el porcentaje de rebote, un aumento del 87% en la cantidad de páginas por sesión y un aumento del 49% en la duración promedio de la sesión. La reducción del porcentaje de rebote fue aún mayor para las búsquedas pagadas, alcanzando una disminución del 59%, lo que es un indicador positivo en lo que respecta a las inversiones en anuncios pagados por clic (PPC).

Captura de pantalla de un gráfico de Google Analytics. Compara los porcentajes de rebote entre dos períodos distintos en marzo de 2021. A partir del 17 de marzo, se observa una ligera disminución en el porcentaje de rebote. La disminución se acentúa el 24 de marzo.
Google Analytics muestra que el porcentaje de rebote disminuye a medida que lanzamos la nueva versión en más páginas.

En cuanto al impacto en las métricas comerciales, analizamos los porcentajes de conversiones de transacciones como programar una visita y solicitar el alquiler o la compra de una propiedad. Mientras se implementaban las mejoras, nuestro equipo comparó la conversión entre la versión anterior y la nueva. En la misma semana, el grupo de páginas con la versión nueva mostró un aumento del 5% en las conversiones, mientras que las otras páginas tuvieron una ligera disminución en la misma métrica.

Dos gráficos de líneas en paralelo, cada uno de los cuales compara las conversiones entre la semana actual y la anterior. El de la izquierda corresponde a la versión anterior de la página, que muestra que la curva de conversiones de la semana actual es un poco inferior a la de la semana anterior. La correcta es para la versión nueva, y la curva de conversiones de la semana actual está un poco por encima de la de la semana anterior.
En la misma semana, la conversión de la versión nueva aumentó, mientras que la versión anterior tuvo una pequeña disminución.

Conclusión

Este proyecto es la primera parte de un esfuerzo de migración a largo plazo de React sin framework a Next.js. Los equipos que trabajaron en la página del condominio desde entonces dieron comentarios positivos sobre la experiencia mejorada para los desarrolladores. Otros equipos que tuvieron que iniciar nuevas apps web ya lo hicieron con Next.js. Creemos que Next.js simplificará los esfuerzos de mantenimiento y establecerá un terreno común entre diferentes apps.

En general, el centro de contenido de condominios ha crecido de forma continua en términos de la cantidad absoluta de usuarios y transacciones. En el análisis a largo plazo, hay muchos factores que contribuyen a esto, como la expansión de la operación de QuintoAndar y las iniciativas de SEO, como la mejora del indexación de páginas. Durante este proyecto, observamos que el rendimiento de la página también es uno de estos factores con un gran potencial para generar un impacto positivo en las conversiones.

Agradecimientos especiales a Pedro Carmo, gerente de producto del equipo de SEO, por analizar los datos de los usuarios y crear todos los análisis de conversiones que se muestran en este caso de éxito.