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 considerablemente el porcentaje de rebote en todo el sitio web.
A medida 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. Gracias a la optimizació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.
Cómo medir el impacto
Nos enfocamos en Largest Contentful Paint (LCP) y Cumulative Layout Shift (CLS), ya que son las 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 Experimentos de usuarios 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 segundos a 2.5 segundos.
Además, los valores de LCP en el rango "Deficiente" se redujeron en un 33% entre octubre de 2020 y julio de 2021:
Además, los valores de CLS en el rango "Deficiente" se redujeron en un 65%, y los valores de CLS en el rango "Buena" aumentaron en un 20% en el mismo período:
El resultado fue que The Economic Times, que antes no cumplía con los umbrales de las Métricas web esenciales, ahora superó los umbrales de las Métricas web esenciales en todo su origen y redujo las tasas 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, la LCP informa el tiempo de renderización de la imagen, el texto o la sección de video más grandes que el usuario puede ver.
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 aplicamos para mejorar el LCP.
Primero las solicitudes críticas
Como todos los navegadores modernos limitan la cantidad simultánea de solicitudes, los desarrolladores deben priorizar la carga del contenido fundamental primero. Para cargar una página web compleja, debemos descargar recursos como elementos de encabezado, CSS, recursos de JavaScript, imagen hero, cuerpo del artículo, comentarios, otras noticias relacionadas, pie de página y anuncios. Evaluamos qué elementos eran necesarios 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, cambiamos a font-display: swap;. Esto renderiza el texto inicialmente en la fuente disponible que mejor coincida y, luego, cambia a la fuente cuando se descarga. Esto permitió que nuestro texto se renderizara rápidamente, 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 del servidor de Gzip a Brotli para lograr un espacio más reducido:
- 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 con Gzip.
Cómo establecer una conexión previa a dominios de terceros
preconnect se debe usar con cuidado, ya que puede ocupar tiempo valioso de la CPU y retrasar otros recursos importantes, especialmente en conexiones seguras.
Sin embargo, si se sabe que se realizará una recuperación de un recurso en un dominio de terceros, preconnect es una buena opción. Si solo ocurre ocasionalmente en un sitio web con mucho tráfico, preconnect podría activar un trabajo innecesario de TCP y TLS. Por lo tanto, dns-prefetch era más adecuado para que los recursos de terceros (por ejemplo, redes sociales, estadísticas, etc.) realizaran búsquedas de DNS con anticipación.
Divide el código en fragmentos
En el encabezado del sitio, solo cargamos los recursos que contienen una parte esencial de la lógica empresarial o que eran críticos para la renderización de la página en 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 acceso del 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 de la 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, se redujo a 2.5 segundos.
¿Qué es CLS y cómo lo mejoramos?
¿Alguna vez notaste algún movimiento inesperado del contenido de una página mientras navegabas por un sitio web? Una de las causas de esto es la carga asíncrona de contenido multimedia (imágenes, videos, anuncios, etcétera) en la página con dimensiones desconocidas. En cuanto se cargan los recursos multimedia, cambian el diseño de la página.
A continuación, analizaremos las medidas que tomamos para mejorar el CLS en el sitio web de The Economic Times.
Usa marcadores de posición
Usamos un marcador de posición con diseño para unidades de anuncios y elementos multimedia de dimensiones conocidas para evitar cambios de diseño cuando la biblioteca de anuncios carga y renderiza anuncios de página. Esto garantiza que se eliminen los cambios de diseño reservando espacio para el anuncio.
Dimensiones del contenedor definidas
Especificamos dimensiones explícitas para todas las imágenes y contenedores para que el motor del navegador no tenga que calcular el ancho y la altura de los elementos 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 la 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.
¿Qué es el retraso de primera entrada (FID) y cómo lo mejoramos?
El retraso de primera entrada es la métrica que realiza un seguimiento de la capacidad de respuesta de un sitio web a las entradas del usuario. La causa principal de una puntuación de FID baja es un trabajo intensivo de JavaScript que mantiene ocupado el subproceso principal del navegador, lo que puede retrasar las interacciones del usuario. Mejoramos el FID de varias maneras.
Cómo dividir tareas largas de JavaScript
Las tareas largas son aquellas que 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 siempre que fue posible a pedido del usuario, lo que ayudó a reducir el aumento excesivo de JavaScript.
Aplaza el código JavaScript sin usar
Priorizamos el contenido de la página 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 hacer un seguimiento preciso del recorrido del usuario.
Reduce los polyfills
Reducción de la dependencia de ciertos polyfills y bibliotecas, ya que los navegadores admiten APIs modernas y menos usuarios usan navegadores heredados, como Internet Explorer
Anuncios de carga diferida
La carga diferida de anuncios en la mitad inferior de la página ayudó a reducir el tiempo de bloqueo del subproceso principal y, por lo tanto, mejoró el FID.
Resumen de los objetivos y logros de la FID
A partir de experimentos de rutina, pudimos reducir nuestro FID de 200 ms a menos de 50 ms en la actualidad.
Evita las regresiones
Economics Times planea implementar verificaciones de rendimiento automatizadas en producción para evitar regresiones en el rendimiento de la página. Planean evaluar Lighthouse-CI para automatizar las pruebas de lab, lo que puede evitar regresiones en su rama de producción.