Destacamos Microsoft Clarity como un producto diseñado con casos de uso prácticos y reales, por expertos en productos que comprenden los desafíos que enfrentan empresas como Switas. Funciones como los clics de ira y el seguimiento de errores de JavaScript resultaron invaluables para identificar las frustraciones y los problemas técnicos de los usuarios, lo que permitió mejoras específicas que impactaron directamente en la experiencia del usuario y las tasas de conversión.
Interacción con la siguiente pintura (INP)
La métrica Interaction to Next Paint mide la rapidez con la que una página responde visualmente a la interacción del usuario, y proporciona un valor que representa las peores latencias de interacción experimentadas durante una visita. Reemplazó a First Input Delay como métrica de capacidad de respuesta de Core Web Vitals en marzo de 2024, y el cambio fue significativo: mientras que la métrica anterior solo registraba el retraso antes de que comenzara el procesamiento en la primera interacción, esta mide la duración total desde la entrada, pasando por el procesamiento, hasta que se dibuja el siguiente fotograma, en todas las interacciones de la sesión.
Esa diferencia es importante porque la métrica anterior favorecía a muchos sitios. Una página podía registrar un excelente retardo en la primera interacción, pero seguir siendo lenta, ya que la métrica ignoraba el tiempo de ejecución del controlador de eventos y el tiempo que tardaba el navegador en renderizar el resultado, y porque solo consideraba una interacción. Los sitios que parecían responsivos con la métrica anterior a menudo no lo son con la nueva, especialmente las aplicaciones de una sola página y cualquier interfaz con lógica compleja del lado del cliente.
El valor reportado se deriva de las interacciones más largas observadas, con una tolerancia para valores atípicos en páginas con muchas interacciones, y el umbral publicado por Google considera que 200 milisegundos o menos es un buen resultado en el percentil 75 de las experiencias reales de los usuarios. Dado que abarca todo el proceso, desde la entrada hasta la visualización, los resultados bajos pueden deberse a varios factores: tareas largas en el hilo principal que impiden que el navegador gestione el evento, controladores de eventos que realizan un trabajo excesivo de forma síncrona, problemas de diseño causados por estilos de lectura y escritura intercalados, y una renderización costosa después de cambios de estado.
El diagnóstico suele apuntar a la ejecución de JavaScript en lugar de a las condiciones de la red, lo que distingue esta métrica de las medidas de carga. Las causas comunes incluyen grandes paquetes monolíticos que se ejecutan en el hilo principal, scripts de terceros que ejecutan tareas arbitrarias durante la interacción, renderizaciones de frameworks que afectan a una parte mucho mayor del árbol de la que requiere el cambio, y manejadores que realizan cálculos síncronos que podrían aplazarse o ejecutarse fuera del hilo principal. En la mayoría de los casos, las tareas largas son el mecanismo subyacente, ya que el navegador no puede responder a la entrada mientras se ejecuta una tarea.
La solución se implementa tras el diagnóstico. Dividir las tareas largas en partes más pequeñas con cesiones explícitas permite que el navegador gestione la entrada entre ellas. Posponer el trabajo no esencial hasta después de la actualización visual, para que el usuario vea una respuesta de inmediato, aborda el patrón más común. Reducir la cantidad de JavaScript enviado, auditar los scripts de terceros para el costo del hilo principal, virtualizar listas largas y trasladar los cálculos pesados a un proceso secundario abordan causas específicas. Proporcionar retroalimentación visual inmediata para las operaciones lentas no mejora el valor medido, pero sí cambia la forma en que se experimenta la demora.
Los scripts de terceros merecen una atención especial, ya que son una causa frecuente de problemas y están fuera del control directo del equipo. Los widgets de chat, los gestores de consentimiento, las bibliotecas de análisis, las herramientas de personalización y los scripts publicitarios se ejecutan en el hilo principal y pueden ocuparlo precisamente en los momentos en que un visitante intenta interactuar. Auditar el coste en el hilo principal de cada tercero, idealmente midiendo la página con y sin él, proporciona una lista concreta del coste de cada proveedor en términos de capacidad de respuesta. Esta cifra permite analizar la relación coste-beneficio con los equipos que solicitaron cada herramienta, lo que suele ser una vía más productiva que intentar optimizar el código de la aplicación en torno a un script que consume la mayor parte del presupuesto disponible.
Debido a que la métrica está impulsada por el código de la aplicación en lugar de por la entrega de activos, mejorarla generalmente requiere trabajo de ingeniería en lugar de configuración. En la práctica, se sitúa en el límite entre rendimiento web y desarrollo de productosy tiene consecuencias particularmente importantes para las interfaces de comercio interactivo y reservas, donde el filtrado, la configuración y las interacciones con el carrito que no responden producen abandonos que aparecen en los análisis como abandonos ordinarios sin una causa aparente.
Switas como se ve en
