Presentamos Scheduler.yield(): la API más nueva de Chrome para optimizar INP
Publicado: 2023-09-15No hay duda de que Google se centrará en la capacidad de respuesta en 2023.
Hasta ahora, ellos:
- Se movió Interacción a Siguiente pintura de experimental a pendiente;
- Anunció que INP reemplazará el retraso de la primera entrada como la nueva métrica Core Web Vital para la capacidad de respuesta en marzo de 2024;
- Comencé a marcar problemas de INP en Search Console y a enviar correos electrónicos a sitios web que no alcanzan el umbral de buena capacidad de respuesta.
Ahora, el equipo de Chrome anunció que actualmente están ejecutando una prueba de origen para una nueva API de programación: Scheduler.yield() .
Se espera que Scheduler.yield() ayude a los desarrolladores a mejorar la capacidad de respuesta de sus sitios brindándoles una manera mejor y más fácil de devolver el control al hilo principal.
Continúe leyendo para obtener más información sobre la nueva API y cómo probarla en su sitio web.
Un resumen rápido de las tareas largas y el hilo principal
Si conoce bien las tareas largas y el hilo principal, no dude en saltarse esta parte. De lo contrario, le recomendamos que lea este resumen rápido, ya que es fundamental para comprender Scheduler.yield() y cómo implementarlo.
Todo lo que el navegador hace como trabajo se considera una tarea. Esto incluye renderizar, analizar HTML y CSS, ejecutar el código JavaScript que escribe y otras cosas sobre las que quizás no tenga control directo.
El hilo principal es donde el navegador hace la mayor parte del trabajo.
Desafortunadamente, el hilo principalsólo puede procesar una tarea a la vez .Y si una tarea tarda más de 50 ms en ejecutarse, se considera una tarea larga.
Encontrar una tarea larga significa que el navegador la ejecutará tanto tiempo como sea necesario para completarla. Una vez finalizado, el control vuelve al hilo principal, lo que permite al navegador procesar la siguiente tarea en la cola.
Las tareas largas son la principal fuente de mala capacidad de respuesta de la página porque retrasan la capacidad del navegador para responder a las entradas del usuario. Además, JavaScript, con su modelo de ejecución hasta su finalización, es el principal culpable cuando se trata de bloquear el hilo principal.
Es por eso que se considera un recurso que bloquea el procesamiento: cuando el navegador lo encuentra, debe descargarlo, analizarlo y ejecutarlo antes de hacer cualquier otra cosa.
La buena noticia es que sólo porque su código inicie una tarea en el navegador no significa que tenga que esperar hasta que finalice esa tarea antes de que el control regrese al hilo principal.
Puede dividir tareas largas cediendo explícitamente en una tarea.
En términos más simples, la entrega de tareas garantiza que el navegador no quede tan atrapado en una tarea que omita o retrase la respuesta a otras tareas importantes o interacciones del usuario.
Desafortunadamente, las estrategias de rendimiento actuales no son perfectas...
Por qué Scheduler.yield(): el problema con las estrategias de rendimiento actuales
Ceder al hilo principal no es un concepto nuevo. Los desarrolladores han estado utilizando diferentes estrategias de rendimiento para dividir tareas largas durante bastante tiempo:
1. establecer tiempo de espera()
setTimeout() le permite programar una tarea para que se ejecute después de un retraso específico o en intervalos regulares. Esto pospone la ejecución de la devolución de llamada en una tarea separada, incluso si especifica un tiempo de espera de 0. Este método es efectivo cuando tiene varias funciones que deben ejecutarse una tras otra.
Desventaja: La precisión no está garantizada. Es posible que la devolución de llamada no se ejecute exactamente después del retraso especificado debido a otras tareas en la cola. Además, si está procesando un gran conjunto de datos en un bucle, la tarea podría llevar mucho tiempo, especialmente con millones de entradas.
2. solicitarIdleCallback()
requestIdleCallback() le permite programar una tarea para que se ejecute durante cualquier período de inactividad que pueda tener el navegador. Es útil para realizar tareas no urgentes sin afectar la experiencia del usuario.
Desventaja: requestIdleCallback() programa tareas con la prioridad más baja posible, lo que significa que si el hilo principal está congestionado, es posible que las tareas programadas nunca lleguen a ejecutarse.
3. estáInputPending()
isInputPending() se puede ejecutar en cualquier momento para comprobar si un usuario está intentando interactuar con un elemento de la página. Si es así, la función devuelveverdadero; si no, devuelvefalso.
Imagine que tiene una serie de tareas que ejecutar pero no quiere interrumpir las interacciones de los usuarios. Puede utilizar isInputPending() y la función yieldToMain() para garantizar que la entrada del usuario no se retrase mientras interactúa con la página.
Desventaja: Es posible que isInputPending() no siempre devuelva verdadero inmediatamente después de la entrada del usuario. Esto se debe a que el sistema operativo necesita tiempo para informarle al navegador que se produjo la interacción. Esto significa que es posible que ya se haya comenzado a ejecutar otro código.
Estas son algunas de las formas populares de volver al hilo principal. Como puedes ver, cada uno tiene sus propios inconvenientes.
Pero la desventaja más importante es que:
Cuando cedes al hilo principal al diferir el código para que se ejecute en una tarea posterior, ese código se agrega al final de la cola de tareas.
¿Por qué es eso un problema?
Es una respuesta triple:
- Mayor probabilidad de errores lógicos: dado que el código diferido se coloca al final de la cola de tareas, puede haber otras tareas que el navegador ejecute antes de volver a la tarea diferida. Esto puede afectar el orden en el que se ejecutan las funciones y potencialmente provocar errores lógicos o comportamientos inesperados.
- Retraso en la ejecución : si hay muchas tareas en la cola, puede pasar una cantidad significativa de tiempo antes de que el navegador alcance y ejecute el código aplazado.
- Imprevisibilidad: es difícil predecir con precisión cuándo se ejecutará la tarea aplazada, ya que depende de la cantidad y la naturaleza de las tareas que ya están en la cola. Esta imprevisibilidad puede dificultar la depuración y la optimización del rendimiento.
En resumen, si bien el uso de las estrategias actuales para ceder el paso al hilo principal puede ayudar a mantener una interfaz de usuario receptiva, también puede presentar desafíos para garantizar la ejecución oportuna y ordenada del código.
Presentando planificador.yield()
El entusiasmo por que Chrome ejecute una prueba de origen para Scheduler.yield() se debe a que es una API de programación que soluciona todos los inconvenientes de las otras estrategias de rendimiento.
Además de eso, es una solución que permitirá tanto a los desarrolladores como a los propietarios lograr sitios web receptivos y buenos puntajes INP mientras ejecutan sin problemas el resto del código.
Entonces, ¿a qué se debe tanto revuelo sobre Scheduler.yield() ?
Para empezar, Scheduler.yield() es una función de rendimiento dedicada. setTimeout(), por ejemplo, se utiliza para dividir tareas largas y ceder el paso al hilo principal, pero es más un efecto secundario de la función que una opción predeterminada.
En segundo lugar, Scheduler.yield() envía el trabajo restante al frente de la cola. Esto significa que el trabajo que desea reanudar inmediatamente después de ceder no quedará relegado a tareas de otras fuentes.
En pocas palabras:
Scheduler.yield() le ofrece lo mejor de ambos mundos: puede ceder para mejorar la capacidad de respuesta y la puntuación INP de su sitio y asegurarse de que el trabajo que desea terminar después de ceder no se retrase.
Cómo probar la nueva API del programador
A partir de Chrome 115, puedes probar Scheduler.yield por tu cuenta.
Para experimentar con la nueva API, simplemente siga las instrucciones de Google:
- Si desea experimentar con Scheduler.yield localmente, escriba e ingrese chrome://flags en la barra de direcciones de Chrome y seleccione Habilitar en el menú desplegable en la sección Funciones de plataforma web experimentales. Esto hará que Scheduler.yield (y cualquier otra función experimental) esté disponible solo en su instancia de Chrome.
- Si desea habilitar Scheduler.yield para usuarios reales de Chromium en un origen de acceso público, deberá registrarse para la prueba de origen de Scheduler.yield. Esto le permite experimentar de forma segura con las funciones propuestas durante un período de tiempo determinado y le brinda al equipo de Chrome información valiosa sobre cómo se utilizan esas funciones en el campo. Para obtener más información sobre cómo funcionan las pruebas de origen, lea esta guía.
Una vez que lo pruebes, también podrás proporcionar comentarios sobre cómo se puede mejorar.
¡Pruebas seguras!
Cómo NitroPack puede ayudar a desbloquear el hilo principal
Dividir tareas largas en partes más pequeñas es esencial para brindar a los usuarios una experiencia ágil.
¿Pero no sería mejor si pudieras optimizar de forma preventiva parte del JavaScript pesado?
Ahí es donde entra en juego NitroPack.
Con sus más de 35 funciones avanzadas de rendimiento web , NitroPack ayuda a más de 180 000 sitios web en todo el mundo a lograr una excelente experiencia de usuario, Core Web Vitals y tasas de conversión.
Una de las ventajas más importantes de NitroPack es su forma de manejar la ejecución de JavaScript.
Al instalar NitroPack, nuestro servicio retrasa la carga de recursos no críticos hasta que se detecta la interacción del usuario.
Además, gracias a nuestro mecanismo patentado de carga de recursos , NitroPack puede reorganizar la forma en que los recursos se envían al hilo principal. Hacemos esto para aprovechar la naturaleza multinúcleo de la CPU moderna al descargar tareas fuera del hilo principal.
De esta manera, podemos garantizar que su hilo principal permanezca desbloqueado y disponible para manejar las interacciones de los usuarios.