Présentation de Scheduler.yield() : la dernière API de Chrome pour optimiser l'INP
Publié: 2023-09-15Il ne fait aucun doute que Google mise avant tout sur la réactivité en 2023.
Jusqu'à présent, ils :
- Interaction déplacée vers Next Paint d’expérimental à en attente ;
- Annonce qu'INP remplacera First Input Delay en tant que nouvelle mesure Core Web Vital pour la réactivité en mars 2024 ;
- Nous avons commencé à signaler les problèmes INP dans la Search Console et à envoyer des e-mails aux sites Web qui ne satisfont pas au seuil de bonne réactivité.
Désormais, l'équipe Chrome a annoncé qu'elle exécutait actuellement un essai d'origine pour une nouvelle API de planificateur – programmer.yield() .
Scheduler.yield() devrait aider les développeurs à améliorer la réactivité de leurs sites en leur fournissant un moyen plus simple et plus efficace de redonner le contrôle au thread principal.
Lisez la suite pour en savoir plus sur la nouvelle API et comment l'essayer sur votre site Web.
Un récapitulatif rapide des tâches longues et du fil principal
Si vous connaissez bien les tâches longues et le fil conducteur, n'hésitez pas à ignorer cette partie. Sinon, nous vous encourageons à lire ce rapide récapitulatif car il est fondamental pour comprendre Scheduler.yield() et comment l'implémenter.
Tout ce que le navigateur fait comme travail est considéré comme une tâche. Cela inclut le rendu, l'analyse HTML et CSS, l'exécution du code JavaScript que vous écrivez et d'autres choses sur lesquelles vous n'avez peut-être pas de contrôle direct.
Le fil principal est l’endroit où le navigateur effectue la majeure partie du travail.
Malheureusement, le thread principal ne peuttraiter qu'une seule tâche à la fois .Et si une tâche prend plus de 50 ms pour s’exécuter, elle est considérée comme une tâche longue.
Rencontrer une tâche longue signifie que le navigateur l'exécutera aussi longtemps que nécessaire pour la terminer. Une fois terminé, le contrôle est rendu au thread principal, permettant au navigateur de traiter la tâche suivante dans la file d'attente.
Les tâches longues sont la principale source de mauvaise réactivité des pages, car elles retardent la capacité du navigateur à répondre aux entrées de l'utilisateur. De plus, JavaScript, avec son modèle d'exécution jusqu'à la fin, est le principal responsable du blocage du thread principal.
C'est pourquoi elle est considérée comme une ressource bloquant le rendu : lorsque le navigateur la rencontre, il doit la télécharger, l'analyser et l'exécuter avant de faire autre chose.
La bonne nouvelle est que ce n'est pas parce que votre code lance une tâche dans le navigateur que vous devez attendre que cette tâche soit terminée avant que le contrôle soit rendu au thread principal.
Vous pouvez diviser des tâches longues en cédant explicitement dans une tâche.
En termes plus simples, le rendement des tâches garantit que le navigateur ne se laisse pas prendre par une tâche au point de manquer ou de retarder la réponse à d'autres tâches importantes ou interactions utilisateur.
Malheureusement, les stratégies de rendement actuelles ne sont pas parfaites…
Pourquoi Scheduler.yield() : le problème des stratégies de rendement actuelles
Céder au fil conducteur n’est pas un concept nouveau. Les développeurs utilisent depuis un certain temps différentes stratégies de rendement pour diviser les tâches longues :
1. setTimeout()
setTimeout() vous permet de planifier l'exécution d'une tâche après un délai spécifié ou à intervalles réguliers. Cela reporte l'exécution du rappel dans une tâche distincte, même si vous spécifiez un délai d'attente de 0. Cette méthode est efficace lorsque vous disposez de plusieurs fonctions qui doivent s'exécuter les unes après les autres.
Inconvénient : La précision n’est pas garantie. Le rappel peut ne pas s'exécuter exactement après le délai spécifié en raison d'autres tâches dans la file d'attente. De plus, si vous traitez un vaste ensemble de données en boucle, la tâche peut devenir fastidieuse, en particulier avec des millions d'entrées.
2. requestIdleCallback()
requestIdleCallback() vous permet de planifier l'exécution d'une tâche pendant les périodes d'inactivité du navigateur. C'est utile pour effectuer des tâches non urgentes sans affecter l'expérience utilisateur.
Inconvénient : requestIdleCallback() planifie les tâches avec la priorité la plus basse possible, ce qui signifie que si le thread principal est encombré, les tâches planifiées risquent de ne jamais s'exécuter.
3. isInputPending()
isInputPending() peut être exécuté à tout moment pour vérifier si un utilisateur essaie d'interagir avec un élément de la page. Si tel est le cas, la fonction renvoietrue; sinon, il renvoiefalse.
Imaginez que vous ayez une série de tâches à exécuter mais que vous ne souhaitiez pas perturber les interactions des utilisateurs. Vous pouvez utiliser isInputPending() et la fonction rendementToMain() pour garantir que la saisie de l'utilisateur ne soit pas retardée lors de son interaction avec la page.
Inconvénient : isInputPending() peut ne pas toujours renvoyer true immédiatement après la saisie de l'utilisateur. En effet, le système d'exploitation met du temps à informer le navigateur que l'interaction a eu lieu. Cela signifie qu'un autre code a peut-être déjà commencé à s'exécuter.
Ce sont quelques-unes des façons les plus courantes de revenir au fil principal. Comme vous pouvez le constater, chacun a ses propres inconvénients.
Mais l’inconvénient le plus important est le suivant :
Lorsque vous cédez au thread principal en différant l'exécution du code dans une tâche ultérieure, ce code est ajouté à la toute fin de la file d'attente des tâches.
Pourquoi est-ce un problème ?
C'est une triple réponse :
- Risque accru d'erreurs logiques : étant donné que le code différé est placé à la fin de la file d'attente des tâches, le navigateur peut exécuter d'autres tâches avant de revenir à la tâche différée. Cela peut affecter l'ordre dans lequel les fonctions sont exécutées et potentiellement provoquer des erreurs logiques ou un comportement inattendu.
- Retard d'exécution : s'il y a de nombreuses tâches dans la file d'attente, cela peut prendre un certain temps avant que le navigateur atteigne et exécute le code différé.
- Imprévisibilité : il est difficile de prédire avec précision quand la tâche différée sera exécutée, car cela dépend du nombre et de la nature des tâches déjà dans la file d'attente. Cette imprévisibilité peut rendre difficile le débogage et l’optimisation des performances.
En résumé, si l’utilisation des stratégies actuelles pour céder le pas au thread principal peut aider à maintenir une interface utilisateur réactive, elle peut également présenter des défis pour garantir l’exécution opportune et ordonnée du code.
Présentation de planificateur.yield()
L'enthousiasme suscité par Chrome exécutant un essai d'origine pour programmer.yield() est dû au fait qu'il s'agit d'une API de planificateur qui résout tous les inconvénients des autres stratégies de rendement.
En plus de cela, c'est une solution qui permettra aux développeurs et aux propriétaires d'obtenir des sites Web réactifs et de bons scores INP tout en exécutant de manière transparente le reste du code.
Alors, quel est tout ce battage médiatique à propos de programmer.yield() ?
Pour commencer, Scheduler.yield() est une fonction de rendement dédiée. setTimeout(), par exemple, est utilisé pour diviser des tâches longues et céder le pas au thread principal, mais il s'agit plus d'un effet secondaire de fonction que d'une option par défaut.
Deuxièmement, Scheduler.yield() envoie le travail restant au début de la file d'attente. Cela signifie que le travail que vous souhaitez reprendre immédiatement après avoir cédé ne passera pas au second plan par rapport aux tâches provenant d'autres sources.
Mettre tout simplement:
Scheduler.yield() vous offre le meilleur des deux mondes : vous pouvez améliorer la réactivité et le score INP de votre site et vous assurer que le travail que vous vouliez terminer après la production n'est pas retardé.
Comment essayer la nouvelle API du planificateur
À partir de Chrome 115, vous pouvez tester programmer.yield vous-même.
Pour expérimenter la nouvelle API, suivez simplement les instructions de Google :
- Si vous souhaitez expérimenter Scheduler.yield localement, tapez et entrez chrome://flags dans la barre d'adresse de Chrome et sélectionnez Activer dans la liste déroulante de la section Fonctionnalités expérimentales de la plate-forme Web. Cela rendra Scheduler.yield (et toute autre fonctionnalité expérimentale) disponible uniquement dans votre instance de Chrome.
- Si vous souhaitez activer Scheduler.yield pour les vrais utilisateurs de Chromium sur une origine accessible au public, vous devrez vous inscrire à l'essai d'origine Scheduler.yield. Cela vous permet d'expérimenter en toute sécurité les fonctionnalités proposées pendant une période de temps donnée et donne à l'équipe Chrome des informations précieuses sur la manière dont ces fonctionnalités sont utilisées sur le terrain. Pour plus d’informations sur le fonctionnement des essais d’origine, lisez ce guide.
Une fois que vous l’avez testé, vous pouvez également fournir des commentaires sur la manière dont il peut être amélioré.
Tests en toute sécurité !
Comment NitroPack peut aider à débloquer le fil principal
Diviser les tâches longues en morceaux plus petits est essentiel pour offrir aux utilisateurs une expérience rapide.
Mais ne serait-il pas préférable que vous puissiez optimiser de manière préventive une partie du JavaScript lourd ?
C'est là qu'intervient NitroPack.
Avec ses plus de 35 fonctionnalités avancées de performances Web , NitroPack aide plus de 180 000 sites Web dans le monde à atteindre une excellente expérience utilisateur, Core Web Vitals et des taux de conversion.
L'un des avantages les plus significatifs de NitroPack est sa manière de gérer l'exécution de JavaScript.
Lors de l'installation de NitroPack, notre service retarde le chargement des ressources non critiques jusqu'à ce que l'interaction de l'utilisateur soit détectée.
De plus, grâce à notre mécanisme propriétaire de chargement des ressources , NitroPack peut réorganiser la façon dont les ressources sont envoyées au thread principal. Nous faisons cela pour tirer parti de la nature multicœur des processeurs modernes en déchargeant les tâches du thread principal.
De cette façon, nous pouvons garantir que votre fil de discussion principal reste débloqué et disponible pour gérer les interactions des utilisateurs.