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 de Cambio de diseño acumulado (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%.
Donde comenzamos
Mail.ru es uno de los principales servicios de correo electrónico en la Internet de habla rusa y se encuentra entre los 5 sitios principales 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, rendimiento de búsquedas en Internet y más.
Mail.ru quería brindar a sus visitantes una experiencia de usuario de alta calidad, por lo que el trabajo comenzó a mejorar las Métricas web esenciales. Antes de analizar nuestra estrategia de optimización, debes tener en cuenta algunos detalles técnicos de la página principal de Mail.ru.
Si bien el proyecto se desarrolló durante mucho tiempo con nuestro motor de plantillas interno Fest, en 2019 comenzamos a migrar a Svelte 3.
Svelte implementa la reactividad de una manera que no usa un DOM virtual, lo que hace que requiera menos 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 las funciones. Durante la compilación, se quita el código que no se usa, 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.
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, realizamos un seguimiento de otras métricas, como First Contentful Paint (FCP), en nuestro panel de rendimiento interno.
Se modificó nuestra secuencia de comandos de recopilación de métricas para recopilar Métricas web esenciales y transmitirlas a nuestro panel de rendimiento para su visualización. Conforme a las recomendaciones de Google, nuestra secuencia de comandos usa la API de PerformanceObserver para obtener métricas, que son parte del frontend universal "Platform" dentro de Mail.ru.
El panel mostraba las siguientes métricas para los usuarios (valores medios para 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 | Por confirmar | TTI | |
| Porcentaje de usuarios de acuerdo con los umbrales de las Métricas web esenciales | good | 52% | 92% | 33% | 35% | 42% | 43% |
| necesita mejorar | 19% | 5% | 23% | 38% | 16% | 25% | |
| débil | 29% | 3% | 44% | 27% | 42% | 32% | |
Mejora las Métricas web esenciales
Si bien existe mucha orientación para mejorar las Métricas web esenciales, cada proyecto tiene desafíos únicos. Para la página principal de Mail.ru, se identificaron las siguientes oportunidades:
- Implementar marcadores de posición para banners de anuncios a fin de reducir el CLS
- Usar la renderización del servidor (SSR) para reducir el Largest Contentful Paint (LCP).
- División de código para reducir el LCP y el retraso de primera entrada (FID).
Esqueletos para mejorar CLS
CLS fue una de las métricas de campo con peor rendimiento para 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 causa del problema. Para mejorar la estabilidad del diseño, nuestro equipo decidió usar marcadores de posición a fin de 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á. Afortunadamente, la versión para computadoras de escritorio 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 utilizaron 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, reescribemos progresivamente el proyecto existente en lugar de volver a empezar. En marzo de 2021, habíamos migrado la mayor parte del frontend a Svelte y, con el tiempo, llevamos SSR a nuestra aplicación de producción después de clasificar y corregir 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 había insertado al momento de procesar el primer contenido en la página. Hubo un retraso entre la pintura inicial del lenguaje de marcado de la página que proporcionó el servidor y la inserción de la sección de noticias en el cliente. Este comportamiento generó un cambio en la estructura de los anuncios, lo que empeoró la métrica CLS.
Aunque las Herramientas para desarrolladores de Chrome mostraron eventos de Cambio de diseño, al principio no pudimos encontrar el motivo. Si bien la SSR en sí no era el problema, ayudó a descubrir la solución más adelante. Al corregir el código responsable del retraso de la pintura, se mejoró la estabilidad del diseño del componente de noticias.
Otro efecto que la SSR puede tener en el CLS es el movimiento de los componentes antes y después de la hidratación, lo que puede conducir a 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 lenguaje de marcado de componentes hidratados. Una buena solución a este problema era transferir tanta lógica de visualización de JavaScript a CSS cuando fuera posible.
División de código y polyfills sin usar
Para mejorar la velocidad de carga de las páginas percibidas, se requirió trabajo reducir los valores de LCP y FID. Una forma de lograrlo es a través de 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á incorporada en muchos de los proyectos de nuestra empresa.
Por razones históricas, el widget se inserta al comienzo de la página como una secuencia de comandos de carga síncrona. La proporción de polyfills en este guion creció con el tiempo. Para limitar los efectos negativos de rendimiento de cargar estos polyfills, implementamos la división de código para navegadores modernos y heredados.
Decidimos utilizar 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 orientó a navegadores lo suficientemente modernos para nuestras necesidades. Para abordar esto, Mail.ru usa una herramienta interna que identifica las versiones modernas del navegador en el backend y puede adaptarse a estos navegadores en consecuencia.
Una vez que se identificaron los navegadores en el backend, implementamos la división de código para los navegadores modernos y heredados. Como resultado, se logró una reducción del 43.3% en el tamaño del widget de JavaScript cargado de forma síncrona para los navegadores modernos. Esta práctica también se aplicó a otras secuencias de comandos del portal.
Además de la reducción del tamaño del paquete y los efectos positivos en las Métricas web esenciales, la división del código también mejora la experiencia de los desarrolladores. Solo el 3.5% de nuestros usuarios usa navegadores heredados, y ese porcentaje tiene una tendencia a la baja, por lo que implementar la división de código permitió a nuestros desarrolladores usar las API de navegador más recientes sin que todos los usuarios pudieran acceder al sobredimensionamiento de polyfills que necesitan los navegadores heredados.
Resultados
Después del esfuerzo de optimización, observamos los valores medios para 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 | Por confirmar | TTI | |
| Porcentaje de usuarios de acuerdo con los umbrales de las Métricas web esenciales | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| necesita mejorar | 18% | 4% | 3% | 34% | 17% | 24% | |
| débil | 24% | 3% | 4% | 23% | 34% | 25% | |
En los gráficos que aparecen a continuación, 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: Se lanzó la iteración con las últimas secciones de página migradas a Svelte.
- 19 de abril de 2021: Lanzamiento de la iteración con SSR mostrado y diseño modificado para corregir las regresiones de CLS
La disminución en los valores del 1 al 10 de mayo se debe a los feriados de mayo en Rusia.
Los resultados obtenidos con la "Plataforma" están en línea 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 de usuario una semana antes del lanzamiento de las mejoras iniciales y una semana después del lanzamiento muestra un crecimiento del 2.7%. Además, hay un aumento general significativo en las conversiones en la mayoría de las secciones de la página. En particular, las conversiones a la aplicación de correo electrónico Mail.ru aumentaron un 11,6%, y la conversión de la sección de noticias aumentó en un 13,5%.
El 181%
Aumento del porcentaje de buen umbral de CLS
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 las etiquetas de precarga).
Después de analizar el resto de las secciones de la página, notamos una mejora significativa en el rendimiento en la gran mayoría de ellas. Incluso en secciones como Clima y Coronavirus, que no son fundamentales en nuestra página, observamos un aumento en las conversiones del 9.6% y 9.5%, respectivamente.
Conclusión
Mejorar el rendimiento es un desafío porque el trabajo involucrado puede ser prolongado. A lo largo del tiempo, debes supervisar los cambios en las métricas con regularidad y asegurarte de que 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 de nuestro presupuesto de rendimiento.
Lo más importante es que hacemos hincapié en la importancia de las Métricas web esenciales para todos los miembros de nuestro equipo de productos, desde gerentes y diseñadores hasta verificadores y QA. Cada miembro del equipo debe conocer las métricas de rendimiento y tener la posibilidad de mejorarlas. También incorporamos objetivos de optimización del rendimiento en nuestros procesos empresariales con regularidad. Proporcionar con éxito una experiencia del usuario de alta calidad solo es posible a través de un esfuerzo conjunto de todos los miembros del equipo.