Retraso de presentación INP: Tamaño del DOM, trabajo de diseño y optimización de renderizado

Problemas de Interaction to Next Paint (INP) causados por el retraso de presentación

Esta página es 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 retraso de presentación es la tercera y última fase del INP, después del retraso de entrada y el tiempo de procesamiento. Si es nuevo en INP, lea primero nuestra guía sobre cómo identificar y solucionar problemas de INP.

En este artículo nos centramos en el retraso de presentación: qué lo causa, cómo afecta al Interaction to Next Paint y cómo optimizarlo para mejorar sus puntuaciones 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: "retraso de entrada", "tiempo de procesamiento" y "retraso de presentación".

El retraso de presentación es el mayor contribuyente al INP total, representando aproximadamente el 42% del tiempo total de INP en promedio. Esto significa que optimizar su canal de renderizado y simplificar su estructura HTML puede tener un impacto significativo en la puntuación INP de su sitio web.

Retraso de presentación: ¿Alguna vez hizo clic en un botón y se preguntó por qué tardó una fracción de segundo en ver el resultado? Eso es el Interaction to Next Paint (INP) en acción. El retraso de presentación es el último paso en el proceso de interacción, que se activa después de que su clic ha sido procesado pero antes de que vea algún cambio visual.

Entendiendo el retraso de presentación

La presentación es la fase final de una interacción. El retraso de presentación representa el tiempo que tarda el navegador en renderizar las actualizaciones visuales que siguen a la interacción. El retraso de presentación comienza cuando los controladores de eventos para la interacción han terminado de ejecutarse y termina cuando se pinta el siguiente fotograma (que contiene los cambios visuales). El retraso de presentación puede verse afectado por varios factores, incluida la complejidad del diseño, 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: "Retraso de entrada", "Tiempo de procesamiento" y "Retraso de presentación".

El retraso de presentación y el INP

El retraso de presentación es la última fase del INP. En promedio, el retraso de presentación constituye aproximadamente el 42% del tiempo total de INP, lo que lo convierte en el mayor contribuyente individual a las interacciones lentas.

En CoreDash recopilamos millones de puntos de datos de Core Web Vitals cada hora. Basándonos en esos datos, el retraso de presentación representa el 42% del Interaction to Next Paint. Esto es más que el tiempo de procesamiento (40%) y significativamente más que el retraso de entrada (18%). A pesar de ser el mayor contribuyente, el retraso de presentación es a menudo la fase más difícil de optimizar porque involucra el canal de renderizado del navegador en lugar de su código de aplicación.

Ejemplo de retraso de presentación: Imagine que está navegando en su teléfono por un sitio web de comercio electrónico buscando un nuevo par de zapatos. Toca una imagen del producto para ver más detalles. Sin embargo, su teléfono es un poco antiguo y le cuesta mantener el ritmo. Usted toca la imagen (Interacción). El teléfono tarda un tiempo en procesar la solicitud y actualizar la pantalla (Tiempo de procesamiento). El sitio web necesita renderizar la nueva página con la imagen más grande y los detalles. Finalmente, toma una cantidad notable de tiempo para que los nuevos detalles del producto y la imagen aparezcan en su pantalla (Retraso de presentación). Este retraso en el INP puede ser frustrante para los usuarios y por eso es importante solucionarlo.

¿Qué causa un alto retraso de presentación?

El retraso de presentación abarca todo el trabajo que hace el navegador después de que terminan sus controladores de eventos y antes de que aparezcan los píxeles en la pantalla. Esto incluye el recálculo de estilo, el cálculo de diseño (layout), la pintura y la composición. Varios factores contribuyen a un alto retraso de presentación:

Gran tamaño del DOM

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

Google recomienda mantener su 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 padre. Cuando su DOM excede estos umbrales, el navegador pasa significativamente más tiempo en el recálculo de estilo y el cálculo de diseño después de cada interacción.

Considere 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 para potencialmente todos ellos, incluso si solo unos pocos elementos cambian visualmente. Este recálculo de estilo ocurre sincrónicamente antes de la siguiente pintura, aumentando directamente el retraso de presentación.

Para técnicas específicas para reducir su DOM, lea nuestra guía sobre solucionar el tamaño excesivo del DOM.

Trabajo de diseño excesivo

El diseño (también llamado "reflow" o redistribución) es el proceso donde 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 la geometría (ancho, alto, margen, relleno, superior, izquierda), el navegador debe realizar el diseño antes de poder pintar el fotograma actualizado.

Dos patrones son particularmente dañinos para el retraso de presentación:

El diseño síncrono forzado ocurre cuando JavaScript lee una propiedad de diseño (como offsetHeight o getBoundingClientRect()) después de realizar un cambio en el DOM que invalida el diseño. El navegador se ve obligado a realizar el diseño sincrónicamente, dentro de su controlador de eventos, para devolver un valor preciso. Este trabajo de diseño se convierte entonces en parte del tiempo de procesamiento, pero cualquier diseño posterior activado por más cambios en el DOM se convierte en parte del retraso de presentación.

El layout thrashing es el patrón repetido de escribir en el DOM y luego leer propiedades de diseño en un bucle. Cada lectura obliga al navegador a recalcular el diseño, y cada escritura invalida el diseño nuevamente. Esto puede causar docenas o incluso cientos de cálculos de diseño innecesarios por interacción. Aquí hay 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 diseño)
    const parentWidth = item.parentElement.offsetWidth;
    // Escritura (invalida el diseño)
    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 Aplicaciones de Página Única (SPA)

