Reducir el TBT en 30 veces ayudó a un cliente a reducir la métrica INP casi cuatro veces, lo que llevó a una disminución del 50% en la tasa de rebote y un aumento del 43% en las vistas de página.
La Interacción hasta la Siguiente Pintura (INP)
La Interacción hasta 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 incierto
Cuando Google inicialmente introdujo INP como una métrica experimental con el potencial de evolucionar en una de las métricas de Core Web Vitals, la empresa aceptó el desafío de solucionarlo antes de que se convirtiera en una, ya que proporcionar una experiencia de usuario de clase mundial es crucial para nuestros valores comerciales fundamentales.
INP ha sido una de las métricas más difíciles de resolver hasta ahora. Al principio, no estaba claro cómo medir INP de manera efectiva. Lo que lo hizo más difícil fue la falta de apoyo de la comunidad, incluyendo la mayoría de los proveedores de Monitoreo de Usuarios Reales (RUM) que aún no lo apoyaban. Sin embargo, teníamos herramientas de RUM de Google como el Informe de Experiencia de Usuario de Chrome (CrUX), la biblioteca de JavaScript de web-vitals y otras que lo apoyaban, lo que nos dio una idea de dónde estábamos mientras evaluábamos el camino a seguir. Nuestro INP estaba cerca de 1,000 milisegundos a nivel de origen cuando comenzamos.
Una cosa que surgió mientras solucionábamos INP en el campo fue que una de las métricas de laboratorio a las que podríamos apuntar podría ser el Tiempo Total de Bloqueo (TBT). TBT ya estaba bien documentado y apoyado por la comunidad. A pesar de que ya cumplíamos con los umbrales de Core Web Vitals, sin embargo, no estábamos haciendo tan bien en el frente de TBT, ya que estaba por encima de 3 segundos cuando comenzamos.
¿Qué es TBT y qué pasos tomamos para mejorarlo?
El TBT es una métrica de laboratorio 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.
TBT se calcula tomando 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 TBT de la página será: 80 milisegundos (30 + 50). Cuanto menor sea el TBT, mejor, y TBT también se correlaciona bien con INP.
Aquí hay una rápida comparación de laboratorio de nuestro TBT antes y después de tomar medidas para mejorarlo:
ANTES
DESPUÉS
Minimizar el trabajo del hilo principal
El hilo principal del navegador se encarga de todo, desde analizar HTML, construir el DOM, hasta analizar CSS y aplicar estilos, así como evaluar y ejecutar JavaScript. El hilo principal también maneja las interacciones del usuario, es decir, clics, toques y pulsaciones de teclas. Si el hilo principal está ocupado haciendo otro trabajo, puede que no responda eficientemente a las entradas del usuario, y puede llevar a una experiencia de usuario irregular.
Esta fue la tarea más difícil para nosotros, ya que tenemos nuestros propios algoritmos para detectar la identidad del usuario para servir anuncios basados en el estado de la suscripción y scripts de terceros para pruebas A/B, análisis y más.
Minimizar el tiempo de evaluación de scripts
También cargamos con lazyload las bibliotecas de terceros utilizando componentes cargables. También eliminamos JavaScript y CSS no utilizados perfilando la página con la herramienta de cobertura en Chrome DevTools. Nos ayudó a identificar áreas donde se necesitaba sacudir el árbol para enviar menos código durante la carga de la página, y por lo tanto reducir el tamaño del paquete inicial de la aplicación.
Reducir el tamaño del DOM
Según Lighthouse, los tamaños grandes de DOM aumentan el uso de memoria, causan cálculos de estilo más largos y producen reflujo de diseño costoso.
Reducimos el número de nodos del DOM de dos maneras:
- Primero, renderizamos nuestros elementos de menú a petición del usuario (al hacer clic). Esto disminuyó el tamaño del DOM en alrededor de 1,200 nodos.
- En segundo lugar, cargamos en lazyload los widgets menos importantes.
Debido a todos estos esfuerzos, redujimos significativamente el TBT, y nuestro INP se redujo en consecuencia casi en un 50%:
En este punto, casi nos quedamos sin victorias fáciles para reducir aún más el TBT (y por ende el INP).
¿Cómo ha ayudado la mejora de INP?
En el momento de publicar este post, el TBT para nuestro origen era de 120 milisegundos, bajando desde 3,260 milisegundos cuando comenzamos nuestros esfuerzos de optimización. De manera similar, el INP para nuestro origen era de 257 milisegundos después de nuestros esfuerzos de optimización, bajando desde más de 1,000 milisegundos.
El tráfico recibido en las páginas de temas representa una porción significativamente menor del tráfico total. Por lo tanto, fue un lugar ideal para la experimentación. Los resultados de CrUX junto con los resultados empresariales fueron muy alentadores, y nos llevaron a expandir nuestros esfuerzos en todo el sitio web para obtener más beneficios.
Utilizamos Google Search como nuestra solución RUM, que mide TBT en el campo. Observamos una disminución constante en TBT, claramente mapeando a los resultados de nuestros esfuerzos para reducir INP. Como se puede ver en la captura de pantalla a continuación, los valores de TBT finalmente cayeron de aproximadamente 5 segundos a alrededor de 200 milisegundos en el campo.
Resultado empresarial
En general, nuestros esfuerzos para reducir TBT en 30 veces nos ayudaron a reducir INP casi 4 veces, lo que finalmente llevó a una disminución del 50% en la tasa de rebote y un aumento del 43% en las vistas de página en las páginas de temas.
Conclusión
Para resumir, INP ayudó extensamente a determinar los problemas de rendimiento en tiempo de ejecución en la web del cliente. Ha demostrado ser una de las métricas más efectivas para impactar positivamente los resultados empresariales. Debido a los números muy alentadores que hemos observado como resultado de este esfuerzo, estamos motivados para escalar nuestros esfuerzos de optimización a otras áreas de nuestro sitio web y obtener beneficios adicionales.