INP: la métrica de Google que está redefiniendo qué significa 'sitio rápido'
Desde que INP (Interaction to Next Paint) reemplazó a FID como Core Web Vital en 2024, el estándar de "sitio rápido" cambió de naturaleza: ya no basta cargar rápido — hay que responder rápido a cada clic, tap y tecla durante toda la sesión. Y como los Core Web Vitals influyen en el ranking de Google, la métrica mueve dinero.
Qué mide exactamente
INP observa todas las interacciones de la visita y reporta prácticamente la peor: cuánto tarda la página en pintar la respuesta visual después de que el usuario actúa. El umbral "bueno" es 200 ms. Un sitio puede tener carga inicial impecable y un INP pésimo — típico en apps con JavaScript pesado que congela el hilo principal.
Los sospechosos de siempre
- Tareas largas de JavaScript que bloquean el hilo principal (hidratación pesada, listeners que hacen demasiado).
- Third-parties — analytics, chats, pixels — ejecutando en el peor momento.
- Renders en cascada tras un clic (frameworks re-renderizando medio árbol para un toggle).
Las curas: dividir tareas largas, diferir lo no crítico (lazy, requestIdleCallback), islas de interactividad en vez de hidratación total, y menos JavaScript en general — la solución más efectiva y menos popular.
El ángulo QA
La performance percibida es comportamiento verificable, no magia de devs:
- Presupuesto en CI: Lighthouse CI con umbral de INP/TBT que rompe el build si se degrada — la regresión de performance se atrapa como cualquier otra.
- Datos de campo sobre datos de laboratorio: el reporte CrUX (usuarios Chrome reales) manda; el laboratorio aproxima. Un QA que sabe leer ambos vale más.
- El test manual del impaciente: clickea todo rápido en un celular de gama media — donde el INP muere. Si se siente pegajoso, los usuarios lo sienten peor.
Nuestra lectura
Aplicamos este estándar en lo que construimos: este mismo sitio se mantiene con presupuesto de performance en CI (por eso las secciones pesadas cargan diferido y el JavaScript inicial se vigila en cada release). Para pymes, la versión corta: un sitio que responde lento vende menos — Google lo mide, y tus clientas lo sienten.
Fuente original: web.dev (Google)