Interaction to Next Paint (INP): Qué es, cómo medirlo y mejorarlo

Interaction to Next Paint (INP) es una Core Web Vital que mide la rapidez con la que una página web responde a las interacciones del usuario, como clics, toques y pulsaciones de teclas. INP captura la latencia completa desde la entrada del usuario, pasando por el procesamiento de JavaScript, hasta la actualización visual final en pantalla. Una buena puntuación de INP es de 200 milisegundos o menos en el percentil 75. INP reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024.

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

Interaction to Next Paint (INP) es una métrica de Core Web Vitals que mide la capacidad de respuesta de una página web durante toda la visita del usuario. A diferencia de su predecesor First Input Delay (FID), que solo medía el retraso antes de que comenzara el manejador de eventos de la primera interacción, INP evalúa cada interacción que un usuario realiza con la página e informa un único valor que representa la capacidad de respuesta general de la página.

Cada vez que un usuario hace clic en un botón, toca un enlace, presiona una tecla del teclado o interactúa con un control personalizado, el navegador mide el tiempo total desde el momento de la entrada hasta que el siguiente frame se pinta en pantalla. INP selecciona una de las interacciones más lentas como la puntuación de capacidad de respuesta de la página. Para páginas con menos de 50 interacciones totales, INP informa la peor interacción. Para páginas con muchas interacciones, INP típicamente usa el percentil 98 para filtrar valores atípicos ocasionales.

Un INP bajo significa que la página responde de manera confiable a la entrada del usuario de forma oportuna. Un INP alto significa que la página se siente lenta, sin respuesta o "entrecortada" porque el navegador no puede procesar las interacciones y actualizar la pantalla con suficiente rapidez.

INP vs FID: Qué cambió y por qué

INP reemplazó oficialmente a First Input Delay (FID) como Core Web Vital en marzo de 2024. Google retiró FID porque tenía dos limitaciones fundamentales que lo convertían en una medida incompleta de la capacidad de respuesta de la página.

Primero, FID solo medía la primera interacción en una página. Si el primer clic de un usuario era rápido pero las interacciones posteriores eran lentas, FID reportaría una puntuación aprobatoria a pesar de la mala experiencia. INP mide todas las interacciones a lo largo de la sesión, proporcionando una imagen mucho más precisa de la capacidad de respuesta real.

Segundo, FID solo medía la fase de input delay, lo que significa que capturaba el tiempo que el navegador pasaba esperando antes de comenzar a procesar el evento. Ignoraba completamente el tiempo dedicado a ejecutar el código del manejador de eventos (tiempo de procesamiento) y el tiempo necesario para pintar el resultado visual en pantalla (presentation delay). INP captura las tres fases, dando a los desarrolladores una vista completa de la latencia de interacción.

La transición de FID a INP causó una caída de aproximadamente 5 puntos porcentuales en las tasas de aprobación de Core Web Vitals en móvil, según el Web Almanac 2025 de HTTP Archive. Esto ocurrió porque muchos sitios que parecían receptivos bajo FID tenían interacciones posteriores lentas que INP ahora captura.

¿Qué interacciones mide INP?

INP solo mide interacciones que involucran entrada discreta del usuario que el navegador puede observar a través de manejadores de eventos. Entender qué interacciones cuentan es esencial para una depuración y optimización precisas.

Interacciones que cuentan para INP

• Clics del ratón (incluyendo clics en botones, enlaces, casillas de verificación y controles personalizados)
• Toques en pantallas táctiles (equivalente a clics en dispositivos móviles)
• Pulsaciones de teclas en un teclado físico o en pantalla (incluyendo escritura en campos de formulario, presionar Enter, usar atajos de teclado)

Interacciones que NO cuentan para INP

• El desplazamiento (scroll) no cuenta porque es manejado por el hilo compositor del navegador y típicamente no bloquea el hilo principal
• Pasar el cursor (hover) no cuenta porque es un estado continuo del puntero, no una interacción discreta del usuario
• Los gestos de arrastre no cuentan, aunque el pointerdown inicial que comienza un arrastre puede generar una entrada INP
• Las transiciones y animaciones CSS que ocurren sin entrada del usuario no son interacciones

Un error común es creer que el desplazamiento afecta al INP. No es así. Sin embargo, si tu página usa desplazamiento basado en JavaScript en lugar del desplazamiento nativo del navegador, esos manejadores de scroll en JavaScript pueden activar callbacks de eventos que el navegador mide como interacciones. Esta es una razón por la que el desplazamiento nativo con CSS supera consistentemente al desplazamiento con JavaScript en capacidad de respuesta.

