Varios meses de trabajo para mejorar las métricas web esenciales en la página principal de Mail.ru generaron un aumento del 60% en el percentil 75 en el cambio de diseño acumulativo (CLS), lo que aumentó el tiempo de sesión promedio en un 2.7% y los porcentajes de conversiones de las secciones principales en más del 10%.
Dónde comenzamos
Mail.ru es uno de los servicios de correo electrónico líderes en la Internet de habla rusa y se encuentra entre los 5 principales sitios de Rusia en términos de tráfico. Mail.ru es un recurso importante para muchas personas. Recibe cientos de millones de visitas por mes y es un portal desde el que las personas pueden acceder a correos electrónicos, noticias, redes sociales, búsquedas de Internet de alto rendimiento y mucho más.
Mail.ru quería brindar a sus visitantes una experiencia del usuario de alta calidad, por lo que comenzó a trabajar para mejorar las métricas web esenciales. Antes de analizar nuestra estrategia de optimización, debemos tener en cuenta algunos detalles técnicos de la página principal de Mail.ru.
Aunque el proyecto se había desarrollado durante mucho tiempo con nuestro motor de plantillas interno Fest, comenzamos a migrar a Svelte 3 en 2019.
Svelte implementa la reactividad de una manera que no usa el DOM virtual, lo que lo hace menos intensivo en recursos. El enfoque de Svelte quita las funciones que no se usan de los paquetes de producción porque el compilador no genera el código que las implementa si no se usan. El código que no se usa se quita durante la compilación, lo que genera paquetes más pequeños. Esto puede ayudar a reducir el tiempo de bloqueo total (TBT) durante el inicio de la página.
Realiza un seguimiento de las métricas de rendimiento
Antes de optimizar las métricas web esenciales, es útil evaluar el rendimiento en el campo. Antes de las métricas web esenciales, hacíamos un seguimiento de otras métricas, como el primer procesamiento de imagen con contenido (FCP), en nuestro panel de rendimiento interno.
Se modificó nuestra secuencia de comandos de recopilación de métricas para recopilar las métricas web esenciales y transmitirlas a nuestro panel de rendimiento para su visualización. De acuerdo con las recomendaciones de Google, nuestra secuencia de comandos usa la API de PerformanceObserver para obtener métricas, que forma parte de la "plataforma" del frontend universal dentro de Mail.ru.
El panel mostró las siguientes métricas para los usuarios (valores promedio de la semana del 15 al 21 de marzo de 2021):
| Nombre del grupo de métricas | Métricas web esenciales | Otras métricas web | |||||
|---|---|---|---|---|---|---|---|
| Nombre de la métrica | LCP | FID | CLS | FCP | TBT | TTI | |
| Porcentaje de usuarios según los umbrales de las Métricas web esenciales | bueno | 52% | 92% | 33% | 35% | 42% | 43% |
| needs-improvement | 19% | 5% | 23% | 38% | 16% | 25% | |
| deficiente | 29% | 3% | 44% | 27% | 42% | 32% | |
Cómo mejorar las métricas web esenciales
Si bien existe mucha orientación para mejorar las Métricas web esenciales, cada proyecto tiene desafíos únicos. En el caso de la página principal de Mail.ru, se identificaron las siguientes oportunidades:
- Implementa marcadores de posición para los banners de anuncios para reducir el CLS.
- Usar la renderización del servidor (SSR) para reducir el procesamiento de imagen con contenido más grande (LCP)
- División de código para reducir el LCP y el retraso de primera entrada (FID)
Esqueletos para mejorar el CLS
El CLS fue una de las métricas de campo con el peor rendimiento en la página principal de Mail.ru. El perfil posterior de esta página en el panel Rendimiento de las Herramientas para desarrolladores de Chrome reveló que los anuncios eran la fuente del problema. Para mejorar la estabilidad del diseño, nuestro equipo decidió usar marcadores de posición para reservar espacio para los anuncios antes de que se carguen.
Cuando implementes marcadores de posición, el primer paso es determinar las dimensiones del contenido que los reemplazará. Por suerte, la versión para computadoras de la página principal de Mail.ru tiene tamaños de anuncios estrictamente documentados. Después de hablar con el equipo de diseño, se usaron esqueletos de IU animados con SVG como marcadores de posición, ya que reducen el tiempo de carga percibido del contenido.
El regreso de SSR
Para facilitar la transición de Fest a Svelte, reescribimos de forma incremental el proyecto existente en lugar de comenzar de nuevo. En marzo de 2021, migramos la mayor parte del frontend a Svelte y, finalmente, llevamos el SSR a nuestra aplicación de producción después de clasificar y corregir los problemas de rendimiento del backend.
Después de implementar el SSR, el equipo descubrió la causa de la regresión de CLS que inicialmente pasó desapercibida: la sección de noticias no se insertaba en el momento de renderizar el primer contenido de la página. Hubo un retraso entre la pintura inicial del marcado de página que proporcionó el servidor y la inserción de la sección de noticias en el cliente. Este comportamiento provocó un cambio en el esqueleto del anuncio, lo que empeoró el CLS.
Aunque las herramientas para desarrolladores de Chrome mostraban eventos de cambio de diseño, no pudimos encontrar el motivo al principio. Aunque el SSR no era el problema, ayudó a descubrir la solución más adelante. Se corrigió el código responsable del retraso en la pintura, lo que mejoró la estabilidad del diseño del componente de noticias.
Otro efecto que el SSR puede tener en el CLS es el movimiento de los componentes antes y después de la hidratación, lo que puede provocar más cambios de diseño. Encontramos este problema en la versión para dispositivos móviles en particular, y requirió prestar especial atención al marcado de componentes hidratados. Una buena solución a este problema fue transferir la mayor cantidad posible de lógica de visualización de JavaScript a CSS.
División de código y polyfills sin usar
Para mejorar la velocidad de carga percibida de la página, se requirió trabajar para disminuir los valores de LCP y FID. Una forma de lograrlo es mediante la división de código. Además de la página principal de Mail.ru, nuestro equipo está desarrollando un widget para la navegación del portal. Actualmente, está incorporado en muchos de los proyectos de nuestra empresa.
Por motivos históricos, el widget se inserta al principio de la página como una secuencia de comandos de carga síncrona. La proporción de polyfills en esta secuencia de comandos aumentó con el tiempo. Para limitar los efectos negativos en el rendimiento de la carga de estos polyfills, implementamos la división de código para navegadores modernos y heredados.
Decidimos no usar el patrón module/nomodule para cargar paquetes de JavaScript para navegadores modernos o heredados, ya que el atributo type="module" del elemento <script> no se segmentaba para navegadores lo suficientemente modernos para nuestras necesidades. Para abordar este problema, Mail.ru usa una herramienta interna para identificar las versiones modernas de navegadores en el backend y puede adaptarse a esos navegadores según corresponda.
Una vez que se pudieron identificar los navegadores en el backend, implementamos la división de código para navegadores modernos y heredados. El resultado fue una reducción del 43.3% en el tamaño del widget de JavaScript cargado de forma síncrona para navegadores modernos. Esta práctica también se aplicó a algunas otras secuencias de comandos del portal.
Además de reducir el tamaño del paquete y tener efectos positivos en las métricas web esenciales, la división de código también mejora la experiencia del desarrollador. Solo el 3.5% de nuestros usuarios usan navegadores heredados, y esa proporción tiene una tendencia a la baja, por lo que la implementación de la división de código permitió que nuestros desarrolladores usaran las APIs de navegador más recientes sin introducir el aumento de tamaño de polyfill necesario para los navegadores heredados para todos los usuarios.
Resultados
Después del esfuerzo de optimización, observamos los valores promedio de la semana del 24 al 30 de mayo de 2021 en nuestros datos de campo:
| Nombre del grupo de métricas | Métricas web esenciales | Otras métricas web | |||||
|---|---|---|---|---|---|---|---|
| Nombre de la métrica | LCP | FID | CLS | FCP | TBT | TTI | |
| Porcentaje de usuarios según los umbrales de las Métricas web esenciales | bueno | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 18% | 4% | 3% | 34% | 17% | 24% | |
| deficiente | 24% | 3% | 4% | 23% | 34% | 25% | |
En los siguientes gráficos, se muestran los cambios en los valores de las métricas de rendimiento de las páginas web según la "Plataforma". Observa las dos fechas importantes en los gráficos:
- 23 de marzo de 2021: Lanzamiento de la iteración con las secciones de la última página migradas a Svelte.
- 19 de abril de 2021: Lanzamiento de la iteración con SSR devuelto y diseño modificado para corregir las regresiones de CLS.
La disminución de los valores del 1 al 10 de mayo se debe a los feriados de mayo en Rusia.
Los resultados obtenidos con "Plataforma" están alineados con el crecimiento de los valores de las métricas en el Informe de UX de Chrome (CrUX).
Una comparación de los valores promedio de la duración de la sesión del usuario una semana antes del lanzamiento de las mejoras iniciales y una semana después muestra un crecimiento del 2.7%. Además, hay un aumento significativo general en la conversión en la mayoría de las secciones de la página. En particular, las conversiones a la app de correo electrónico Mail.ru aumentaron un 11.6%, y las conversiones de la sección de noticias aumentaron un 13.5%.
181%
Aumento del umbral de porcentaje de CLS bueno
2.7%
Mayor duración promedio de la sesión
13.5%
Aumento del porcentaje de conversiones de la sección de noticias
El resultado más inesperado que obtuvimos fue un aumento del 17.4% en la tasa de clics (CTR) del banner de marketing (su tiempo de renderización se redujo significativamente con la introducción de SSR y etiquetas de carga previa).
Después de analizar el resto de las secciones de la página, notamos una mejora significativa en el rendimiento de la gran mayoría de ellas. Incluso en secciones como Clima y Coronavirus, que no son clave en nuestra página, observamos un aumento de las conversiones del 9.6% y el 9.5%, respectivamente.
Conclusión
Mejorar el rendimiento es un desafío, ya que el trabajo involucrado puede prolongarse. Debes supervisar periódicamente los cambios en las métricas a lo largo del tiempo y asegurarte de que todas las funciones nuevas del producto no causen regresiones en las métricas web esenciales. Para lograrlo, supervisamos los cambios en las Métricas web esenciales en nuestro presupuesto de rendimiento.
Lo más importante es que enfatizamos la importancia de las métricas web esenciales a todos los miembros de nuestro equipo de productos, desde los gerentes y diseñadores hasta los verificadores y el control de calidad. Cada miembro del equipo debe conocer las métricas de rendimiento y tener la capacidad de mejorarlas. También incorporamos objetivos de optimización del rendimiento en nuestros procesos comerciales con una cadencia regular. Proporcionar con éxito una experiencia del usuario de alta calidad solo es posible mediante un esfuerzo conjunto de todos los miembros del equipo.