La optimización de las Métricas web esenciales en el sitio web de The Economic Times mejoró significativamente la experiencia del usuario y redujo significativamente el porcentaje de rebote en todo el sitio web.
Debido a que las velocidades de Internet mejoran día a día, los usuarios esperan que los sitios web respondan y se comporten más rápido que nunca. The Economic Times administra más de 45 millones de usuarios activos por mes. Con la optimización en función de las Métricas web esenciales en todo el dominio, en páginas de AMP y que no son de AMP, logramos reducir significativamente los porcentajes de rebote y mejorar la experiencia de lectura.
Medición del impacto
Nos enfocamos en el Largest Contentful Paint (LCP) y el Cambio de diseño acumulado (CLS), ya que son los más importantes a la hora de proporcionar una excelente experiencia de lectura a nuestros usuarios. Después de implementar varias correcciones de rendimiento como se describe a continuación, The Economic Times logró mejorar significativamente las métricas del informe de los experimentos de usuario de Chrome (CrUX) en pocos meses.
En general, el CLS mejoró un 250%, de 0.25 a 0.09. En general, el LCP mejoró un 80%, de 4.5 a 2.5 segundos.
Además, los valores de LCP en el rango "Lentas" se redujeron en un 33% entre octubre de 2020 y julio de 2021:
![Distribuciones de LCP agrupadas por mes, desde octubre de 2020 hasta julio de 2021 La cantidad de valores de LCP clasificados como "Lentas" se redujo del 15.03% al 10.08%.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/lcp-distributions-grouped-1665cedb8a1c1.png?authuser=5&hl=es)
Además, los valores de CLS en el rango "Lentas" se redujeron en un 65% y los valores de CLS en el rango "Bueno" aumentaron un 20% en el mismo período:
![Distribuciones de CLS agrupadas por mes, desde octubre de 2020 hasta julio de 2021. La cantidad de valores de CLS clasificados como "Deficiente" se redujo del 25.92% al 9%, y la cantidad de los valores de CLS clasificados como "Bueno" aumentó del 62.62% al 76.5%.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/cls-distributions-grouped-8c9f113c949f8.png?authuser=5&hl=es)
Como resultado, The Economic Times, que antes no cumplía con los umbrales de las Métricas web esenciales, ahora lo superó en todo su origen y redujo los porcentajes de rebote en un 43% en general.
¿Qué es el LCP y cómo lo mejoramos?
El elemento más grande es el más relevante para mejorar la experiencia del usuario y reconocer la velocidad de carga. Las métricas de rendimiento, como el Primer procesamiento de imagen con contenido (FCP), solo capturan la experiencia inicial de carga de la página. Por otro lado, LCP informa el tiempo de renderización de la sección de imágenes, texto o video de mayor tamaño visible para el usuario.
Además de cambiar a un proveedor de DNS más rápido y optimizar las imágenes, estas son algunas de las técnicas que abordamos para mejorar el LCP.
Primero, las solicitudes críticas
Como todos los navegadores modernos limitan la cantidad de solicitudes simultáneas, los desarrolladores deben priorizar primero la carga del contenido crítico. Para cargar una página web compleja, debemos descargar recursos como los elementos de encabezado, CSS, recursos de JavaScript, hero image, el cuerpo del artículo, los comentarios, otras noticias relacionadas, el pie de página y los anuncios. Evaluamos qué elementos se requerían para el LCP y proporcionamos la preferencia de cargar esos elementos primero para mejorar el LCP. También aplazamos las llamadas que no formaban parte de la renderización inicial de la página.
Apariencia del texto
Experimentamos con la propiedad font-display
, ya que afecta tanto al LCP como al CLS. Probamos font-display: auto;
y, luego, lo cambiamos a font-display: swap;
. De esta forma, el texto inicialmente se mostrará en la mejor fuente coincidente y disponible y, luego, cambiará a la fuente cuando se haya descargado. Como resultado, nuestro texto se renderizaba con rapidez, independientemente de la velocidad de la red.
Mejor compresión
Brotli es un algoritmo de compresión alternativo a Gzip y Deflate desarrollado por Google. Reemplazamos nuestras fuentes y recursos, y cambiamos la compresión de servidores de Gzip a Brotli para reducir el tamaño:
- Los archivos JavaScript son un 15% más pequeños que con Gzip.
- Los archivos HTML son un 18% más pequeños que con Gzip.
- Los archivos CSS y de fuentes son un 17% más pequeños que los de Gzip.
Establece una conexión previa con dominios de terceros
preconnect
debe usarse con cuidado, ya que aún puede consumir tiempo de CPU valioso y retrasar otros recursos importantes, especialmente en conexiones seguras.
Sin embargo, si se sabe que se realizará la recuperación de un recurso en un dominio de terceros, preconnect
es adecuado. Si solo sucede ocasionalmente en un sitio web con mucho tráfico, preconnect
podría activar trabajos innecesarios de TCP y TLS. Por lo tanto, dns-prefetch
era una mejor opción para recursos de terceros, como redes sociales, estadísticas, etc., para realizar búsquedas de DNS con anticipación.
Dividir el código en bloques
En el encabezado del sitio, solo cargamos los recursos que contenían una parte esencial de la lógica empresarial o eran críticos para la renderización de la página de la mitad superior de la página. Además, dividimos nuestro código en fragmentos con la división de código. Esto nos ayudó a mejorar aún más el LCP de la página.
Mejor almacenamiento en caché
Para todas las rutas de frontend, agregamos una capa de Redis que entregaba plantillas desde la caché. Esto reduce el tiempo de procesamiento en el servidor y compila toda la IU en cada solicitud, lo que disminuye el LCP en las solicitudes posteriores.
Resumen de los objetivos y logros del LCP
Antes de comenzar el proyecto de optimización, el equipo comparó su puntuación de LCP en 4.5 segundos (para el percentil 75 de sus usuarios, según los datos de campo del informe de CrUX). Después del proyecto de optimización, el tiempo se redujo a 2.5 segundos.
![Distribuciones de LCP desde septiembre de 2020 hasta junio de 2021. En general, el percentil 75 de los valores de LCP observado en el informe sobre la experiencia del usuario en Chrome mostró una reducción del 8.97% en los valores de LCP "Lentas". La disminución general del tiempo de LCP en el percentil 75 fue de 200 milisegundos, con un 77.63% de los valores de LCP que se encontraban en el intervalo “Bueno”.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/lcp-distributions-septem-dba1967fe2b85.png?authuser=5&hl=es)
¿Qué es CLS y cómo lo mejoramos?
¿Alguna vez has notado algún movimiento inesperado del contenido de la página mientras navegabas en un sitio web? Una de las causas es la carga asíncrona de medios (imágenes, videos, anuncios, etc.) en la página con dimensiones desconocidas. Tan pronto como se cargan los recursos multimedia, cambian el diseño de la página.
Hablaremos sobre las medidas que tomamos para mejorar CLS en el sitio web de The Economic Times.
Cómo usar marcadores de posición
Utilizamos un marcador de posición con estilo para unidades de anuncios y elementos multimedia de dimensiones conocidas a fin de evitar los cambios de diseño cuando la biblioteca de anuncios carga y renderiza anuncios de páginas. Esto garantiza que se eliminen los cambios de diseño al reservar espacio para el anuncio.
![Comparación en paralelo del sitio web de The Economic Times en un teléfono celular. A la izquierda, hay un marcador de posición gris reservado para la hero image del artículo. A la derecha, el marcador de posición se reemplaza por la imagen cargada.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/a-side-side-comparison-7fa833805779e.jpg?authuser=5&hl=es)
Dimensiones definidas del contenedor
Especificamos dimensiones explícitas para todas las imágenes y los contenedores de modo que el motor del navegador no necesite calcular el ancho y la altura de los elementos del DOM una vez que estén disponibles. Esto evitó cambios de diseño innecesarios y trabajo de pintura adicional.
Resumen de los objetivos y logros de CLS
Antes de comenzar el proyecto de optimización, el equipo comparó su puntuación de CLS en 0.25. Pudimos reducirlo significativamente en un 90% a 0.09.
![Las distribuciones de CLS se muestran en el Informe sobre la experiencia del usuario en Chrome. El 76% de los valores de CLS son "Bueno", el 15% son "Regulares" y el 9% son "Deficientes". El percentil 75 de experiencias del usuario en el sitio web de The Economic Times en general experimentó un CLS de 0.09.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/cls-distributions-shown-24bb04e5f1222.png?authuser=5&hl=es)
¿Qué es el retraso de primera entrada (FID) y cómo lo mejoramos?
El retraso de primera entrada es la métrica que hace un seguimiento de la capacidad de respuesta de un sitio web ante las entradas del usuario. La causa principal de una puntuación FID deficiente es el gran trabajo de JavaScript que mantiene ocupado el subproceso principal del navegador, lo que puede retrasar las interacciones del usuario. Mejoramos el FID de varias maneras.
Divide las tareas largas de JavaScript
Las tareas largas duran 50 milisegundos o más. Las tareas largas ocupan el subproceso principal del navegador y evitan que responda a las entradas del usuario. Dividimos las tareas de larga duración en tareas más pequeñas cuando era posible a pedido del usuario, lo que ayudó a reducir el sobredimensionamiento de JavaScript.
![Tiempo de CPU desglosado por tipo de actividad en el panel de rendimiento de las Herramientas para desarrolladores de Chrome Se dedicaron 143 milisegundos a la programación de la carga de recursos. JavaScript se dedicó 4,553 milisegundos. Se dedicaron 961 milisegundos al trabajo de renderización. Se dedicaron 191 milisegundos a las operaciones de pintura. 1,488 milisegundos en tareas del sistema con 3,877 milisegundos de tiempo de inactividad. El período total fue de 11,212 milisegundos.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/cpu-broken-down-activit-755810742b7d6.png?authuser=5&hl=es)
Aplaza el código JavaScript sin usar
Priorizamos el contenido de la página por sobre las secuencias de comandos de terceros, como las estadísticas, para que la página sea más responsiva. Sin embargo, existen ciertas limitaciones en algunas bibliotecas, ya que deben cargarse en el documento <head>
para realizar un seguimiento preciso del recorrido del usuario.
Reduce los polyfills
Redujimos nuestra dependencia de ciertos polyfills y bibliotecas, ya que los navegadores admiten API modernas y menos usuarios usan navegadores heredados, como Internet Explorer.
Anuncios de carga diferida
La carga diferida de los anuncios en la mitad inferior de la página ayudó a reducir el tiempo de bloqueo en los subprocesos principales y, por lo tanto, mejorar el FID.
Resumen de los objetivos y logros de FID
En la actualidad, a partir de los experimentos de rutina, pudimos reducir nuestro FID de 200 ms a menos de 50 ms.
![Distribuciones de FID que se muestran en el Informe sobre la experiencia del usuario en Chrome. El 86% de los valores de CLS son "Bueno", el 10% son "Regulares" y el 4% son "Deficientes". En general, el percentil 75 de experiencias del usuario en el sitio web de The Economic Times tuvo un FID de 44 milisegundos.](https://web.developers.google.cn/static/case-studies/economic-times-cwv/image/fid-distributions-shown-aef0cbd6725b6.png?authuser=5&hl=es)
Prevención de regresiones
The Economics Times planea introducir verificaciones de rendimiento automatizadas en la producción para evitar regresiones de rendimiento de la página. Planean evaluar Lighthouse-CI para automatizar las pruebas de laboratorio, lo que puede prevenir regresiones en su rama de producción.