INP Presentation Delay: tamaño del DOM, trabajo de layout y optimización del renderizado

Problemas de Interaction to Next Paint (INP) causados por el Presentation Delay

Esta página forma parte de nuestra serie sobre Interaction to Next Paint (INP). El INP mide el tiempo total desde una interacción del usuario hasta la siguiente actualización visual. El Presentation Delay es la tercera y última fase del INP, después del Input Delay y el Processing Time. Si eres nuevo en INP, lee primero nuestra guía sobre cómo identificar y solucionar problemas de INP.

En resumen: el Interaction to Next Paint (INP) mide cuánto tiempo tarda un usuario en ver un cambio visual en una página después de interactuar con ella. Este INP se puede desglosar en 3 componentes: "Input Delay", "Processing Time" y "Presentation Delay".

El Presentation Delay es el principal contribuyente al INP total, representando en promedio aproximadamente el 42% del tiempo total del INP. Optimizar el pipeline de renderizado y simplificar la estructura HTML es la palanca más importante para mejorar el INP.

Presentation Delay: ¿Alguna vez has hecho clic en un botón y te has preguntado por qué ha tardado un poco de más en verse el resultado? Eso es el Interaction to Next Paint (INP) en acción. El Presentation Delay es el último paso en el proceso de interacción, que se activa después de que se haya procesado tu clic pero antes de que veas cualquier cambio visual.

Entendiendo el Presentation Delay

La presentación es la fase final de una interacción. El Presentation Delay representa el tiempo que tarda el navegador en renderizar las actualizaciones visuales que siguen a la interacción. El Presentation Delay comienza cuando los controladores de eventos para la interacción han terminado de ejecutarse y finaliza cuando se pinta el siguiente frame (que contiene los cambios visuales). El Presentation Delay puede verse afectado por varios factores, incluida la complejidad del layout, el tamaño del DOM y la cantidad de trabajo de renderizado requerido.

El Interaction to Next Paint (INP) se puede desglosar en 3 subpartes: "Input Delay", "Processing Time" y "Presentation Delay".

Presentation Delay y el INP

El Presentation Delay es la última fase del INP. En promedio, el Presentation Delay constituye aproximadamente el 42% del tiempo total del INP, lo que lo convierte en el factor individual que más contribuye a las interacciones lentas.

En CoreDash recopilamos millones de puntos de datos de Core Web Vitals cada hora. Basándonos en esos datos, el Presentation Delay representa el 42% del Interaction to Next Paint. Esto es más que el Processing Time (40%) y significativamente más que el Input Delay (18%). A pesar de ser el mayor contribuyente, el Presentation Delay suele ser la fase más difícil de optimizar porque involucra el pipeline de renderizado del navegador en lugar del código de tu aplicación.

Ejemplo de Presentation Delay: imagina que estás con tu teléfono navegando en un sitio web de e-commerce buscando un par de zapatos nuevos. Tocas la imagen de un producto para ver más detalles. Sin embargo, tu teléfono es un poco antiguo y le cuesta seguir el ritmo. Tocas la imagen (Interacción). El teléfono tarda un tiempo en procesar la solicitud y actualizar la pantalla (Processing Time). El sitio web necesita renderizar la nueva página con la imagen más grande y los detalles. Finalmente, transcurre una cantidad de tiempo perceptible hasta que los nuevos detalles del producto y la imagen aparecen en tu pantalla (Presentation Delay). Este retraso en el INP puede ser frustrante para los usuarios y por eso es importante solucionarlo.

¿Qué causa un Presentation Delay elevado?

El Presentation Delay abarca todo el trabajo que hace el navegador después de que terminan tus controladores de eventos y antes de que los píxeles aparezcan en pantalla. Esto incluye la recalculación de estilos, el cálculo del layout, el pintado y la composición. Varios factores contribuyen a un Presentation Delay elevado:

Tamaño excesivo del DOM

Un DOM grande o profundamente anidado es una de las causas más comunes de un Presentation Delay elevado. Cada vez que el navegador necesita actualizar el estado visual de la página después de una interacción, debe recalcular los estilos, calcular el layout y volver a pintar los elementos afectados. El coste de cada uno de estos pasos escala con el número de nodos del DOM que se ven afectados.

Google recomienda mantener el DOM por debajo de 1.400 elementos, con una profundidad máxima de 32 niveles y no más de 60 elementos secundarios por nodo primario (consulta la auditoría de tamaño del DOM de Lighthouse). Cuando tu DOM supera estos umbrales, el navegador dedica mucho más tiempo a la recalculación de estilos y al cálculo del layout después de cada interacción.

