¿Cómo puede la optimización de Core Web Vitals en dispositivos móviles reducir el INP?

Para reducir el INP en dispositivos móviles, la clave no es que la página se descargue más rápido, sino que el navegador muestre cuanto antes el siguiente fotograma después de un clic, un toque o una entrada de teclado. Comprimir imágenes e integrar una CDN puede mejorar la experiencia de carga, pero no resuelve directamente el problema de que un botón tarde en responder después de hacer clic. Si el hilo principal está ocupado ejecutando scripts o renderizando la página, la interacción seguirá siendo lenta.

Para determinar cómo optimizar Core Web Vitals y mejorar la experiencia móvil, hay que desglosar el INP en retraso de entrada, tiempo de procesamiento de eventos y retraso de presentación, y abordar después el origen del tiempo empleado. Acortar únicamente la función de devolución de llamada de un clic o mejorar una puntuación puntual de laboratorio no basta para demostrar que la respuesta a las interacciones de los usuarios reales haya mejorado.

El INP mide el tiempo desde la interacción hasta el siguiente fotograma, no hasta que se completa la operación

El INP, o interacción hasta el siguiente renderizado, observa los clics, toques e interacciones de teclado que cumplen los requisitos durante el ciclo de vida de una página y refleja la respuesta de las interacciones más lentas. Cuando hay muchas interacciones, el cálculo descarta algunos valores extremos conforme a ciertas reglas, por lo que no debe entenderse simplemente como el promedio del tiempo de todos los clics ni como el valor máximo absoluto.

En la evaluación Core Web Vitals de Google, un INP de hasta 200 milisegundos se considera «bueno»; si supera los 200 milisegundos, pero no los 500, «necesita mejorar»; y si supera los 500 milisegundos, es «deficiente». La evaluación del cumplimiento del sitio se basa en el percentil 75 de los datos de visitas reales y se realiza por separado para dispositivos móviles y de escritorio. Esto es distinto de seleccionar las interacciones representativas dentro de una sola visita a la página: son dos niveles estadísticos diferentes.

El INP tampoco es el tiempo de respuesta de una API. Si, después de enviar una consulta, se muestra de inmediato el estado «Enviando» y la solicitud de red se completa después, el INP de esa interacción puede ser bajo. Sin embargo, un INP bajo no significa que la operación se haya completado correctamente: también hay que supervisar por separado el tiempo de las solicitudes, la tasa de errores y los envíos duplicados.

Primero localiza qué etapa es lenta y luego decide qué cambiar

El retraso de entrada de una interacción es el tiempo de espera desde que el usuario realiza una acción hasta que comienza a ejecutarse la función de devolución de llamada del evento. El tiempo de procesamiento es lo que tardan en ejecutarse las funciones de devolución de llamada relacionadas. El retraso de presentación es el tiempo entre el fin de dichas funciones y la visualización del siguiente fotograma. Cualquiera de las tres etapas puede ser un cuello de botella en dispositivos móviles.

Si, cuando el usuario hace clic, el hilo principal está analizando scripts, ejecutando código de terceros o procesando otras tareas, aumentará el retraso de entrada. Si la función de devolución de llamada filtra sincrónicamente una gran cantidad de productos, valida todo un formulario o actualiza muchos componentes, aumentará el tiempo de procesamiento. Si, al terminar la función, todavía hay que realizar cálculos de estilo, diseño y renderizado a gran escala, aumentará el retraso de presentación.

Puedes grabar en el panel de rendimiento de Chrome DevTools acciones como abrir un menú, filtrar productos, cambiar especificaciones y enviar una consulta, y revisar las tareas del hilo principal y la actividad de renderizado a lo largo de la interacción. Las tareas que superan los 50 milisegundos se consideran tareas largas, pero solo son una pista para la investigación: varias tareas cortas consecutivas también pueden retrasar el renderizado. La ausencia de tareas largas no demuestra que el INP cumpla los objetivos.

Reducir los bloqueos es más importante que limitarse a aplazar los scripts

Si el retraso de entrada es elevado, comprueba si se ejecutan muchos scripts a la vez cuando el usuario empieza a interactuar. En los sitios web de marketing, conviene revisar uno por uno el chat de atención al cliente, las etiquetas de analítica, el seguimiento de anuncios y los componentes de ventanas emergentes, teniendo en cuenta cuándo se cargan y cuánto cuesta ejecutarlos. Usar async o defer puede cambiar el momento de carga y ejecución de los scripts, pero no elimina la ocupación del hilo principal durante su ejecución.

