Skip to content

Conversation

@patrickhulce
Copy link
Collaborator

Summary
After some discussion, we settled on surfacing the blocking time of third parties rather than a full-fledged opportunity of TTI savings of removing all third-party resources. It shows up as failing if the impact to TBT is >250ms (which would push you out of a ~90 score range on TBT).

Related Issues/PRs
closes #9256

image

@benschwarz
Copy link
Contributor

I know that Total Blocking Time is the newly coined name for main thread long tasks, but I feel like it's a little confusing in this context without a more descriptive label referencing the "main thread" more directly.

Specifically, I'm referring to the table heading "Blocking Time". It could easily be confused as the time that a given vendor delayed http requests.

Could the label be: Main thread blocking time?

url: 'https://marketingplatform.google.com/about/tag-manager/',
},
mainThreadTime: 104.70300000000002,
blockingTime: 18.186999999999998,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just interesting to see the impact here drop (104ms -> 18ms)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I'm a bit disappointed to see the very busy third parties disappear, but if it's an incentive to script responsibly than I guess it's still a very positive outcome so I'm :)

My biggest concern is that no one is going to understand what "main-thread blocking time" actually is and they'll assume it's the time spent which would be sad.

FWIW this is also not as drastic in the lantern case, it goes from 419 -> 250. While still a big drop, the number is still noticeable.

Copy link
Contributor

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My biggest concern is that no one is going to understand what "main-thread blocking time" actually is and they'll assume it's the time spent which would be sad.

this concerns me, too, but I guess we'll see how it goes :)

Other than that, though, LGTM! Only superficial comments.

columnThirdParty: 'Third-Party',
/** Label for a table column that displays how much time each row spent executing on the main thread, entries will be the number of milliseconds spent. */
columnMainThreadTime: 'Main Thread Time',
/** Label for a table column that displays how much time each row spent blocking other work on the main thread, entries will be the number of milliseconds spent. */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there might have been an issue with describing the "main thread" to the tc... @exterkamp? Or was it for this audit and it's already been clarified :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem was with "thread" being used, in regards to the description in first-interactive

I think this is fine here. Maybe add something about threads. But I think that is unnecessary. This LGTM.


const str_ = i18n.createMessageInstanceIdFn(__filename, UIStrings);

// A page passes when all third-party code blocks for less than 250 ms.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe put some version of the comment in the PR description

It shows up as failing if the impact to TBT is >250ms (which would push you out of a ~90 score range on TBT)

in here to give motivation to the particular number?

Copy link
Collaborator Author

@patrickhulce patrickhulce Aug 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah sg

Suggested change
// A page passes when all third-party code blocks for less than 250 ms.
// A page fails this audit if the main-thread impact is >250ms (which would push you out of a ~90 score range on TBT).

// The amount of time spent on main thread is the sum of all durations.
entityStats.mainThreadTime += taskDuration;
// The amount of time spent *blocking* on main thread is the sum of all time longer than 50ms.
// Note that this is not totally equivalent to the TBT definition since it fails to account for FCP,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a TODO or worth reexamining at some point?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO not a TODO ever worth fixing since it should be rare that third party code actually blocks FCP and if it does I'm fine pointing the finger at it anyway. Our slight decoupling of the audit from TBT in external descriptions also makes this less of an issue.

}`,
=1 {1 third-party}
other {# third-parties}
} blocked the main thread by {timeInMs, number, milliseconds}\xa0ms`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plurals must be totally contained in the {}. #9460 allows replacements in plurals like this. But I don't want to add more strings that violate this policy (I get a lot of emails saying this is against policy).

Suggested change
} blocked the main thread by {timeInMs, number, milliseconds}\xa0ms`,
`{itemCount, plural,
=1 {1 third-party blocked the main thread by {timeInMs, number, milliseconds}\xa0ms`}
=other {# third-parties blocked the main thread by {timeInMs, number, milliseconds}\xa0ms`}
}`,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also expand on "third-party" with something like 1 third-party script blocked...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally forgot about this whole fiasco, honestly I don't think the number of third parties needs to be communicated here if it causes trouble

@codecov
Copy link

codecov bot commented Aug 15, 2019

Codecov Report

Merging #9486 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #9486      +/-   ##
==========================================
- Coverage   91.88%   91.87%   -0.01%     
==========================================
  Files         298      298              
  Lines       10361    10364       +3     
==========================================
+ Hits         9520     9522       +2     
- Misses        841      842       +1
Flag Coverage Δ
#smoke 84.4% <22.22%> (-0.05%) ⬇️
#unit 90.27% <100%> (ø) ⬆️
Impacted Files Coverage Δ
lighthouse-core/audits/third-party-summary.js 100% <100%> (ø) ⬆️
...house-core/computed/metrics/lantern-speed-index.js 97.14% <0%> (-2.86%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5eb01d6...676b9b0. Read the comment docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FR - Add better ways of visualizing perf impact of 3rd party scripts

6 participants