Las tres fases de una interacción INP

Cada interacción medida por INP consta de tres fases secuenciales. El valor total de INP es la suma de las tres. Entender cada fase es crítico porque la estrategia de optimización difiere para cada una.

1. Input Delay

El input delay es el tiempo entre cuando el usuario interactúa con la página y cuando el navegador comienza a ejecutar los manejadores de eventos asociados. Este retraso ocurre porque el hilo principal del navegador puede estar ocupado con otro trabajo, como analizar JavaScript, ejecutar tareas previamente programadas o procesar otros callbacks de eventos.

El input delay es especialmente problemático durante la fase de carga de la página cuando muchos scripts se están analizando y ejecutando simultáneamente. Los datos de CoreDash muestran que las interacciones durante la fase de carga tienen un INP p75 de 132ms, comparado con solo 50ms para las interacciones después de que la carga de la página se completa. Eso es una diferencia de 2,6 veces. Reducir la contención del hilo principal durante el inicio de la página es una de las formas más efectivas de mejorar el INP.

En la mediana, el input delay es la sub-parte más pequeña del INP. Pero en el percentil 90, el input delay se convierte en el contribuyente dominante porque las tareas largas en el hilo principal pueden retrasar el procesamiento de eventos por cientos de milisegundos. El Web Almanac 2025 de HTTP Archive encontró que menos del 25% de los sitios web mantienen la duración de las tareas por debajo del umbral recomendado de 50ms.

2. Tiempo de procesamiento

El tiempo de procesamiento es el tiempo total que el navegador dedica a ejecutar todos los callbacks del manejador de eventos asociados con la interacción. Esto incluye cualquier JavaScript que se ejecute en respuesta al evento, desde validación de formularios hasta actualizaciones de estado y llamadas de seguimiento de analíticas.

El tiempo de procesamiento representa una porción significativa del INP total. Si un manejador de eventos realiza operaciones DOM costosas, hace llamadas API sincrónicas o ejecuta bucles ineficientes, el tiempo de procesamiento se disparará. Un patrón común que infla el tiempo de procesamiento es ejecutar código no esencial (como eventos de analíticas o callbacks de etiquetas de terceros) dentro del mismo manejador de eventos que la actualización visual crítica.

3. Presentation Delay

El presentation delay es el tiempo entre cuando todos los manejadores de eventos han terminado de ejecutarse y cuando el navegador presenta el siguiente frame con la actualización visual. Esta fase incluye el recálculo de estilos, el cálculo de layout, el pintado y la composición.

En la mediana, el presentation delay es la sub-parte más grande del INP porque cada interacción requiere al menos un pase de renderizado. Las páginas con un DOM grande o profundamente anidado tardan más en recalcular estilos y realizar el layout. Las aplicaciones de página única (SPA) que re-renderizan grandes árboles de componentes después de cambios de estado son particularmente susceptibles a un alto presentation delay.

¿Cuáles son las puntuaciones buenas y malas de INP?

Para aprobar la evaluación de Core Web Vitals para la métrica Interaction to Next Paint, el percentil 75 de todas las interacciones registradas en campo debe mantenerse por debajo de 200 milisegundos:

• Un INP igual o inferior a 200 milisegundos significa que tu página tiene buena capacidad de respuesta.
• Un INP entre 200 y 500 milisegundos significa que la capacidad de respuesta de tu página necesita mejoras.
• Un INP superior a 500 milisegundos significa que tu página tiene una capacidad de respuesta deficiente.

Es importante entender que INP usa el percentil 75, no el promedio. Esto significa que el 75% de tus usuarios reales deben experimentar interacciones más rápidas que 200ms. La metodología del percentil 75 asegura que la métrica refleje la experiencia de usuarios en dispositivos y conexiones más lentos, no solo aquellos con hardware de gama alta.

Cómo medir Interaction to Next Paint (INP)

Interaction to Next Paint solo se puede medir con herramientas de campo que capturen interacciones reales de usuarios. A diferencia de las métricas de laboratorio que simulan una carga de página única, INP requiere visitantes reales haciendo clic, tocando y escribiendo en tus páginas. No hay forma de obtener una puntuación de INP significativa a partir de una prueba sintética porque INP depende del comportamiento humano real.

Obtén las métricas oficiales de INP

Puedes obtener las métricas oficiales de INP desde PageSpeed Insights o el panel de CrUX y Google BigQuery. PageSpeed Insights informa la puntuación del percentil 75 basada en los últimos 28 días de datos de usuarios de Chrome. Google BigQuery proporciona más contexto histórico y permite consultas personalizadas en todo el conjunto de datos CrUX.

