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.
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.
El 46%
reducción del porcentaje de rebote
87%
aumento de las páginas por sesión
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
Se implementó la versión nueva de la página del condominio 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 el procesamiento del servidor listo para usar y quita la necesidad de una configuración personalizada. Con la documentación, es mucho más fácil 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 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 recuperación anticipada 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 tenía que hacerse 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 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.
Ya se habían implementado otras optimizaciones de JS, como la compresión estática con Brotli, que se realizó durante el tiempo de 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 durante el tiempo de compilación y logramos una reducción del 24%.
Cómo optimizar los recursos de imagen
Hay una imagen principal que ocupa la mayor parte del área de la mitad superior de la página en la versión para dispositivos móviles. También resulta ser el Largest Contentful Paint (LCP) de la página.
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 la 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 el uso de la propiedad de 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.
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:
- 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.
- En la segunda fase, se publicó para más páginas, lo que representa unos miles de usuarios por día.
- 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% |
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%.
PageSpeed Insights proporciona un informe de datos de campo de los últimos 28 días. La página del condominio a la que más se accedió tenía datos suficientes para generar un informe de los usuarios de dispositivos móviles. A partir de noviembre de 2021, todas las Métricas web esenciales se encuentran en el bucket "óptimo".
Durante el lanzamiento progresivo, notamos una disminución en los porcentajes de rebote. Cuando terminamos la versión de todas las páginas, Google Analytics mostró 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 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).
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. Si bien todavía se estaban lanzando 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 nueva versión mostró un aumento de las conversiones del 5%, mientras que las otras páginas tuvieron una leve disminución en la misma métrica.
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 las mejoras en la experiencia de 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 las operaciones de QuintoAndar y las iniciativas de SEO, como la mejora de la 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.