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 del 87% en las páginas por sesión.

Daniela Sayuri Yassuda
Daniela Sayuri Yassuda

QuintoAndar es una empresa brasileña de tecnología de propósito, cuyos productos ofrecen soluciones digitales integrales para el sector inmobiliario. Este año, llevamos a cabo un proyecto enfocado en mejorar el rendimiento de un centro de contenido en nuestra app y obtuvimos resultados alentadores en el aumento de las métricas de conversión y tráfico de usuarios.

El 46%

de disminución del porcentaje de rebote

El 87%

de aumento en páginas por sesión

El 5%

de 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 las que los usuarios pueden obtener información sobre sus propiedades, ver fotos de áreas comunes, leer sobre el vecindario y encontrar fichas disponibles para alquilar o vender. Estas páginas son muy importantes para QuintoAndar:

  • Son una fuente importante de tráfico orgánico, ya que cada vez más usuarios 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 relacionados con el rendimiento y la experiencia del usuario en estas páginas:

  • Su rendimiento, según las mediciones de las Métricas web esenciales, no se optimizó. Además, había problemas conocidos relacionados con la carga lenta de la página, la lentitud en la respuesta a las entradas del usuario y la inestabilidad del diseño.
  • Sus porcentajes de rebote eran altos, incluso si esperábamos que fueran más altos 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 lanzó, incluía las Métricas web esenciales en el algoritmo de clasificación, lo que significaba que el rendimiento de la página podía afectar la forma en que se mostrarían los resultados de la búsqueda.

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

  • Nuestra lógica de renderización del lado del servidor, que procesa todas las páginas de alto tráfico, incluidas las páginas de condominios, se creó internamente y se volvió demasiado compleja para mantener e 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 el trabajo manual de los desarrolladores.
  • QuintoAndar tiene más de 30 aplicaciones web de React. Publicar actualizaciones para 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 para condominios para mejorar la experiencia del usuario, ya que estas mejoras podrían aumentar las conversiones, mejorar la SEO y la usabilidad. Esta iniciativa también fue una oportunidad adecuada para mejorar la experiencia de los desarrolladores.

Migra a Next.js

La versión nueva de la página del condominio se implementó con Next.js. Al ser en gran medida independiente de otras partes de la app, el centro de contenido de condominios parecía un buen candidato para probar un nuevo framework. Podremos entender la magnitud de los esfuerzos de migración y evaluar cómo sus funciones podrían ser útiles sin afectar a las otras aplicaciones de React en QuintoAndar.

Un requisito estricto era garantizar que los motores de búsqueda siguieran rastreando las páginas. Next.js cumple con este requisito porque admite la renderización del lado del servidor lista para usar y quita la necesidad de una configuración personalizada. La documentación facilita compartir conocimientos sobre cómo realizar tareas como la recuperación de datos en el servidor y la integración de nuevos desarrolladores. También se sabe que la renderización del servidor mejora el rendimiento, como el Primer procesamiento de imagen con contenido (FCP).

El framework proporciona otras funciones optimizadas para el rendimiento, como la división de código y la carga previa automáticas. Si bien la estructura existente ya proporcionaba esas funciones, el trabajo adicional que requerían los desarrolladores retrasaron su adopción. Por ejemplo, la división del código a nivel de la página o del componente tenía que hacerse de forma manual.

Optimización de recursos de JavaScript

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

Nuestro equipo evaluó el costo del rendimiento de las funciones existentes. Por ejemplo, el botón “me gusta” requirió mucho 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 mayor frecuencia en otras partes de nuestra app. Después de una discusión sobre 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 con forma de corazón que se vuelve azul cuando se hace clic en él.

Ya se implementaron otras optimizaciones de JS, como la compresión estática con Brotli, que se realizaba en el tiempo de compilación con BrotliWebpackPlugin, y también se aplicaba a otros tipos de recursos estáticos. Al principio, confiábamos en la compresión proporcionada por la CDN, por lo que 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 recursos de imagen

Hay una imagen de héroe que ocupa la mayor parte del área en la mitad superior de la página en la versión para dispositivos móviles. También corresponde al Largest Contentful Paint (LCP) de la página.