Google Search Console también informa problemas de INP en la sección de Core Web Vitals, agrupando las URLs afectadas y señalando las páginas que necesitan mejoras o tienen una capacidad de respuesta deficiente.

Rastrea el INP con Real User Monitoring

Mientras que el conjunto de datos oficial CrUX es la fuente definitiva para las puntuaciones de Core Web Vitals, está altamente anonimizado y no soporta monitoreo en tiempo real ni filtrado detallado. Por eso los profesionales de rendimiento web confían en herramientas de Real User Monitoring (RUM) como CoreDash para obtener datos de INP prácticos y en tiempo real. Las herramientas RUM recopilan mediciones de INP de cada carga de página, las atribuyen a elementos específicos, estados de carga y tipos de dispositivos, y te permiten diagnosticar exactamente qué interacciones están causando problemas.

Mide el INP para la sesión actual

La forma más sencilla de depurar el INP durante el desarrollo es a través de Chrome DevTools. Abre el panel de Rendimiento y usa el modo "timespan" en Lighthouse para grabar interacciones y ver su latencia. También puedes usar la extensión Core Web Vitals Visualizer, que superpone las puntuaciones de INP en la página mientras interactúas con ella.

Para depuración práctica, usa la biblioteca JavaScript Web Vitals de Google para registrar interacciones individuales en la consola:

Registra el INP en la consola con la biblioteca JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Cómo mejorar Interaction to Next Paint

Mejorar Interaction to Next Paint requiere optimizar las tres fases: input delay, tiempo de procesamiento y presentation delay. Tu página podría responder instantáneamente a la mayoría de las interacciones, pero si incluso una interacción es lenta, puede definir toda la puntuación de INP. Por eso es necesario un enfoque sistemático.

CONSEJO PageSpeed: la mayoría de las veces el INP será mucho peor cuando un usuario interactúa con la página durante la fase de inicio de la carga de la página. Por eso, al depurar el INP, tiene sentido registrar todas las interacciones así como el estado de carga de la página.

1. Minimiza el Input Delay: Prevén tareas largas en el hilo principal

Normalmente cualquier página es menos receptiva durante la fase de inicio, cuando ocurre la mayor parte del trabajo del hilo principal (análisis, decodificación, renderizado y scripting). Para mantener el hilo principal lo más libre posible:

• Elimina código no utilizado. Usa tree shaking para eliminar código muerto y code splitting para dividir tu bundle en fragmentos más pequeños que se cargan bajo demanda. Audita la cobertura de tu código usando Chrome DevTools para identificar scripts que se cargan pero nunca se ejecutan.
• Carga código no esencial durante el tiempo de inactividad del navegador. ¿Realmente necesitas un widget de chat durante los primeros 500ms de la carga de la página? Programa scripts no críticos con requestIdleCallback() para que se ejecuten solo cuando el navegador esté inactivo.
• Identifica y reescribe scripts lentos que consumen recursos de CPU excesivos. Usa el panel de Rendimiento de Chrome para encontrar scripts con tiempos de ejecución largos y optimízalos.
• Mantén tu página fácil de renderizar. Evita tamaños de DOM grandes, imágenes excesivas, demasiados vídeos y animaciones CSS intensivas en CPU.
• Usa async y defer en las etiquetas script para evitar que JavaScript bloquee el analizador HTML. Considera diferir JavaScript no crítico completamente hasta después de que la página sea interactiva.

Divide las tareas largas con scheduler.yield()

JavaScript se ejecuta en el hilo principal del navegador usando un modelo de "ejecución hasta completar": una vez que una tarea comienza, bloquea el hilo principal hasta que termina. Las tareas largas (más de 50ms) impiden que el navegador responda a la entrada del usuario. La API scheduler.yield() te permite crear explícitamente puntos de yield dentro de código de larga ejecución, dando al navegador la oportunidad de procesar interacciones de usuario pendientes antes de continuar.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Difiere trabajo no crítico con requestIdleCallback

Usa requestIdleCallback() para programar tareas no esenciales (analíticas, telemetría, precarga) para cuando el navegador esté inactivo. Esto mantiene el hilo principal libre para las interacciones del usuario y reduce directamente el input delay.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Usa event listeners pasivos

Para eventos que no necesitan llamar a preventDefault(), marca tus event listeners como pasivos. Esto le dice al navegador que no necesita esperar a que tu manejador decida si cancela el comportamiento predeterminado, permitiendo un desplazamiento más fluido y una respuesta táctil más rápida.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimiza el tiempo de procesamiento: Proporciona retroalimentación inmediata