Considera este escenario: un usuario hace clic en un botón que alterna una clase CSS en un elemento contenedor. Si ese contenedor tiene 5.000 nodos descendientes, el navegador debe recalcular los estilos de potencialmente todos ellos, incluso si solo unos pocos elementos cambian visualmente. Esta recalculación de estilos ocurre sincrónicamente antes del siguiente pintado, aumentando directamente el Presentation Delay.

Para técnicas específicas para reducir tu DOM, lee nuestra guía sobre cómo solucionar el tamaño excesivo del DOM.

Trabajo de layout excesivo

El layout (también llamado "reflow") es el proceso en el que el navegador calcula la posición y las dimensiones de cada elemento visible en la página. Después de una interacción que modifica el DOM o cambia las propiedades CSS que afectan a la geometría (width, height, margin, padding, top, left), el navegador debe realizar el layout antes de poder pintar el frame actualizado.

Dos patrones son particularmente perjudiciales para el Presentation Delay:

Forced synchronous layout ocurre cuando JavaScript lee una propiedad de layout (como offsetHeight o getBoundingClientRect()) después de realizar un cambio en el DOM que invalida el layout. El navegador se ve obligado a realizar el layout de forma sincrónica, dentro de tu controlador de eventos, para devolver un valor preciso. Este trabajo de layout se convierte entonces en parte del Processing Time, pero cualquier layout posterior provocado por nuevos cambios en el DOM se convierte en parte del Presentation Delay.

Layout thrashing es el patrón repetido de escribir en el DOM y luego leer propiedades de layout en un bucle. Cada lectura obliga al navegador a recalcular el layout, y cada escritura vuelve a invalidar el layout. Esto puede causar docenas o incluso cientos de cálculos de layout innecesarios por interacción. Aquí tienes un ejemplo de layout thrashing y cómo solucionarlo:

// MAL: Layout thrashing dentro de un bucle
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Lectura (fuerza el layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Escritura (invalida el layout)
    item.style.width = parentWidth + 'px';
  });
}

// BIEN: Lecturas por lotes, luego escrituras por lotes
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Leer todos los valores primero
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Luego escribir todos los valores
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Renderizado del lado del cliente en Single Page Applications

El renderizado del lado del cliente de HTML puede afectar significativamente al Presentation Delay, particularmente en las Single Page Applications (SPA). Cuando una interacción del usuario activa un cambio de ruta o una actualización importante de la interfaz de usuario, el framework de la SPA debe:

1. Ejecutar el algoritmo de diferenciación del DOM virtual para determinar qué ha cambiado
2. Aplicar las mutaciones del DOM resultantes al DOM real
3. Activar la recalculación de estilos y el layout para todos los elementos afectados
4. Pintar el frame actualizado

En las aplicaciones React, el proceso de reconciliación del DOM virtual forma parte del Processing Time, pero las mutaciones del DOM resultantes y su coste de renderizado caen dentro del Presentation Delay. Cuantos más nodos del DOM produzca tu árbol de componentes, más costosa será la reconciliación y el trabajo de renderizado posterior.

Para mitigar esto en aplicaciones React y Next.js:

• Usa React.memo() para evitar renderizados innecesarios de componentes secundarios que reciben las mismas props.
• Usa useDeferredValue() para los valores que activan renderizados costosos, permitiendo que React priorice las actualizaciones más urgentes.
• Mantén los árboles de componentes poco profundos. Las jerarquías de componentes profundamente anidadas producen un DOM profundamente anidado, lo que aumenta el coste tanto de la reconciliación como del renderizado del navegador.
• Usa librerías de virtualización (como react-window o @tanstack/react-virtual) para listas largas, de modo que el DOM solo contenga los elementos visibles.

Reduciendo el Presentation Delay

Minimizar el tamaño del DOM

La mayor victoria para el Presentation Delay es mantener el DOM pequeño:

• Elimina los elementos HTML no utilizados, especialmente los divs contenedores profundamente anidados.
• Usa la virtualización de listas para listas largas (renderiza solo los elementos visibles más un pequeño margen).
• Aplana las estructuras profundamente anidadas donde sea posible.
• Usa CSS Grid y Flexbox en lugar de divs anidados para el layout.

// Virtualiza listas largas para reducir el tamaño del DOM
// Antes: 10.000 elementos en el DOM

<ul>
  {allItems.map(item => 
     <li key="{item.id}">{item.name}</li>)
   }
</ul>

// Después: solo elementos visibles en el DOM (usando react-window)
import { FixedSizeList } from 'react-window';
<fixedsizelist height="{600}" 
               itemcount="{allItems.length}" 
               itemsize="{50}" width="100%">  
  {({ index, style }) => (
    <div style="{style}">{allItems[index].name}</div>
  )}
</fixedsizelist>

