Guías

Los 200 milisegundos que los usuarios expulsan del SaaS

Una interfaz SaaS parece lenta mucho antes de que sea medible. Interaction to Next Paint mide esa vacilación y determina tanto el posicionamiento como…

Por Benedikt Langer 17 julio 2026 4 min de lectura

Los 200 milisegundos que los usuarios expulsan del SaaS

Una interfaz SaaS parece lenta mucho antes de que sea medible. El usuario hace clic. Durante un parpadeo no ocurre nada. Es precisamente esta vacilación lo que mide Interaction to Next Paint. Este valor influye en el ranking de Google y, aún más, en si una aplicación se siente ágil o lenta.

Por qué FID ya no era suficiente

First Input Delay solo medía el retraso de la primera interacción en una página. Para las páginas web clásicas, esto era un indicador útil. Pero para una aplicación SaaS, en la que los usuarios hacen clic, filtran y escriben durante minutos, se quedaba corto. El primer clic no dice nada sobre cómo se siente la aplicación después de diez minutos de trabajo.

Interaction to Next Paint cierra esta brecha. Considera prácticamente todas las interacciones de una sesión y reporta el peor valor representativo. Así, INP mide lo que los usuarios realmente experimentan: la capacidad de respuesta durante toda la sesión. Para interfaces interactivas, este es un criterio más honesto.

Dónde se pierden los milisegundos

En casi todos los casos, la causa está en el Main Thread. El navegador procesa las interacciones, el renderizado y JavaScript en el mismo hilo. Si allí se ejecuta una tarea larga, la respuesta al clic debe esperar. El usuario lo percibe como un tartamudeo o un retraso hasta que algo se mueve en la pantalla.

En la práctica, hay tres patrones. Paquetes de JavaScript demasiado grandes, que generan trabajo al cargar y con cada interacción. Re-renderizados costosos, en los que un clic recalcula toda una jerarquía de componentes. Y manejadores síncronos que realizan trabajo de red o cómputo antes de liberar la interfaz. Quien quiera mejorar el INP, debe buscar aquí.

Los mecanismos más efectivos

El primer mecanismo es la división. Las tareas largas pueden dividirse en fragmentos más pequeños, de modo que el navegador pueda responder a las entradas entre medias. Los enfoques modernos posponen el trabajo no crítico detrás de la respuesta real, por ejemplo, con un *yield* dirigido al planificador. El usuario ve una respuesta inmediata y el resto del trabajo se ejecuta después.

El segundo mecanismo es menos código en el momento adecuado. El *code-splitting* carga solo lo que necesita la pantalla actual. El tercero es la disciplina en el renderizado: evitar re-renderizados innecesarios, memoizar cálculos costosos y virtualizar listas grandes. Ningún truco por sí solo logra el avance. La suma de las decisiones determina si una interacción se mantiene por debajo de los 200 milisegundos.

Mediciones en el funcionamiento real

Una prueba de laboratorio en el navegador del desarrollador engaña. Se ejecuta en hardware rápido con buena red y rara vez alcanza las interacciones que duelen en el día a día. Los datos de campo de usuarios reales son significativos. El Chrome UX Report los proporciona agregados, y una recopilación propia mediante la biblioteca Web Vitals muestra qué interacciones producen concretamente los valores malos.

El camino pragmático: recopilar datos de campo, identificar las peores interacciones y optimizar allí de forma específica. Quien, en cambio, ajusta a ciegas en puntos supuestamente lentos, quema tiempo en síntomas que nadie nota. Al final, INP no es un valor SEO que se pueda marcar como hecho. Es la métrica de si el software se siente bien.

Preguntas frecuentes

¿Qué es Interaction to Next Paint (INP)?

INP es un Core Web Vital de Google. Mide qué tan rápido un sitio web o aplicación responde visiblemente a las interacciones del usuario, como clics, toques y pulsaciones de teclado. Se evalúa la latencia en toda la sesión, no solo la primera interacción. Un buen valor está por debajo de 200 milisegundos.

¿Cuándo reemplazó INP al valor FID?

En marzo de 2024, Interaction to Next Paint se convirtió oficialmente en un Core Web Vital y reemplazó a First Input Delay. FID medía solo la primera interacción, mientras que INP considera la capacidad de respuesta durante todo el uso.

¿Qué valor de INP se considera bueno?

Google evalúa un INP por debajo de 200 milisegundos como bueno, de 200 a 500 milisegundos como mejorable y por encima de 500 milisegundos como malo. El valor se refiere al percentil 75 de las visitas a la página.

¿Por qué las aplicaciones SaaS se ven particularmente afectadas?

Porque son interactivas. Cada clic, cada entrada y cada cambio de estado influye en el valor de INP. Las páginas de contenido tienen pocas interacciones, una aplicación tiene cientos por sesión. En consecuencia, un hilo principal bloqueado afecta más duramente.

¿Cómo se mide INP de forma fiable?

Mediante datos de campo de usuarios reales, no mediante pruebas de laboratorio. El Chrome UX Report proporciona valores agregados, y una recopilación propia con la biblioteca web-vitals muestra qué interacciones concretas causan los valores malos.