Al reducir la TBT en 30 veces y migrar a Next.js, The Ecomonic Times redujo el INP casi cuatro veces, lo que generó una disminución del 50% en el porcentaje de rebote y un aumento del 43% en las vistas de página.
Interaction to Next Paint (INP) es una métrica que evalúa la capacidad de respuesta de un sitio web ante la entrada del usuario. Una buena capacidad de respuesta significa que una página responde rápidamente a las interacciones del usuario. Cuanto más bajo sea el INP de una página, mejor podrá responder a las interacciones del usuario.
El comienzo confuso
Cuando Google introdujo por primera vez INP como una métrica experimental con el potencial de evolucionar en una de las Métricas web esenciales, el equipo de Economic Times aceptó el desafío antes de que pasara a ser una, ya que proporcionar una experiencia del usuario de primer nivel es crucial para nuestros valores fundamentales de la empresa.
El INP ha sido una de las métricas más difíciles de resolver hasta ahora. Al principio, no era claro cómo medir eficazmente el INP. Lo que dificultó aún más la situación fue la falta de asistencia de la comunidad, incluidos la mayoría de los proveedores de supervisión de usuarios reales (RUM) que aún no lo admitían. Sin embargo, contábamos con herramientas de RUM de Google, como el Informe sobre la experiencia del usuario en Chrome (CrUX) y la biblioteca JavaScript de web-vitals, entre otras herramientas, lo que nos dio una idea de dónde nos ocupamos mientras evaluábamos el camino por delante. Cuando comenzamos, nuestro INP tardaba cerca de 1,000 milisegundos en el nivel del origen.
Algo que surgió mientras se corrige el INP en el campo fue que una de las métricas del lab para segmentar podría ser Tiempo de bloqueo total (TBT). TBT ya estaba bien documentado y con el apoyo de la comunidad. A pesar de que ya cumplimos con los umbrales de las Métricas web esenciales, no nos fuimos tan bien en el frente de TBT, ya que, cuando comenzamos, tardamos más de 3 segundos.
¿Qué es la TBT y qué pasos seguimos para mejorarla?
La TBT es una métrica de lab que mide la capacidad de respuesta de una página web a la entrada del usuario cuando se carga. Cualquier tarea que tarde más de 50 milisegundos en ejecutarse se considera una tarea larga y el tiempo después del umbral de 50 milisegundos se conoce como tiempo de bloqueo.
Para calcular la TB, se suman los tiempos de bloqueo de todas las tareas largas durante la carga de la página. Por ejemplo, si hay dos tareas largas durante la carga, el tiempo de bloqueo se determina de la siguiente manera:
- La tarea A tarda 80 milisegundos (30 milisegundos más de 50 milisegundos).
- La tarea B tarda 100 milisegundos (50 milisegundos más que 50 milisegundos).
La TBT de la página será de 80 milisegundos (30 + 50). Cuanto menor sea la TBT, mejor. La TBT también se correlaciona bien con el INP.
A continuación, te mostramos una comparación de lab rápida de nuestra TBT antes y después de implementar medidas para mejorarla:
Minimiza el trabajo del subproceso principal
El subproceso principal del navegador controla todo, desde el análisis de HTML y la creación del DOM hasta el análisis de CSS y la aplicación de estilos, y la evaluación y ejecución de JavaScript. El subproceso principal también controla las interacciones del usuario, es decir, hacer clic, presionar y presionar teclas. Si el subproceso principal está ocupado con otras tareas, es posible que no responda de manera eficiente a las entradas del usuario y genere bloqueos en la experiencia del usuario.
Esta fue la tarea más difícil para nosotros, ya que tenemos nuestros propios algoritmos para detectar la identidad de los usuarios y publicar anuncios en función del estado de la suscripción y de las secuencias de comandos de terceros para pruebas A/B, estadísticas y mucho más.
Al principio, dimos pequeños pasos, como reducir la prioridad de la carga de recursos comerciales menos críticos. En segundo lugar, usamos requestIdleCallback para el trabajo no crítico, lo que puede ayudar a reducir la TBT.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
Se recomienda especificar un tiempo de espera cuando se usa requestIdleCallback, ya que garantiza que, si transcurrió el tiempo especificado y si aún no se llamó a la devolución de llamada, se ejecute inmediatamente después del tiempo de espera.
Minimiza el tiempo de evaluación de la secuencia de comandos
También cargamos de forma diferida bibliotecas de terceros con componentes cargables. También quitamos los elementos JavaScript y CSS sin usar. Para ello, generamos perfiles de la página con la herramienta de cobertura en las Herramientas para desarrolladores de Chrome. Nos ayudó a identificar áreas en las que se necesitaba la eliminación de código no utilizado para enviar menos código durante la carga de la página y, por lo tanto, reducir el tamaño inicial del paquete de la aplicación.
Reduce el tamaño del DOM
Según Lighthouse, los tamaños grandes del DOM aumentan el uso de memoria, provoca recálculos de estilo más largos y produce reprocesamientos de diseño costosos.
Redujimos la cantidad de nodos del DOM de dos maneras:
- Primero, renderizamos nuestros elementos de menú a pedido del usuario (al hacer clic). Disminuyó el tamaño del DOM en aproximadamente 1,200 nodos.
- En segundo lugar, cargamos de forma diferida widgets menos importantes.
Debido a todos estos esfuerzos, redujimos la TBT de manera significativa, y nuestro INP también se redujo en casi un 50%:
En este punto, casi nos quedamos sin victorias sencillas para reducir aún más el TBT (y el INP por proxy), pero sabíamos que teníamos mucho margen para mejorar. Fue entonces cuando decidimos actualizar nuestro código estándar de IU personalizada a la versión más reciente de React junto con Next.js para aprovechar mejor los hooks y evitar la repetición innecesaria de componentes.
Debido a actualizaciones más frecuentes y un tráfico comparativamente menor en comparación con otras partes del sitio web, comenzamos a migrar nuestras páginas de temas a Next.js. También usamos PartyTown para transferir a los trabajadores web más trabajo pesado del subproceso principal, junto con técnicas como requestIdleCallBack para diferir las tareas no críticas.
¿Cómo ayudó a The Economic Times mejorar el INP?
INP y TBT actuales en el origen
Al momento de publicar esta publicación, la TBT de nuestro origen era de 120 milisegundos, en comparación con los 3,260 milisegundos que vimos cuando comenzamos nuestros esfuerzos de optimización. De manera similar, el INP de nuestro origen fue de 257 milisegundos después de nuestros esfuerzos de optimización, en comparación con más de 1,000 milisegundos.
Tendencia de INP CrUX
El tráfico recibido en las páginas de temas representa una porción significativamente menor del tráfico general. Por lo tanto, era un lugar ideal para la experimentación. Los resultados de CrUX y los resultados comerciales fueron muy alentadores y nos llevaron a ampliar nuestros esfuerzos en todo el sitio web para obtener más beneficios.
Análisis TBT de Akamai mPulse
Utilizamos Akamai mPulse como nuestra solución de RUM, que mide la TBT en el campo. Observamos una disminución constante en la TBT, que refleja claramente los resultados de nuestros esfuerzos para reducir el INP. Como se puede ver en la siguiente captura de pantalla, los valores TBT eventualmente disminuyeron de unos 5 segundos a unos 200 milisegundos en el campo.
Resultado empresarial
En general, nuestros esfuerzos por reducir la TBT en 30 veces y la migración a Next.js nos permitieron reducir el INP casi 4 veces, lo que finalmente generó una disminución del 50% en el porcentaje de rebote y un aumento del 43% en las vistas de página en las páginas de temas.
Conclusión
En resumen, el INP ayudó en gran medida a determinar los problemas de rendimiento durante el tiempo de ejecución en partes del sitio web de Economic Times. Está demostrado ser una de las métricas más eficaces para tener un impacto positivo en los resultados comerciales. Debido a las cifras muy alentadoras que hemos observado como resultado de este esfuerzo, nos vemos motivados a ampliar nuestros esfuerzos de optimización a otras áreas de nuestro sitio web y cosechar beneficios adicionales.