The Ecomonic Times disminuyó 30 veces el valor de TBT y la migración a Next.js ayudó a The Ecomonic Times a reducir 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.
Interacción a la siguiente pintura (INP) es una métrica que evalúa la capacidad de respuesta de un sitio web a la entrada del usuario. Una buena capacidad de respuesta significa que una página responde rápidamente a las interacciones del usuario. Cuanto menor sea el INP de una página, mejor podrá responder a las interacciones del usuario.
El comienzo confuso
Cuando Google introdujo inicialmente INP como una métrica experimental con el potencial de convertirse en una de las Métricas web esenciales, el equipo de Economic Times asumió el desafío de corregirla antes de pasar a ser una, ya que proporcionar una experiencia del usuario de primer nivel es fundamental para nuestros valores empresariales principales.
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 el INP eficazmente. Lo que lo hizo más difícil fue la falta de asistencia de la comunidad, incluido el hecho de que la mayoría de los proveedores de supervisión de usuarios reales (RUM) aún no lo admitían. Sin embargo, contábamos con herramientas de RUM de Google, como el Chrome User Experience Report (CrUX), la biblioteca de JavaScript web-vitals y otras que lo respaldaban, lo que nos dio una idea de dónde nos encontrabamos mientras evaluábamos los próximos pasos. Nuestro INP estaba cerca de 1,000 milisegundos en el nivel de origen cuando comenzamos.
Algo que surgió mientras se corrige el INP en el campo es que una de las métricas del lab para segmentar podría ser el Tiempo de bloqueo total (TBT). La TBT ya estaba bien documentada y recibió el apoyo de la comunidad. Sin embargo, a pesar de que ya alcanzamos los umbrales de Métricas web esenciales, no estábamos haciendo tan bien en cuanto a TBT, ya que tardaban más de 3 segundos cuando comenzamos.
¿Qué es TBT y qué pasos seguimos para mejorarlo?
TBT es una métrica del lab que mide la capacidad de respuesta de una página web a la entrada del usuario durante la carga de la página. 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.
La TBT se calcula con la suma del tiempo 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 que 50 milisegundos).
- La tarea B tarda 100 milisegundos (50 milisegundos más que 50 milisegundos).
El valor de 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 la INP.
A continuación, presentamos una comparación rápida de nuestro lab de nuestra TBT antes y después de realizar los pasos para mejorarla:
Minimiza el trabajo del subproceso principal
El subproceso principal del navegador se encarga de todo, desde el análisis de HTML y la compilación del DOM hasta el análisis de CSS y la aplicación de estilos, además de la evaluación y ejecución de JavaScript. El subproceso principal también controla las interacciones del usuario, es decir, hacer clic, presionar o presionar teclas. Si el subproceso principal está ocupado realizando otro trabajo, es posible que no responda a las entradas del usuario de manera eficiente y que provoque 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 a fin de publicar anuncios basados en el estado de la suscripción y las secuencias de comandos de terceros para pruebas A/B, estadísticas y mucho más.
Al principio, dimos pasos pequeños, como dejar de priorizar la carga de recursos comerciales de menor importancia. 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 transcurre el tiempo determinado y no se ha llamado aún la devolución de llamada, se ejecuta la devolución de llamada inmediatamente después de que se agota el tiempo de espera.
Minimizar 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 JavaScript y CSS sin usar. Para ello, creamos 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 requería 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
Por Lighthouse, los tamaños de DOM grandes aumentan el uso de memoria, provocan recálculos de estilo más largos y producen reprocesamientos del diseño costosos.
Redujimos la cantidad de nodos del DOM de dos maneras:
- Primero, procesamos los elementos de nuestro 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 significativamente el TBT y, en consecuencia, nuestro INP se redujo casi en un 50%:
En este punto, casi nos quedamos sin ganancias fáciles para reducir aún más las TBT (y el INP por proxy), pero sabíamos que teníamos mucho margen para mejorar. En este momento, decidimos actualizar nuestro código estándar de IU personalizado a la versión más reciente de React junto con Next.js para aprovechar mejor los hooks y evitar que se vuelvan a renderizar los componentes de forma innecesaria.
Debido a las actualizaciones más frecuentes y a un tráfico comparativamente menor en comparación con las otras partes del sitio web, comenzamos a migrar nuestras páginas de temas a Next.js. También usamos PartyTown para transferir trabajo adicional pesado de subproceso principal a los trabajadores web, junto con técnicas como requestIdleCallBack para diferir las tareas no críticas.
¿Cómo ayudó mejorar el INP a The Economic Times?
TBT e INP actuales en el origen
En el momento de la publicación de esta publicación, el TBT de nuestro origen era de 120 milisegundos, frente a los 3260 milisegundos que teníamos cuando comenzamos nuestros esfuerzos de optimización. Del mismo modo, el INP de nuestro origen fue de 257 milisegundos después de nuestros esfuerzos de optimización, en lugar de más de 1,000 milisegundos.
Tendencia de CrUX de INP
El tráfico recibido en las páginas de temas representa una porción significativamente menor del tráfico total. Por lo tanto, era un lugar ideal para experimentar. Los resultados de CrUX y los resultados comerciales fueron muy alentadores y nos llevaron a ampliar nuestros esfuerzos en todo el sitio web para cosechar más beneficios.
Análisis TBT de Akamai mPulse
Usamos Akamai mPulse como nuestra solución de RUM, que mide TBT en el campo. Observamos una disminución constante en la TBT, que indica claramente los resultados de nuestros esfuerzos para reducir el INP. Como se puede ver en la siguiente captura de pantalla, los valores TBT finalmente redujeron de 5 segundos a 200 milisegundos en el campo aproximadamente.
Resultados empresariales
En general, nuestras iniciativas para reducir la TBT en 30 veces, junto con la migración a Next.js, nos ayudaron a 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 páginas vistas en páginas de temas.
Conclusión
En resumen, INP ayudó muchísimo a determinar los problemas de rendimiento durante el tiempo de ejecución en partes del sitio web del Economic Times. Demostró ser una de las métricas más eficaces para generar un impacto positivo en los resultados comerciales. Debido a las cifras muy alentadoras que hemos observado como resultado de este esfuerzo, nos motiva ampliar nuestras iniciativas de optimización a otras áreas de nuestro sitio web y cosechar beneficios adicionales.