La página del condominio del 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 principal de una página de condominios.

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 según demanda y configuramos nuestra CDN para que las almacene 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 de la imagen 3 o 4 veces si estuvieran disponibles. A medida que aumenta la resolución, es cada vez más difícil para el ojo humano percibir las diferencias, pero el tamaño de los archivos aumentará de todos modos. Al limitar la resolución máxima de la imagen, se mejora el tamaño de la imagen sin comprometer la experiencia del usuario. Limitamos la imagen hero para que se publicara la versión de 2x como máximo, que es aproximadamente un 35% más pequeña que la versión de 3x y un 50% más pequeña que la de 4x.

Para finalizar, usamos una estrategia de precarga para descargarla y mostrarla lo antes posible con el objetivo 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 implementarlo en funciones nuevas.

Reduce 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, hidratación del lenguaje de marcado del servidor con componentes renderizados por el cliente o imágenes sin atributos width y height definidos.

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

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

Implementación gradual de cambios

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

  1. En la primera fase, se publicó la nueva versión para unas pocas URL elegidas cuidadosamente, de modo que solo unos cientos de usuarios por día las veían;
  2. En la segunda fase, se publicó para más páginas, lo que representaba 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 continuamente en la página del condominio. Estos son los resultados para la versión para dispositivos móviles:

Métrica del lab Antes Después Diferencia
Procesamiento de imagen con contenido más grande (LCP) 2.41 segundos 1.48 segundos −39%
Tiempo de carga (TTI) 12.16 segundos 7.48 segundos −39%
Tiempo de bloqueo total (TBT) 1,124 milésimas de segundo 1,056 milésimas de segundo −4%
Cambio de diseño acumulado (CLS) 0,0402 0.0093 −77%
Resultados de métricas de lab recopilados con SpeedCurve.

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

Gráfico de líneas con valores del LCP que compara la versión nueva con la anterior durante el mes actual y el pasado. La curva de la nueva versión flota entre 2 y 4 segundos, y se mantiene 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 compara la versión nueva con la anterior durante el mes actual y el pasado. La curva de la nueva versión permanece por debajo de los 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 métricas de campo recopilados con Instana.

PageSpeed Insights proporciona un informe de datos de campo de los últimos 28 días. Por sí sola, la página del condominio con mayor acceso 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 "bueno".

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

Durante el lanzamiento progresivo, notamos una disminución en los porcentajes de rebote. Para el momento en que terminamos la versión de todas las páginas, Google Analytics mostraba una disminución del 46% en el porcentaje de rebote, un aumento del 87% en las páginas por sesión y un aumento del 49% en la duración promedio de la sesión. La disminución del porcentaje de rebote fue aún mayor en las búsquedas pagadas, con una disminución del 59%, lo cual es un signo positivo cuando se trata de inversiones en anuncios de pago 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, hay una leve disminución en el porcentaje de rebote. El descenso 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 un recorrido y solicitar alquilar o comprar una propiedad. Mientras se continuaban lanzando las mejoras, nuestro equipo comparó las conversiones de la versión anterior con la nueva. En la misma semana, el grupo de páginas de la nueva versión presentó un aumento del 5% en las conversiones, mientras que las otras páginas tuvieron una leve disminución en la misma métrica.

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

Conclusión

Este proyecto es la primera parte de una iniciativa 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 brindaron comentarios positivos sobre la experiencia mejorada para los desarrolladores. Otros equipos que tuvieron que iniciar nuevas aplicaciones web ya lo hicieron con Next.js. Creemos que Next.js simplificará los esfuerzos de mantenimiento y establecerá un común entre las diferentes apps.

En general, el centro de contenido para condominios ha estado creciendo continuamente en términos de cantidad absoluta de usuarios y transacciones. En el análisis a largo plazo, existen muchos factores que contribuyen a esto, como la expansión de la operación de QuintoAndar y las iniciativas de SEO, como una mejor 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 profundizar en los datos del usuario y crear todo el análisis de conversiones de este caso de éxito.