Usar content-visibility para el renderizado diferido de contenido fuera de pantalla

La propiedad CSS content-visibility indica al navegador que omita el renderizado del contenido fuera de pantalla hasta que el usuario se desplace cerca de él. Esto reduce la cantidad de trabajo de renderizado durante las interacciones al limitar el alcance de la recalculación de estilos y el layout a la parte visible de la página.

/* Aplicar content-visibility a secciones por debajo del pliegue */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Aplicar a elementos individuales en listas largas */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

La propiedad contain-intrinsic-size proporciona una altura estimada para que el navegador pueda calcular el tamaño de la barra de desplazamiento correctamente sin renderizar el contenido. Esto evita saltos de layout cuando el usuario se desplaza y el contenido se vuelve visible.

Para más estrategias de optimización de CSS que reduzcan el coste de renderizado, consulta nuestra guía sobre cómo eliminar el CSS no utilizado.

Minimizar el trabajo de layout provocado por las interacciones

Al diseñar interacciones, prefiere las propiedades CSS que no activen el layout. Propiedades como transform y opacity pueden ser manejadas por el compositor de la GPU sin activar el layout o el pintado. En lugar de animar top, left, width o height, usa transform: translate() y transform: scale(). Para obtener la lista completa de propiedades CSS que activan el layout, consulta la guía de rendimiento de renderizado de web.dev.

Usa la propiedad CSS will-change para indicar al navegador que un elemento será animado. Esto permite al navegador crear una capa de composición separada para el elemento, aislando su renderizado del resto de la página:

/* Promover elementos a su propia capa de composición */
.animated-element {
  will-change: transform, opacity;
}

/* Alternar visibilidad con opacity en lugar de display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identificando retrasos prolongados de Presentation Delay

Para identificar retrasos prolongados de Presentation Delay, puedes usar el perfilador de rendimiento de Chrome. Abre DevTools (Ctrl+Shift+I), ve a la pestaña Performance, pulsa grabar e interactúa con la página.

A continuación, puedes analizar la línea de tiempo de una interacción y visualizar las diferentes fases, incluido el Presentation Delay. Al examinar las actualizaciones de renderizado que se producen después de que los controladores de eventos hayan finalizado, puedes identificar cualquier cuello de botella que contribuya a un Presentation Delay prolongado. Busca entradas grandes de "Recalculate Style", "Layout" y "Paint" en la línea de tiempo. Estas representan el trabajo que hace el navegador durante la fase de Presentation Delay.

Identificando el Presentation Delay con datos RUM

Midiendo el Presentation Delay con Long Animation Frames (LoAF)

La API Long Animation Frames (LoAF) muestra exactamente qué causa los retrasos en el renderizado durante las interacciones del usuario. La API te ofrece datos de tiempo para separar el Processing Time del Presentation Delay e identificar qué scripts ralentizan el renderizado.

Las propiedades clave de LoAF para entender el Presentation Delay son:

• renderStart: cuando el navegador comenzó la fase de renderizado (recalculación de estilos, layout, pintado)
• styleAndLayoutStart: cuando comenzó el cálculo de estilos y layout
• duration: duración total del long animation frame
• blockingDuration: cuánto del frame fue bloqueado por scripts

LoAF está actualmente disponible solo en Chromium (Chrome 123+). Para otros navegadores, usa los rastreos del panel Performance de Chrome DevTools para analizar el trabajo de renderizado.

La diferencia entre el final de la ejecución del script y el final del frame representa el coste de renderizado puro, que es el Presentation Delay. Aquí tienes cómo observar y registrar estos datos:

// Medir el Presentation Delay usando la API LoAF
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

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

Las herramientas RUM como CoreDash integran los datos de LoAF y te muestran qué scripts y cambios en el DOM causan retrasos en el renderizado, con una atribución completa de los scripts.

Explora las otras fases del INP

Para tener tu INP bajo control, aborda también las otras dos fases:

• Input Delay: minimiza el tiempo de espera antes de que los controladores de eventos comiencen a ejecutarse. El Input Delay suele ser la fase más pequeña, pero aumenta durante el inicio de la página cuando el hilo principal está ocupado.
• Processing Time: optimiza el código del controlador de eventos que se ejecuta durante la interacción. En la mayoría de las páginas, aquí es donde rinde el grueso de tu esfuerzo de optimización.

Para un flujo de trabajo de diagnóstico completo, consulta nuestra guía sobre cómo identificar y solucionar problemas de INP. Para estrategias adicionales de optimización del renderizado, explora nuestras guías sobre cómo solucionar el tamaño excesivo del DOM y cómo eliminar el CSS no utilizado. Regresa a la página principal de INP para obtener una visión general completa.