El renderizado del lado del cliente de HTML puede impactar significativamente en el retraso de presentación, particularmente en Aplicaciones de Página Única (SPA). Cuando una interacción del usuario activa un cambio de ruta o una actualización grande de la UI, el marco de trabajo de la SPA debe:

1. Ejecutar el algoritmo de diferenciación del DOM virtual para determinar qué cambió
2. Aplicar las mutaciones del DOM resultantes al DOM real
3. Activar el recálculo de estilo y el diseño para todos los elementos afectados
4. Pintar el fotograma actualizado

En aplicaciones React, el proceso de reconciliación del DOM virtual es parte del tiempo de procesamiento, pero las mutaciones del DOM resultantes y su costo de renderizado caen en el retraso de presentación. Cuantos más nodos DOM produzca su á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:

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

Reduciendo el retraso de presentación

Ahora que entendemos las causas, aquí están las estrategias más efectivas para minimizar el retraso de presentación.

Minimizar el tamaño del DOM

La optimización más impactante para el retraso de presentación es mantener su DOM pequeño. Aquí hay técnicas prácticas:

• Elimine elementos HTML no utilizados, especialmente divs contenedores profundamente anidados.
• Use virtualización de listas para listas largas (renderice solo los elementos visibles más un pequeño búfer).
• Aplane las estructuras profundamente anidadas donde sea posible.
• Use CSS Grid y Flexbox en lugar de divs anidados para el diseño.

// Virtualizar 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>

Use content-visibility para renderizar de forma diferida el contenido fuera de pantalla

La propiedad CSS content-visibility le dice 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 del recálculo de estilo y el diseño a la porción visible de la página.

/* Aplicar content-visibility a secciones 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 cambios de diseño cuando el usuario se desplaza y el contenido se vuelve visible.

Para más estrategias de optimización CSS que reducen el costo de renderizado, vea nuestra guía sobre eliminar CSS no utilizado.

Minimizar el trabajo de diseño activado por interacciones

Al diseñar interacciones, prefiera propiedades CSS que no activen el diseño (layout). Propiedades como transform y opacity pueden ser manejadas por el compositor de la GPU sin activar el diseño o la pintura. En lugar de animar top, left, width o height, use transform: translate() y transform: scale().

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

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

/* Alternar visibilidad con opacidad 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 largos retrasos de presentación

Para identificar largos retrasos de presentación puede usar el perfilador de rendimiento de Chrome. Abra DevTools (Ctrl+Shift+I), navegue a la pestaña Performance, presione grabar e interactúe con la página.

Luego puede analizar la línea de tiempo de una interacción y visualizar las diferentes fases, incluyendo el retraso de presentación. Al examinar las actualizaciones de renderizado que ocurren después de que los controladores de eventos han terminado, puede identificar cualquier cuello de botella que contribuya a un largo retraso de presentación. Busque 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 retraso de presentación.

Identificando el retraso de presentación con datos RUM

Midiendo el retraso de presentación con Long Animation Frames (LoAF)

La API Long Animation Frames (LoAF) proporciona información detallada sobre las causas de los retrasos de renderizado, incluyendo aquellos que ocurren durante las interacciones del usuario. La API ofrece datos de tiempo que le ayudan a separar el tiempo de procesamiento del retraso de presentación e identificar qué scripts contribuyen a los cuellos de botella de renderizado.

Las propiedades clave de LoAF para entender el retraso de presentación son:

• renderStart: cuando el navegador comenzó la fase de renderizado (recálculo de estilo, diseño, pintura)
• styleAndLayoutStart: cuando comenzó el cálculo de estilo y diseño
• duration: duración total del fotograma de animación largo
• blockingDuration: cuánto del fotograma fue bloqueado por scripts

La diferencia entre el final de la ejecución del script y el final del fotograma representa el costo puro de renderizado, que es el retraso de presentación. Aquí se muestra cómo observar y registrar estos datos:

// Medir el retraso de presentación 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('Desglose del retraso de presentación:', {
        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 datos de LoAF y proporcionan información adicional sobre los fotogramas de animación largos, como datos de atribución de scripts. Estas herramientas le ayudan a entender qué scripts y cambios en el DOM están contribuyendo a los retrasos de renderizado para que pueda optimizar su código base para una mejor capacidad de respuesta.

Explore las otras fases de INP

El retraso de presentación es solo una parte del Interaction to Next Paint. Para optimizar completamente sus puntuaciones de INP, también debe abordar las otras dos fases:

• Retraso de entrada: Minimice el tiempo de espera antes de que los controladores de eventos comiencen a ejecutarse. El retraso de entrada representa aproximadamente el 18% del tiempo total de INP.
• Tiempo de procesamiento: Optimice la ejecución del controlador de eventos que representa aproximadamente el 40% del tiempo total de INP.

Para un flujo de trabajo de diagnóstico completo, vea nuestra guía sobre cómo encontrar y solucionar problemas de INP. Para estrategias adicionales de optimización de renderizado, explore nuestras guías sobre solucionar el tamaño excesivo del DOM y eliminar CSS no utilizado. Regrese a la página central de INP para ver la descripción completa.