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

[demianrenzulli]

Feature request summary

Today LH offers different ways of visualizing the amount of 3rd party scripts a page loads:

• The Minimize main-thread work suggestion shows the overall JS impact.
• The Reduce JS execution time suggestion shows a break down of JS libraries, and has a very handy switch to show/hide 3rd-party resources.

As a complement of this, it would be useful to be able to simulate how the Performance score or individual metrics would change, by not loading these scripts (similarly to what you'd do with the "Block" feature in WPT).

Ideas on how to achieve this:

• Turning the "Show 3rd party resources" off, shows how metrics like TTI, and others, would change as a result.
• Allowing the block requests feature in DevTools to impact the LH resulting report (already discussed in FR - Integrate DevTools blocked requests with LH reports ran from Audits tab #9095). This one requires more work from the developer, and might look like a hidden feature and not very intuitive. Also harder to connect with the 3p JS breakdown, LH shows.

Note: Showing a page without any 3p scripts, also can lead to unintended scenarios:

• Some 3p scripts are meant to execute important functionality (i.e: libraries like JQuery, or libraries with business logic the developer has hosted in a different domain, like a CDN). Omitting them in the report might end up showing scores for an unusable site.
  To mitigate that, maybe changing the list from "3p resources", to something more specific like "trackers/analytics" might help.

What is the motivation or use case for changing this?

3p scripts are among the main reasons for slow websites today. Anything that can be done to show the impact of these resources more clearly, can help teams communicate this internally and take action.

How is this beneficial to Lighthouse?

It makes the tool more actionable.

[patrickhulce]

Thanks for filing @demianrenzulli! Have you already seen #9067 ? We're definitely on the case for better surfacing third party data :)

[demianrenzulli]

This is great @patrickhulce! It seems like you have already some plans to make this information more actionable. Should I keep this FR open, then? Or maybe close and leave the other as the main one?

[patrickhulce]

We can make this the tracking issue moving forward :)

[demianrenzulli]

Awesome, thanks @patrickhulce!

[jonkeller]

Hi, @demianrenzulli: do you have any additional thoughts about the audience(s) for this (e.g. just developers? Also CTO/decision-makers who may not care so much about the tech details?), or suggestions for how the UI could look? Thanks!

[patrickhulce]

As an update, our current thinking inside the team here is that it would be a bit too aggressive to present an "Opportunity" that reports how much TTI savings there would be by removing all third parties since that's not realistic incremental step for most site owners. Instead we're going to convert the existing "informative" diagnostic into a failing one that reports the impact to the new TBT metric.

[demianrenzulli]

Thanks guys,

@jonkeller: it's usually the case that developers don't have much control on which scripts are injected in the page (mostly through tag managers).
With that said, I thought it would be mostly for developers trying to show to internal stakeholders the impact 3rd party JS might have on metrics like TTI.

One of the problems is that, as @patrickhulce, it wouldn't be realistic to remove all of them. Also, many 3rd party scripts actually add important functionality for the site, so this might be a subgroup of scripts (trackers, etc).

Hope this helps understand the motivations better.

[paulirish]

Someone mentioned the requestmap visualization on twitter: https://twitter.com/nystudio107/status/1026609102502457344

I think it does a good job of indicating the connections between 3rd parties, but I'm interested in exploring how to better communicate impact. Circle size and color are two variables in this force-directed graph viz.

[jonkeller]

Understood re: "it wouldn't be realistic to remove all of them". I've been thinking about it in terms of "this is the lower bound for latency - you're not going to exceed this by tweaking your script tags", but even if the wording communicates that clearly...maybe that's not as useful to the user as something more realistic/practical.
Thanks for the graph!