Interaction to Next Paint - Presentation Delay
Aprende a encontrar y mejorar problemas de INP causados por el presentation delay

Problemas de Interaction to Next Paint (INP) causados por el presentation delay
En nuestra serie de artículos anteriores hablamos sobre el Interaction to Next Paint y sobre cómo identificar problemas de Interaction to Next Paint. Si deseas repasar los conceptos básicos, ¡este es un excelente lugar para comenzar!
En este artículo me centraré en el 'presentation delay'. Cómo afecta al Interaction to Next Paint y luego explicaré cómo optimizar el presentation delay para mejorar el Interaction to Next Paint.
En resumen: El Interaction to Next Paint (INP) mide cuánto tiempo tarda en verse un cambio visual en una página después de que un usuario ha interactuado 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 aproximadamente el 42% del input delay en promedio. Esto significa que optimizar tu presentación y simplificar el HTML puede impactar significativamente la puntuación de INP de tu sitio web.
Presentation Delay: ¿Alguna vez hiciste clic en un botón y te preguntaste por qué tardó una fracción de segundo de más en ver 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 tu clic ha sido procesado pero antes de que veas cualquier cambio visual.
Table of Contents!
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 event handlers de la interacción han terminado de ejecutarse y finaliza cuando el siguiente frame (que contiene los cambios visuales) es pintado. El presentation delay puede verse afectado por varios factores, incluyendo 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
La presentación es la última fase del INP. En promedio, el presentation delay representa aproximadamente el 42% del tiempo total del INP.

En CoreDash recopilamos millones de datos de Core Web Vitals cada hora. Basándonos en esos datos, el tiempo de Presentation Delay representa el 42% del Interaction to Next Paint.
Presentation delay: Imagina que estás en tu teléfono navegando por un sitio web de comercio electrónico buscando un nuevo par de zapatos. Tocas una imagen de producto para ver más detalles. Sin embargo, tu teléfono es un poco antiguo y le cuesta mantenerse al día. En esta situación, podrías experimentar una métrica de Interaction to Next Paint (INP) deficiente. Esto es lo que está sucediendo: 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 obtener la información adicional del producto y renderizar la nueva página con la imagen más grande y los detalles (Esto puede ser más lento debido a factores como una conexión a internet lenta o una página de producto compleja con muchos elementos). Finalmente, tarda una cantidad notable de tiempo en que los nuevos detalles del producto y la imagen aparezcan en tu pantalla (Presentation Delay). Este retraso en el INP puede ser frustrante para los usuarios y por eso es importante solucionarlo.
Reduciendo el Presentation Delay
Minimizar el presentation delay es a menudo necesario para pasar la métrica de Interaction to Next Paint (INP) y mantener tu página responsiva. Una estrategia efectiva es minimizar el tamaño del Document Object Model (DOM). Un DOM más pequeño generalmente lleva a tiempos de renderizado más rápidos, ya que el navegador tiene menos contenido que procesar y actualizar. Los desarrolladores deberían esforzarse por mantener el DOM pequeño y simple, usando técnicas como la carga diferida de contenido fuera de pantalla con la propiedad content-visibility. Además, es importante ser consciente de la cantidad de trabajo de layout que desencadena una interacción. Un trabajo de layout excesivo puede aumentar significativamente el presentation delay, llevando a una user experience menos responsiva.
El renderizado del lado del cliente de HTML también puede impactar el presentation delay, particularmente en las Single Page Applications (SPAs). Cuando el HTML se crea dinámicamente en el lado del cliente usando JavaScript, puede resultar en tareas largas que bloquean el hilo principal, potencialmente retrasando la presentación del siguiente frame. Los desarrolladores deberían considerar cuidadosamente las implicaciones de rendimiento del renderizado del lado del cliente y esforzarse por minimizar la cantidad de HTML generado dinámicamente.
Identificando Presentation Delays Largos
Para identificar presentation delays largos puedes usar el perfilador de rendimiento de Chrome. Abre devtools (Ctrl-shift-i), navega a la pestaña de rendimiento, presiona grabar e interactúa con la página.,
Ahora puedes analizar la línea de tiempo de una interacción y visualizar las diferentes fases, incluyendo el presentation delay. Al examinar las actualizaciones de renderizado que ocurren después de que los event handlers han finalizado, puedes identificar cualquier cuello de botella que contribuya a un presentation delay largo.

Identificando el Presentation delay con datos de RUM
Más información sobre las causas del presentation delay con Long Animation Frames
La API de 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. Esta API expone tiempos y otros datos que pueden ayudar a los desarrolladores a identificar causas específicas de interacciones lentas y optimizar su código en consecuencia. Las herramientas de RUM como CoreDash proporcionan soporte para LoAF y ofrecen información adicional sobre los long animation frames, como datos de atribución de scripts. Estas herramientas pueden ayudar a los desarrolladores a entender qué scripts están contribuyendo a los retrasos de renderizado y optimizar su base de código para una mejor capacidad de respuesta.
CrUX data is 28 days late.
Google provides data 28 days late. CoreDash provides data in real-time. Debug faster.
- Real-Time Insights
- Faster Debugging
- Instant Feedback

