Cela se produit lorsque Blink (le moteur de rendu de Chrome) décide de retarder l'exécution d'une minuterie (comme une fonction passée à la fonction requestAnimationFrame , setTimeout o setInterval ) parce que l'exécution de ces fonctions prend généralement plus de 50 ms. et il y a une entrée tactile de l'utilisateur. Il s'agit de donner la priorité à la gestion des entrées de l'utilisateur (comme les défilements et les tapotements) plutôt qu'à l'activité du site.
Si vous avez rencontré ce message, il est probable que vos utilisateurs obtiennent un comportement similaire. Voici comment se reproduire ce scénario :
- Avoir un javascript à long terme qui est déclenché par des minuteries.
- Être sur mobile (ou l'émuler avec le mode appareil de DevTools)
- L'entrée tactile, le défilement avec le doigt vers le bas sur l'écran est le plus fiable. Taper sur la page ou la jeter peut aussi la déclencher, mais c'est moins probable et plus difficile à reproduire.
- Les outils expérimentaux de devtools Etranglement du CPU fera durer le JS plus longtemps et vous donnera plus de chances de le voir.
La méthode pour comment résoudre Ceci est directement issu de la question référencée dans le message de la console dans le commentaire 40 :
- Enregistrez une ligne de temps sur la page qui déclenche le message de la console concernant le report.
- Sélectionnez toute la timeline et ouvrez le volet "Journal des événements" en bas de la fenêtre.
- Entrez "Timer Fired" dans le champ de texte du filtre. (Voir l'image en bas)
- Recherchez dans la liste les minuteurs dont le "Temps total" dépasse 50 millisecondes. Ce sont ceux qui posent problème. (Notez que les temporisateurs qui dépassent 10 millisecondes peuvent également déclencher ce message dans certains cas où le navigateur traite un geste de l'utilisateur. )
Vous souhaitez que ces fonctions s'exécutent plus rapidement ou moins fréquemment.
![Timer fired filter on timeline]()
