Increasing pauseAfterLoadMs also increases Total Blocking Time

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

Locally

What happened?

When increasing the pauseAfterLoadMs to 5000 the Total Blocking Time (TBT) increased to 1237ms, which decreased its score to 11%.

module.exports = {
  extends: "lighthouse:default",

  passes: [
    {
      passName: 'defaultPass',
      /** The number of milliseconds to wait after the load event until the page should be considered loaded. */
      pauseAfterLoadMs: 5000,
      gatherers: []
    },
  ],

What did you expect?

TBT should not have been affected by pauseAfterLoadMs

What have you tried?

I played around with the values of pauseAfterLoadMs; the more I increased them the more the TBT score decreased.

How were you running Lighthouse?

node

Lighthouse Version

6.0

Chrome Version

No response

Node Version

No response

OS

No response

Relevant log output

No response

[connorjclark]

Instead of configuring pauseAfterLoadMs to maybe capture a later part of the page, I suggest you try our new user flow api and wait for your widget to appear before ending your timespan.

Perhaps because you’ve now captured this widget loading, the increased TBT is really a signal that the widget had a lot of blocking code associated with it?

https://github.com/GoogleChrome/lighthouse/blob/master/docs/user-flows.md

[bakiasib]

@connorjclark yes I have a widget that starts during page load. Lighthouse was not waiting long enough for it to load and I wanted to calculate its size so that is why I increased the pauseAfterLoadMs. However the site is interactive even if the widget has not loaded yet, so I would think it wouldn’t cause the scores of TBT or Time To Interactive, and First CPU Idle to drop