Cuando un visitante realiza una acción como enviar un formulario o agregar un artículo al carrito, no esperes la confirmación del servidor antes de actualizar la UI. Proporciona retroalimentación visual inmediata ("Enviando tu formulario...", "Agregando artículo al carrito...") y luego completa la operación en segundo plano.

Además, haz yield al hilo principal tan pronto como sea posible después de la actualización visual crítica. Debido a que JavaScript sigue un modelo de "ejecución hasta completar", bloquea el hilo principal hasta que todo el código en el callback se ha ejecutado. Puedes crear manualmente un punto de yield donde el navegador puede actualizar el layout y luego continuar ejecutando el código no crítico restante.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Minimiza el Presentation Delay: Mantén las cosas simples

Cuando la página necesita actualizarse después de una interacción, el navegador debe recalcular estilos, realizar el layout, pintar los píxeles cambiados y componer el resultado. La complejidad y el tamaño de tu DOM determinan directamente cuánto tarda este trabajo de renderizado.

Algunos entornos SPA mal optimizados re-renderizan demasiado contenido después de cada interacción. Por ejemplo, al actualizar un contador, asegúrate de actualizar solo el elemento del contador, no todo el árbol de componentes.

Sigue estas dos reglas de oro para un renderizado más rápido:

1. Mantén el DOM pequeño y simple. Es mucho más fácil para un navegador renderizar una página con menos elementos DOM (nodos HTML) que una página con estructuras DOM profundamente anidadas y complicadas. Apunta a menos de 1.400 elementos DOM en total y evita anidar más de 32 niveles.
2. Usa content-visibility para renderizar de forma diferida el contenido fuera de pantalla. La propiedad CSS content-visibility: auto acelera el renderizado inicial al diferir el renderizado del contenido fuera de pantalla hasta que el usuario se desplace cerca de él.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Depuración del INP con la API Long Animation Frames (LoAF)

La API Long Animation Frames (LoAF) es una herramienta poderosa para diagnosticar problemas de INP. Proporciona información detallada sobre frames que tardan más de 50ms en renderizarse, incluyendo datos de atribución de scripts que te indican exactamente qué scripts están contribuyendo a interacciones lentas.

A diferencia de la antigua API Long Tasks, LoAF captura el tiempo de renderizado así como el tiempo de ejecución de scripts, lo que la hace particularmente útil para diagnosticar problemas de presentation delay. Las entradas LoAF incluyen la duración del frame, la duración de bloqueo y un array de entradas de scripts que muestran la URL fuente, el nombre de la función y el tiempo de ejecución de cada script que se ejecutó durante el frame.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Las herramientas RUM como CoreDash integran datos LoAF automáticamente, correlacionando frames de animación largos con interacciones específicas del usuario para que puedas identificar exactamente qué script, en qué página, para qué tipo de interacción, está causando tus peores puntuaciones de INP.

INP y LCP: La conexión de las tareas largas

Las tareas largas en el hilo principal afectan tanto a INP como a Largest Contentful Paint (LCP). Una tarea de JavaScript que bloquea el hilo principal durante 200ms retrasa el procesamiento de eventos (empeorando el INP) y también retrasa al navegador en renderizar el elemento LCP (empeorando el LCP). Cuando optimizas tu hilo principal dividiendo tareas largas, difiriendo JavaScript no crítico y reduciendo el tiempo de ejecución de scripts, mejoras ambas métricas simultáneamente.

Casos de estudio: Mejoras de INP en producción

redBus: 80 a 100% de mejora en conversión móvil

redBus, una de las mayores plataformas de venta de billetes de autobús en línea del mundo, invirtió en la optimización de Core Web Vitals en sus mercados globales. Su enfoque en reducir el tiempo de ejecución de JavaScript y optimizar los manejadores de eventos contribuyó a una mejora del 80 al 100% en las tasas de conversión móvil en sus mercados globales. Las mejoras fueron impulsadas por una combinación de reducción del tiempo de bloqueo del hilo principal, optimización de la carga de scripts de terceros e implementación de code splitting para reducir la cantidad de JavaScript analizado durante el inicio de la página.

Preply: INP de 250ms a 185ms, $200.000 al año en ahorros estimados de SEO

Preply, una plataforma de tutoría de idiomas en línea, mejoró el INP de su página de inicio de aproximadamente 250ms a 185ms y el INP de su página de búsqueda de aproximadamente 250ms a 175ms. El equipo logró estas ganancias perfilando su aplicación React, identificando y eliminando re-renderizados innecesarios, y difiriendo callbacks de eventos no críticos. Las puntuaciones mejoradas de Core Web Vitals se correlacionaron con rankings de búsqueda más altos, traduciéndose en un valor estimado de $200.000 al año en búsqueda orgánica.

