Deferred long-running timer task(s) to improve scrolling smoothness

This occurs when Blink (Chrome’s rendering engine) decides to delay executing a timer (like a function passed to requestAnimationFrame, setTimeout, or setInterval) because those functions are generally taking >50ms to execute and there is user touch input. It’s done to prioritize handling user input (like scrolls and taps) above what the site is doing.

If you’ve encountered this message, then its likely your users will get similar behavior. Here’s how to reproduce this scenario:

  1. Have long-running javascript that is triggered via timers
  2. Be on mobile (or emulating it with DevTools device mode)
  3. Have touch input, scrolling with finger down on the screen is the most reliable. Tapping or flinging the page may also trigger it, but it is less likely and harder to reproduce.
  4. The devtools’ experimental CPU throttling will make the JS take longer and give you a better chance of seeing it.

The method for how to solve this is directly from the referenced issue in the console message down in comment 40:

  1. Record a timeline on the page that is triggering the console message about deferral.
  2. Select the entire timeline and open the “Event Log” pane near the bottom of the window.
  3. Enter “Timer Fired” into the filter text field. (See image at bottom)
  4. Look for timers in the list whose “Total Time” exceeds 50 milliseconds. These are the problematic ones. (Note that timers that exceed 10 milliseconds can also trigger this message in some cases where the browser is processing a user gesture. )

You want these functions to execute faster or less frequently.

Timer fired filter on timeline

Leave a Comment

tech