misc(treemap): unused-bytes view mode #12142

connorjclark · 2021-02-26T02:42:12Z

https://lighthouse-1gxbe1yl8-googlechrome.vercel.app/gh-pages/treemap/?debug

This adds a "view modes" data structure, which defines how to interpret the data when walking currentTreemapRoot. unused-bytes is the first view mode, which highlights nodes with especially large amounts of unused bytes, and partitions the treemap based on percentage of total unused bytes on the page.

This only shows unused bytes based on javascript coverage, but there's no reason in the future that we couldn't determine unused bytes of images, css, etc. and plug them into this view mode.

patrickhulce

code mostly LGTM just minor stuff 💯

I had a few UX notes while I was playing around with it, but it's been a while since I remember talking about this so might have already been covered.

It takes a fair bit of time to orient oneself to a new treemap, identifying your bundles and what files you're looking at. When you click "unused" then, it was quite jarring to have the entire thing reshuffle orders, so I'm second guessing if that's the best way to interact with this information. IIRC, our rationale was that luminance intensity is pretty useless? But I was surprised in practice how powerful the use of white v. no color was already. My current thinking is that it might be a more powerful call to action if you get to see the unused modules in the context of your entire bundle for the easy wins. Right now it's weird that I'm looking at 100% unused bytes, so it feels like there's no priority.
The percentages in the module labels were confusing in the context of an unused bytes visualization. I get that it's a treemap and we're saying "hey this module's unused bytes were 2% of your overall unused bytes" but I don't think I care. I kinda want to know how much of the module itself was unused in that percentage.
The usage breakdown feels pretty unactionable when it's an entire bundle without a source map and there's quite a bit of visual space dedicated to them. I don't have a suggestion on how to fix yet, maybe we split them into source mapped and non-source mapped with less emphasis on the giant blobs?

lighthouse-treemap/app/src/main.js

patrickhulce · 2021-02-26T17:31:01Z

lighthouse-treemap/app/src/main.js