Qué muestran los datos del mundo real sobre INP

La brecha de INP entre móvil y escritorio

Los datos de CoreDash revelan que el INP en móvil (131ms en p75) es 2,8 veces peor que el INP en escritorio (48ms en p75). Esta es la mayor brecha entre dispositivos de cualquier métrica de Core Web Vitals. Los dispositivos móviles tienen procesadores más lentos, menos memoria y mayor latencia de red, todo lo cual contribuye a tiempos de bloqueo del hilo principal más largos y un procesamiento de eventos más lento. En escritorio, el 95,6% de las interacciones logran una puntuación de INP "buena", mientras que en móvil esa cifra cae al 88,0%. Los usuarios móviles también experimentan 5 veces más eventos INP "deficientes" (9,6% vs 1,9%).

Interacciones de teclado vs puntero

Los datos de CoreDash muestran que las interacciones de teclado (75ms p75) son un 56% más lentas que las interacciones de puntero (49ms p75). Los eventos de teclado también tienen significativamente más experiencias deficientes: el 7,4% de las interacciones de teclado resultan en un INP deficiente, comparado con solo el 1,4% para interacciones de puntero. Esta brecha se debe probablemente a que los eventos de teclado, especialmente en campos de formulario, desencadenan un procesamiento más complejo como validación de entrada, sugerencias de autocompletado y actualizaciones de estado.

Interacciones durante la carga vs después de la carga

Las interacciones que ocurren durante la carga de la página tienen un INP dramáticamente más alto que las que ocurren después de que la página se ha cargado completamente. Los datos de CoreDash muestran que las interacciones durante la fase de "carga" tienen un INP p75 de 132ms, comparado con solo 50ms para interacciones post-carga. Eso es una diferencia de 2,6 veces. Incluso las interacciones durante la fase "dom-content-loaded" (75ms) muestran un INP elevado porque los scripts asíncronos y sub-recursos aún se están procesando. Estos datos respaldan fuertemente la recomendación de diferir JavaScript no crítico para reducir la contención del hilo principal durante el inicio de la página.

Tasas globales de aprobación de INP

Según el Web Almanac 2025 de HTTP Archive, el 77% de todas las páginas móviles logran una puntuación de INP "buena" (frente al 55% en 2022). Sin embargo, solo el 53% de los 1.000 sitios web más visitados aprueban INP. Los sitios web de alto tráfico tienden a tener JavaScript más complejo, más scripts de terceros y estructuras DOM más intrincadas, todo lo cual contribuye a una peor capacidad de respuesta. En escritorio, el 97% de las páginas logran buenas puntuaciones de INP, destacando la enorme brecha de rendimiento entre móvil y escritorio. El Total Blocking Time mediano en pruebas de laboratorio es de 67ms en escritorio pero 1.209ms en móvil.

Preguntas frecuentes

Guías relacionadas

Esta página principal cubre los fundamentos de Interaction to Next Paint. Para orientación en profundidad sobre aspectos específicos de la optimización de INP, explora estos artículos dedicados:

• <strong>Encuentra y corrige problemas de INP</strong>: Una metodología de diagnóstico paso a paso usando Search Console, datos RUM y Chrome DevTools para identificar exactamente qué interacciones están causando tus peores puntuaciones de INP.
• <strong>INP Input Delay</strong>: Cubre la primera fase de INP. Aprende cómo las tareas largas en el hilo principal bloquean el procesamiento de eventos y cómo minimizar el input delay con programación de tareas, code splitting y web workers.
• <strong>INP Tiempo de procesamiento</strong>: Cubre la segunda fase de INP. Aprende cómo optimizar los callbacks del manejador de eventos, priorizar código crítico, diferir trabajo no esencial y usar las características de concurrencia de React para reducir el tiempo de procesamiento.
• <strong>INP Presentation Delay</strong>: Cubre la tercera fase de INP. Aprende cómo el tamaño del DOM, el layout thrashing y el renderizado del lado del cliente contribuyen a actualizaciones visuales lentas y cómo reducir el presentation delay.

También puedes encontrar útiles estas guías de optimización de PageSpeed para mejorar el INP:

• Mejorar el INP: Elimina el desplazamiento con JavaScript
• Async vs Defer: Estrategias de carga de JavaScript
• 14 métodos para diferir JavaScript
• Widget de chat con Core Web Vitals perfectos
• Solución: Evitar tamaño excesivo del DOM