Expose simulated throttling specific requestIdleCallback params

Description

As i was consistently experiencing mediocre TTI Scores in my Applications i started splitting Code and applied the Idle-until-urgent Pattern (using the idlize library Philip Walton, which is using requestIdleCallback under the hood) quite agressively until i had no visible Long Tasks in my Performance Tab. However even after making these optimizations i still experienced TTI Scores above 4s while having FMP Values of about 1.5s.

So i started making some isolated Tests and came to the conclusion that Lighthouse seems to find Long Tasks that are not reflected in the Performance Tab as such. In these isolated Tests this is obviously not a big deal as it is a small HTML Document with a single Script Tag, but in a larger Application this leads to bad TTI Scores which are harming the overall Score and there is no real way to identify and debug them, as they cannot be detected in the Performance Tab.

Provide the steps to reproduce

1. Clone Repository (https://github.com/LukasAuerMstage/lighthouse-tti)
2. Run Lighthouse Audit against the test HTML Page

What is the current behavior?

TTI ist higher than FMP although there are no visible Long Tasks in the Performance Tab. This can be seen in the Lighthouse Result: (FMP 0.6, TTI 0.9) https://github.com/LukasAuerMstage/lighthouse-tti/blob/master/lh-score.PNG Task Timing can be seen in this Screenshot: https://github.com/LukasAuerMstage/lighthouse-tti/blob/master/performance-tab.png or the Performance Profile: https://github.com/LukasAuerMstage/lighthouse-tti/blob/master/Profile-20200502T162332.json

Note: Profile was created with 6 Times CPU Throttling and Slow 3g.

What is the expected behavior?

According to the Specification TTI should be the same as FMP (or DomContentLoaded respectively, whatever fires last) if no Long Tasks were found. As Tasks are split into Chunks that do not exceed the 50ms Limit (about 30ms each), this should be the case.

Further Explanation

This Test Document obviously takes a very naive approach with just scheduling 2 Timeouts while simulating a Sleep for 30ms each but as i stated above i also experienced similar Results in more Complex Environments while structuring similar Chunks of Execution Time in requestIdleCallbacks.

According to my Experience every Chunk of Code that appears to be longer than 20-30ms (while still remaining below 50ms) in the Chrome Performance Tab potentially produces a Long Task under the Hood and therefore ruins the TTI Score.

So as long as i only have 10ms Chunks and i run them sequentially, i can process as many Scripts as i want without risking to produce an unseen Long Task. But as soon as one Chunk somewhere takes about 30ms, my TTI Score gets in the red.

Debugging the issue

I looked a bit into the Lighthouse Code and ran some local Audits while printing out Long Tasks in my console and indeed Lighthouse finds a Long Tasks that is responsible for the Scoring:

node: CPUNode {
    _id: '12440.65069837946',
    _isMainDocument: false,
    _dependents: [],
    _dependencies: [ [CPUNode], [NetworkNode] ],
    _event: {
      args: {},
      cat: 'disabled-by-default-devtools.timeline',
      dur: 30939,
      name: 'RunTask',
      ph: 'X',
      pid: 17420,
      tdur: 30828,
      tid: 12440,
      ts: 65069837946,
      tts: 648811
    },
    _childEvents: [ [Object], [Object], [Object], [Object], [Object], [Object] ]
  },
  endTime: 848.281,
  timing: { startTime: 724.281, endTime: 848.281, duration: 124 }

When printing the Child Events, the output looks as such:

TimerFire
ScheduledAction::execute
v8.callFunction
FunctionCall
V8.Execute
UpdateCounters

Specification (TTI)

Find a the first 5 second window W after FMP such that W overlaps no tasks longer than 50ms For all timestamp t in W, number of resource requests in flight at t is no more than 2.

Now find the last long task L before W. Consistently Interactive Candidate is the end of L In the case there is no long task before L, Consistently Interactive Candidate = FMP.

Now, Consistently Interactive = max(Consistently Interactive Candidate, DOMContentLoadedEventEnd)

Environment Information

• Affected Channels: Lighthouse Devtools, as well as Lighthouse called programmatically and Lighthouse CLI (overall, its reproduceable in all available Lighthouse Channels)
• Lighthouse version: 5.7.0
• Chrome version: Version 81.0.4044.129 (64-Bit)
• Node.js version: v12.16.1
• Operating System: Windows for this Performance Test but my Sites, which experience similar Results, run on Linux Servers

Conclusion

I dont know if these are false Long Tasks (i assume they are not) and this is a Bug in the end, but at least this Behaviour should be reflected in the Performance Tab. As of right now it is very hard to optimize for a good TTI Score in my opinion. As Lighthouse 5.x has a very strong emphasis on TTI Scrores this is actually quite problematic. I would be happy if you would look into the matter and tell me if this is actually expected Behaviour, a bug or if i am missing something entirely. Thank!

[LukasAuerMstage]

@patrickhulce Yeah i will definately submit it, sorry for the delay, probably within the next couple of days.

[patrickhulce]

I think we’ve fully addressed this with #11032 🎉 thanks for your contribution @LukasAuerMstage!