+      TreemapUtil.walk(this.currentTreemapRoot, (node, path) => {
+        // Only highlight leaf nodes of a certain size.
+        if (node.children) return;
+        if (!node.unusedBytes || node.unusedBytes < 50 * 1024) return;


extract this 50KiB to a constant? feels like it will get buried otherwise :)

also should this account for relative usage some? like if 90% of a module 500kb dep is used, feels a bit weird to flag it as unused (though a bloat visualization should 😆 )

Copied the constants from the unused-audit for this, but I also refactored things a bit...

Now, it will only highlight anything in a d1 (depth one) node if it is greater than some number of unused bytes. The audit uses a 20KiB threshold to ignore an entire bundle, so I did the same here. For a specific leaf node (a module in a bundle), only highlight if more than half of the bytes are unused.

Later PRs will add a pie graph/something similar to show how much of a node is unused.

lighthouse-treemap/app/src/main.js

connorjclark · 2021-03-01T21:49:38Z

It takes a fair bit of time to orient oneself to a new treemap, identifying your bundles and what files you're looking at. When you click "unused" then, it was quite jarring to have the entire thing reshuffle orders, so I'm second guessing if that's the best way to interact with this information. IIRC, our rationale was that luminance intensity is pretty useless? But I was surprised in practice how powerful the use of white v. no color was already. My current thinking is that it might be a more powerful call to action if you get to see the unused modules in the context of your entire bundle for the easy wins. Right now it's weird that I'm looking at 100% unused bytes, so it feels like there's no priority.

I removed the unusedBytes partition for this view mode and I agree, it is much less jarring. For purposes of quick assessment I think this is the better experience so let's do that. I'm not certain that a "partition by unused bytes" couldn't be useful to someone. For myself, if I'm tackling the problem "let's reduce how much unused JS we are shipping", I'd appreciate the ability to partition by the metric I'm trying to reduce. But that can be relegated to the settings module.

The percentages in the module labels were confusing in the context of an unused bytes visualization. I get that it's a treemap and we're saying "hey this module's unused bytes were 2% of your overall unused bytes" but I don't think I care. I kinda want to know how much of the module itself was unused in that percentage.

Later PRs will add a gauge to each module to indicate how much is unused. also, the table component that is coming up soon offers another way to view this data. see gallery.googleplex.com/projects/MCHbtQVoQ2HCZeok9-CasvMb/files/MCFFTHkODMy6RyA6lXJuFGJb

The usage breakdown feels pretty unactionable when it's an entire bundle without a source map and there's quite a bit of visual space dedicated to them. I don't have a suggestion on how to fix yet, maybe we split them into source mapped and non-source mapped with less emphasis on the giant blobs?

I don't want to deemphasize something just because it doesn't have a source map. Perhaps an indicator for these nodes that "A source map will provide more granular data" will suffice?

paulirish · 2021-03-04T23:26:15Z

lighthouse-treemap/app/src/main.js

+      for (const d1Node of this.currentTreemapRoot.children || []) {
+        // Only highlight leaf nodes if entire node (ie a JS bundle) has greater than a certain
+        // number of unused bytes.
+        if (!d1Node.unusedBytes || d1Node.unusedBytes < UNUSED_BYTES_IGNORE_THRESHOLD) continue;


based on the UNUSED_BYTES_IGNORE_THRESHOLD over in unused-bytes.... wouldnt it meant that there is no node created in those cases?

regardless.. this seems fine to me.

no, the treemap data sets unusedBytes straight from the coverage data, not the unused-javascript audit.

paulirish · 2021-03-04T23:36:36Z

lighthouse-treemap/app/src/main.js

@@ -191,6 +244,14 @@ class TreemapViewer {
        // Ran out of colors.
      }

+      // A view can set nodes to highlight. If so, don't color anything else.
+      if (this.currentViewMode.highlightNodePaths) {


Array.isArray

but, typescript?

lighthouse-treemap/app/src/main.js

paulirish

lgtm. one small thing i noticed.

paulirish · 2021-03-16T19:04:33Z

lighthouse-treemap/app/styles/treemap.css

@@ -65,6 +65,12 @@ body {
  background-color: lightblue;
 }

+.view-mode__button {


btw you're losing your cursor styling because label has a default (who knew)

connorjclark added 2 commits February 25, 2021 19:34

misc(treemap): unused bytes

a98b0b6

tweak

01d5bbe

connorjclark requested a review from a team as a code owner February 26, 2021 02:42

connorjclark requested review from patrickhulce and removed request for a team February 26, 2021 02:42

google-cla bot added the cla: yes label Feb 26, 2021

devtools-bot assigned patrickhulce Feb 26, 2021

devtools-bot added the waiting4reviewer label Feb 26, 2021

patrickhulce reviewed Feb 26, 2021

View reviewed changes

patrickhulce added waiting4committer and removed waiting4reviewer labels Feb 26, 2021

pr

8f3a4ad

vercel bot deployed to Preview March 1, 2021 21:38 View deployment

connorjclark requested a review from paulirish March 1, 2021 21:40

test not using unsed bytes partition by

94eb4e6

vercel bot deployed to Preview March 1, 2021 21:42 View deployment

connorjclark assigned paulirish and unassigned patrickhulce Mar 3, 2021

paulirish reviewed Mar 5, 2021

View reviewed changes

pr

3ebf2ae

vercel bot deployed to Preview March 9, 2021 21:26 View deployment

connorjclark added waiting4reviewer and removed waiting4committer labels Mar 9, 2021

paulirish approved these changes Mar 16, 2021

View reviewed changes

fix

8a08747

vercel bot deployed to Preview March 16, 2021 22:20 View deployment

connorjclark merged commit aae0d0e into master Mar 16, 2021

connorjclark deleted the treemap-unused-bytes branch March 16, 2021 22:50

connorjclark mentioned this pull request Mar 17, 2021

Lighthouse Treemap ☂️ #11254

Closed

24 tasks

paulirish pushed a commit that referenced this pull request Mar 23, 2021

misc(treemap): unused-bytes view mode (#12142)

9e985f4

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

misc(treemap): unused-bytes view mode #12142

misc(treemap): unused-bytes view mode #12142

connorjclark commented Feb 26, 2021 •

edited

Loading

patrickhulce left a comment •

edited

Loading

patrickhulce Feb 26, 2021

patrickhulce Feb 26, 2021

connorjclark Mar 1, 2021

connorjclark commented Mar 1, 2021

paulirish Mar 4, 2021

connorjclark Mar 5, 2021

paulirish Mar 4, 2021

connorjclark Mar 5, 2021

paulirish left a comment

paulirish Mar 16, 2021

misc(treemap): unused-bytes view mode #12142

misc(treemap): unused-bytes view mode #12142

Conversation

connorjclark commented Feb 26, 2021 • edited Loading

patrickhulce left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark commented Mar 1, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulirish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

connorjclark commented Feb 26, 2021 •

edited

Loading

patrickhulce left a comment •

edited

Loading