Los scripts no esenciales se pueden cargar en función del propósito de la página, el estado del consentimiento o las necesidades reales de uso, y se pueden eliminar las etiquetas duplicadas. Al cargar scripts de forma diferida, evita iniciarlos todos a la vez con el primer clic; de lo contrario, solo trasladarás el coste de carga a la ruta de interacción.

Los cálculos sincrónicos deben dividirse en lotes y ceder el hilo principal entre uno y otro. Los navegadores compatibles pueden usar scheduler.yield(); en otros entornos se necesita una alternativa. Dividir el trabajo usando solo Promise o queueMicrotask no es fiable, porque la cola de microtareas puede seguir ejecutándose antes del renderizado. Los cálculos que consumen mucha CPU y no dependen del DOM se pueden trasladar a un Web Worker, pero hay que tener en cuenta el coste de comunicación y copia de datos.

Hay que reducir tanto las funciones de devolución de llamada de eventos como el renderizado

Las funciones de devolución de llamada de los clics deben priorizar los cambios de estado necesarios, como mostrar un estado de carga, marcar la opción actual o desactivar los envíos repetidos, y después programar el trabajo no urgente. Modificar primero la interfaz y ejecutar luego más cálculos sincrónicos no significa que el usuario ya haya visto la respuesta: el navegador necesita una oportunidad para renderizarla.

El filtrado de productos puede almacenar en caché los resultados para evitar recorrer todos los datos de nuevo en cada interacción. La validación de formularios debe evitar recalcular el formulario entero cada vez que se introduce un carácter. El debounce sirve para reducir las consultas que no necesitan resultados inmediatos, pero no debe retrasar la respuesta visual de un botón ni usarse para ocultar la lentitud de una operación necesaria.

Si el retraso de presentación es elevado, revisa el tamaño del DOM, el alcance de los cambios de estilo y los límites de actualización de los componentes. Las listas largas de productos se pueden virtualizar, pero hay que tener en cuenta la accesibilidad y las necesidades de rastreo de los motores de búsqueda. Alternar repetidamente entre «escribir un estilo» y «leer una dimensión» puede provocar un cálculo de diseño forzado; conviene agrupar primero las lecturas y luego las escrituras. En las aplicaciones basadas en frameworks, también hay que comprobar si un cambio de estado local actualiza componentes no relacionados, en lugar de limitarse a medir el tiempo de las funciones de devolución de llamada.

requestAnimationFrame tampoco es un espacio para guardar tareas costosas: el código que contiene se ejecuta antes del renderizado, por lo que incluir en él muchos cálculos puede bloquear el siguiente fotograma.

Valida con datos de visitas reales, no solo con una prueba puntual

Las pruebas de laboratorio sirven para reproducir las causas; la monitorización de usuarios reales permite confirmar el alcance del impacto. Los datos de CrUX en PageSpeed Insights reflejan la experiencia de visitas reales. Si el tráfico no es suficiente, es posible que no haya datos a nivel de página; la ausencia de datos no significa que el rendimiento sea bueno. El tiempo total de bloqueo de Lighthouse puede ayudar a detectar presión sobre el hilo principal durante la carga, pero no sustituye al INP.

En el sitio se puede usar web-vitals y su función de atribución para registrar el objetivo de la interacción, el tipo de página y el tiempo de cada etapa, evitando recopilar datos personales como el contenido de los formularios. Las pruebas deben abarcar dispositivos móviles reales y condiciones razonables de limitación de la CPU; el modo de pantalla estrecha de un navegador de escritorio no refleja las diferencias en la capacidad de procesamiento de los dispositivos móviles.

La aceptación de una puesta en producción debe comparar la distribución del INP en páginas similares y en condiciones de dispositivo parecidas, y volver a comprobar que las interacciones clave sigan completándose correctamente. CrUX utiliza datos móviles de 28 días, por lo que no se puede esperar que todos los efectos de un cambio se reflejen de inmediato. Según la definición de INP de Google, una optimización eficaz se demuestra con una reducción del tiempo de espera de las interacciones reales, no con una disminución del tamaño de los recursos ni con una mejora en una prueba puntual.