Obtén información para optimizar la interacción a la siguiente pintura de tu sitio web.
La Interacción a la siguiente pintura (INP) es una métrica de métricas web esenciales pendiente que evalúa la capacidad de respuesta general de una página ante las interacciones del usuario mediante la observación de la latencia de todas las interacciones calificadas que ocurren durante la vida útil de la visita del usuario a una página. El valor de INP final es la interacción más larga que se observa (a veces, se ignoran los valores atípicos).
Para brindar una buena experiencia del usuario, los sitios web deben esforzarse por tener una interacción a la siguiente pintura de 200 milisegundos o menos. Para asegurarte de alcanzar este objetivo para la mayoría de los usuarios, un buen umbral para medir es el percentil 75 de las cargas de páginas, segmentados entre dispositivos móviles y computadoras de escritorio.
Según el sitio web, es posible que haya pocas interacciones o ninguna. Por ejemplo, páginas que contienen principalmente texto e imágenes con pocos elementos interactivos o ninguno. O, en el caso de sitios web, como los editores de texto o los juegos, podría haber cientos, o incluso miles, de interacciones. En cualquier caso, cuando el INP es alto, la experiencia del usuario está en riesgo.
Mejorar INP requiere tiempo y esfuerzo, pero la recompensa ofrece una mejor experiencia del usuario. En esta guía, se explorará una ruta para mejorar el INP.
Averigua cuál es la causa de un INP deficiente
Para poder corregir las interacciones lentas, necesitarás datos que te indicarán si el INP de tu sitio web es deficiente o requiere mejoras. Una vez que tengas esa información, podrás avanzar al lab para comenzar a diagnosticar interacciones lentas y trabajar para encontrar una solución.
Busque interacciones lentas en el campo
Idealmente, tu recorrido para optimizar el INP comenzará con los datos de campo. En el mejor de los casos, los datos de campo de un proveedor de supervisión de usuarios reales (RUM) te proporcionarán no solo el valor de INP de una página, sino también datos contextuales que destacan qué interacción específica fue responsable del valor de INP en sí, si la interacción ocurrió durante o después de la carga de la página, el tipo de interacción (clic, pulsación de tecla o toque) y otra información valiosa.
Si no dependes de un proveedor de RUM para obtener datos de campos, en la guía de datos del campo de INP, te recomendamos que uses el Informe sobre la experiencia del usuario en Chrome (CrUX) a través de PageSpeed Insights para llenar los vacíos. CrUX es el conjunto de datos oficial del programa de Métricas web esenciales y proporciona un resumen de alto nivel de las métricas de millones de sitios web, incluido el INP. Sin embargo, a menudo, CrUX no proporciona los datos contextuales que obtendrías de un proveedor de RUM para ayudarte a analizar los problemas. Por este motivo, recomendamos que los sitios usen un proveedor de RUM siempre que sea posible, o que implementen su propia solución de RUM para complementar lo que está disponible en CrUX.
Cómo diagnosticar interacciones lentas en el lab
Idealmente, le recomendamos que comience a realizar pruebas en el lab una vez que tenga datos de campo que sugieran que sus interacciones son lentas. Ante la ausencia de datos de campo, existen algunas estrategias para identificar interacciones lentas en el lab. Estas estrategias incluyen seguir flujos de usuarios comunes y probar interacciones a lo largo del proceso, así como interactuar con la página durante la carga (cuando el subproceso principal suele estar más activo) para mostrar interacciones lentas durante esa parte crucial de la experiencia del usuario.
Optimizar las interacciones
Una vez que identifiques una interacción lenta y puedas reproducirla manualmente en el lab, el siguiente paso es optimizarla. Las interacciones se pueden dividir en tres fases:
- La demora de entrada, que comienza cuando el usuario inicia una interacción con la página y finaliza cuando comienzan a ejecutarse las devoluciones de llamada del evento para la interacción.
- El tiempo de procesamiento, que consiste en el tiempo que tardan en ejecutarse las devoluciones de llamada de eventos hasta completarse.
- La demora en la presentación, que es el tiempo que tarda el navegador en presentar el siguiente fotograma que contiene el resultado visual de la interacción.
La suma de estas tres fases es la latencia total de las interacciones. Cada fase de una interacción contribuye en cierta cantidad de tiempo a la latencia total de la interacción, por lo que es importante saber cómo optimizar cada parte de la interacción para que se ejecute el menor tiempo posible.
Cómo identificar y reducir el retraso de entrada
Cuando un usuario interactúa con una página, la primera parte de esa interacción es el retraso de entrada. Según otras actividades en la página, las demoras en las entradas pueden ser considerables. Esto podría deberse a la actividad que tiene lugar en el subproceso principal (tal vez debido a la carga, el análisis y la compilación de secuencias de comandos), el manejo de recuperaciones, las funciones de temporizador o incluso a partir de otras interacciones que ocurren en sucesión rápida y se superponen entre sí.
Cualquiera sea la fuente del retraso de entrada de una interacción, te recomendamos que lo reduzcas al mínimo para que las interacciones puedan comenzar a ejecutar devoluciones de llamada de eventos lo antes posible.
La relación entre la evaluación de la secuencia de comandos y las tareas largas durante el inicio
Un aspecto crítico de la interactividad en el ciclo de vida de la página es durante el inicio. Cuando una página se cargue, inicialmente se renderizará, pero es importante recordar que el hecho de que se haya renderizado la página no significa que terminó de cargarse. Según la cantidad de recursos que necesite una página para que funcione por completo, es posible que los usuarios intenten interactuar con ella mientras se está cargando.
Un factor que puede extender el retraso de entrada de una interacción mientras se carga una página es la evaluación de la secuencia de comandos. Después de que se ha recuperado un archivo JavaScript de la red, el navegador aún tiene trabajo que hacer antes de que JavaScript se pueda ejecutar; ese trabajo incluye analizar una secuencia de comandos para garantizar que su sintaxis sea válida, compilarla en código de bytes y luego ejecutarla.
Dependiendo del tamaño de una secuencia de comandos, este trabajo puede introducir tareas largas en el subproceso principal, lo que retrasará el navegador responder a otras interacciones del usuario. Para que tu página sea responsiva a las entradas del usuario mientras se carga, es importante que comprendas qué puedes hacer para reducir la probabilidad de que haya tareas largas durante la carga, de modo que esta se mantenga ágil.
Optimiza las devoluciones de llamada de eventos
El retraso de entrada es solo la primera parte de lo que mide el INP. También deberás asegurarte de que las devoluciones de llamada de eventos que se ejecutan en respuesta a una interacción del usuario se puedan completar lo más rápido posible.
cede el paso al subproceso principal con frecuencia
El mejor consejo general para optimizar las devoluciones de llamada de eventos es realizar la menor cantidad de trabajo posible en ellas. Sin embargo, tu lógica de interacción puede ser compleja y solo podrías reducir de forma marginal el trabajo que realizan.
Si crees que este es el caso de tu sitio web, lo siguiente que puedes intentar es dividir el trabajo en devoluciones de llamada de eventos en tareas separadas. Esto evita que el trabajo colectivo se convierta en una tarea larga que bloquea el subproceso principal, lo que permite que otras interacciones que, de lo contrario, estarían esperando que el subproceso principal se ejecuten antes.
setTimeout es una forma de dividir las tareas, ya que la devolución de llamada que se le pasa se ejecuta en una tarea nueva. Puedes usar setTimeout por sí solo o abstraer su uso en una función separada para obtener un rendimiento más ergonómico.
Es preferible ceder el hilo de manera indiscriminada a no hacerlo en absoluto. Sin embargo, hay una forma más matizada de ceder al subproceso principal, que solo incluye la producción inmediatamente después de una devolución de llamada de evento que actualice la interfaz de usuario para que la lógica de renderización pueda ejecutarse antes.
cede para permitir que el trabajo de renderización ocurra antes.
Una técnica de rendimiento más avanzada implica estructurar el código en tus devoluciones de llamada de eventos a fin de limitar lo que se ejecuta solo a la lógica necesaria para aplicar actualizaciones visuales en el siguiente fotograma. Todo lo demás se puede diferir a una tarea posterior. Esto no solo mantiene las devoluciones de llamada ligeras y ágiles, sino que también mejora el tiempo de renderización de las interacciones, ya que no permite que las actualizaciones visuales se bloqueen en el código de devolución de llamada de eventos.
Por ejemplo, imagina un editor de texto enriquecido que da formato al texto a medida que escribes, pero que también actualiza otros aspectos de la IU en respuesta a lo que escribiste (como el recuento de palabras, el resaltado de errores ortográficos y otros comentarios visuales importantes). Además, es posible que la aplicación también deba guardar lo que escribiste para que si te vas y vuelves, no hayas perdido nada.
En este ejemplo, las siguientes cuatro cosas deben suceder en respuesta a los caracteres que escribe el usuario. Sin embargo, solo se debe hacer el primer elemento antes de presentar el siguiente fotograma.
- Actualiza el cuadro de texto con lo que escribió el usuario y aplica el formato que sea necesario.
- Actualiza la parte de la IU que muestra el recuento actual de palabras.
- Ejecuta la lógica para verificar si hay errores ortográficos.
- Guarda los cambios más recientes (ya sea de forma local o en una base de datos remota).
El código para hacer esto podría ser similar al siguiente:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
En la siguiente visualización, se muestra cómo aplazar las actualizaciones no críticas hasta después del siguiente fotograma puede reducir el tiempo de procesamiento y, por lo tanto, la latencia de interacción general.
Si bien el uso de setTimeout() dentro de una llamada a requestAnimationFrame() en el ejemplo de código anterior es un poco esotérico, es un método eficaz que funciona en todos los navegadores para garantizar que el código no crítico no bloquee el siguiente fotograma.
Evita la hiperpaginación de diseños
La hiperpaginación de diseños, a veces llamada diseño sincrónico forzado, es un problema de rendimiento de la renderización en el que el diseño se produce de forma síncrona. Ocurre cuando actualizas estilos en JavaScript y, luego, los lees en la misma tarea. Además, existen muchas propiedades en JavaScript que pueden causar hiperpaginación de diseños.
La hiperpaginación de diseños es un cuello de botella de rendimiento, ya que, cuando se actualizan estilos y luego se solicitan inmediatamente los valores de esos estilos en JavaScript, el navegador se ve obligado a realizar un trabajo de diseño síncrono que, de lo contrario, podría haber esperado para realizarlo de forma asíncrona más adelante, después de que terminan de ejecutarse las devoluciones de llamada de eventos.
Minimizar la demora en la presentación
El retraso de presentación de una marca de interacción abarca desde el momento en que terminan de ejecutarse las devoluciones de llamada de eventos de una interacción hasta el momento en que el navegador puede pintar el siguiente fotograma que muestra los cambios visuales resultantes.
Minimiza el tamaño del DOM
Cuando el DOM de una página es pequeño, el trabajo de renderización suele finalizar rápidamente. Sin embargo, cuando los DOM son muy grandes, el trabajo de representación tiende a escalar a medida que aumenta el tamaño del DOM. La relación entre el trabajo de representación y el tamaño del DOM no es lineal, pero los DOM grandes requieren más trabajo para la renderización que los DOM pequeños. Un DOM de gran tamaño presenta problemas en dos casos:
- Durante la representación inicial de la página, cuando un DOM grande requiere mucho trabajo para representar el estado inicial de la página.
- En respuesta a una interacción del usuario, cuando un DOM de gran tamaño puede hacer que las actualizaciones de representación sean muy costosas y, por lo tanto, aumentar el tiempo que tarda el navegador en presentar el siguiente fotograma.
Ten en cuenta que, en algunos casos, los DOM grandes no se pueden reducir de forma significativa. Si bien existen enfoques que puedes adoptar para reducir el tamaño del DOM, como acoplar tu DOM o agregarlo al DOM durante las interacciones del usuario para mantener pequeño el tamaño inicial de tu DOM, esas técnicas pueden llegar hasta cierto punto.
Usa content-visibility para renderizar de forma diferida elementos fuera de la pantalla
Una forma de limitar la cantidad de trabajo de renderización durante la carga de la página y de procesamiento en respuesta a las interacciones del usuario es recurrir a la propiedad content-visibility de CSS, que en efecto equivale a renderizar elementos de forma diferida a medida que se acercan al viewport. Si bien content-visibility requiere un uso eficaz, vale la pena investigar si el resultado es un tiempo de renderización menor, que puede mejorar el INP de tu página.
Ten en cuenta los costos de rendimiento cuando se renderiza HTML con JavaScript
Cuando hay HTML, se analiza el código HTML y, una vez que el navegador termina de analizar HTML en un DOM, debe aplicarle estilos, realizar cálculos de diseño y, luego, renderizar ese diseño. Este es un costo inevitable, pero la forma en la que se procesa el HTML es importante.
Cuando el servidor envía HTML, este llega al navegador como una transmisión. Transmitir significa que la respuesta HTML del servidor llega en partes. El navegador optimiza la manera en la que maneja una transmisión mediante el análisis gradual de los fragmentos de esa transmisión a medida que llegan y el procesamiento con ellos poco a poco. Esta es una optimización del rendimiento en la que el navegador produce de manera implícita y automática durante la carga de la página, y puedes obtenerla de forma gratuita.
Si bien la primera visita a cualquier sitio web siempre implicará algún nivel de código HTML, un enfoque común comienza con un mínimo de código HTML inicial y, luego, se usa JavaScript para completar el área de contenido. Las actualizaciones posteriores de esa área de contenido también ocurren como resultado de las interacciones del usuario. Por lo general, esto se denomina modelo de aplicación de una sola página (SPA). Una desventaja de este patrón es que, cuando se procesa HTML con JavaScript en el cliente, no solo obtienes el costo de procesamiento de JavaScript para crear ese HTML, sino que también el navegador no genera el rendimiento hasta que haya terminado de analizarlo y renderizarlo.
Sin embargo, es fundamental recordar que incluso los sitios web que no son SPA probablemente implican una cierta cantidad de procesamiento de HTML a través de JavaScript como resultado de las interacciones. Por lo general, no hay problema, siempre y cuando no renderices grandes cantidades de HTML en el cliente, lo que puede retrasar la presentación del siguiente fotograma. Sin embargo, es importante comprender las implicaciones de rendimiento que tiene este enfoque para renderizar HTML en el navegador y cómo puede afectar la capacidad de respuesta de tu sitio web ante la entrada del usuario si renderizas mucho HTML a través de JavaScript.
Conclusión
Mejorar el INP de tu sitio es un proceso iterativo. Cuando corriges una interacción lenta en el campo, es muy probable que, especialmente si tu sitio web proporciona mucha interactividad, comiences a encontrar otras interacciones lentas y también debas optimizarlas.
La clave para mejorar el INP es la persistencia. Con el tiempo, podrás lograr que la capacidad de respuesta de tu página llegue a un lugar en el que los usuarios estén satisfechos con la experiencia que les brindas. También es muy probable que, a medida que desarrollas funciones nuevas para los usuarios, debas realizar el mismo proceso de optimización de las interacciones específicas para ellos. Esto requiere tiempo y esfuerzo, pero también requieren tiempo y esfuerzo.
Hero image de Unsplash, de David Pisnoy y modificada de acuerdo con la licencia de Unsplash.