Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lighthouse Treemap ☂️ #11254

Closed
16 of 24 tasks
connorjclark opened this issue Aug 12, 2020 · 4 comments
Closed
16 of 24 tasks

Lighthouse Treemap ☂️ #11254

connorjclark opened this issue Aug 12, 2020 · 4 comments
Assignees
Labels

Comments

@connorjclark
Copy link
Collaborator

connorjclark commented Aug 12, 2020

Design (Googlers only, sorry): https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZeok9-CasvMb/files/MCFFTHkODMy6RyA6lXJuFGJb

Just one of the mock designs:
image

Initial proof-of-concept PR: #10312

Branch with these items in various levels of "WIP/Draft" state: https://github.com/GoogleChrome/lighthouse/compare/viewer-treemap-2

ref #10369

@connorjclark connorjclark self-assigned this Aug 12, 2020
@connorjclark connorjclark changed the title Treemap app ☂️ Lighthouse Treemap ☂️ Oct 9, 2020
@brendankenny
Copy link
Member

brendankenny commented May 19, 2021

(I can move this feedback to a separate issue if that's easier)

While working on a mock LR bundle to test speed-index perf, I accidentally made a 12MiB bundle. As I was trimming stuff out of the bundle, I wanted to easily see everything inside, so I generated the bundle with source maps, took a Lighthouse run of a page with the bundle in it, then looked at the treemap of it :)

Saved report is here

Ridiculousness of doing it this way aside, there were some issues I ran into:

  • almost all of the files are missing in the treemap view except lightrider-entry.js (which is huge because it has an inlined trace, but there should still be other files in the remaining 15%). All the rest of the files are shown in the table, however.
  • the coverage bars in the table are tiny, presumably in relation to the lightrider-entry.js 2.1MiB coverage bar, but lightrider-entry.js doesn't have a coverage bar
    small visible treemap coverage bars
  • clicking on the "Unused Bytes" button makes lightrider-entry.js completely shaded, even though it's definitely at least somewhat used since it's the entry point :). There's no unused bytes in the table though...is it assuming that it's 100% unused and so shading the whole thing in that case?
  • sorting by unused bytes in the table interleaves bytes and KiB. It's not quite string code unit order, but it's close enough that I would bet it's sorting strings with the default [].sort() somewhere
    oddly sorted data column

@connorjclark
Copy link
Collaborator Author

connorjclark commented May 19, 2021

reference:

image

almost all of the files are missing in the treemap view except lightrider-entry.js (which is huge because it has an inlined trace, but there should still be other files in the remaining 15%). All the rest of the files are shown in the table, however.

the third child of this d1 node is 91% of the total size, and lightrider-entry.js is overwhelmingly the biggest thing there, so everything else is hidden. I'm not familiar with how the webtreemap lib makes these layout decisions, but if we wanted to show every possible node we'd need some clever UI. Maybe a three-dots button in the bottom right corner of a node ... click for a drop down list, select and then treemap does another layout but zooms into the node you selected and does another layout (possibly with more three dot buttons).

It'd be pretty involved. Since the files are relatively small, and the main functionality here is to identify opportunities to reduce bundle size, is it worth it?

the coverage bars in the table are tiny, presumably in relation to the lightrider-entry.js 2.1MiB coverage bar, but lightrider-entry.js doesn't have a coverage bar

yeah i'm not happy with how minuscule they look here. but I do like the idea of relative coverage bars. I think in a more realistic bundle, which don't have the property that the second largest file is 1% the size of the largest file, the coverage bar is fine.

can you run LH again on this page and see why "clients/lightrider/lightrider-entry.js" node doesn't have unusedBytes set?

clicking on the "Unused Bytes" button makes lightrider-entry.js completely shaded, even though it's definitely at least somewhat used since it's the entry point :). There's no unused bytes in the table though...is it assuming that it's 100% unused and so shading the whole thing in that case?

hmm... it shouldn't be doing that. am I reading this code wrong? seems correct... behavior you noticed is unexpected.

https://github.com/GoogleChrome/lighthouse/blob/99c47cd/lighthouse-treemap/app/src/main.js#L614

sorting by unused bytes in the table interleaves bytes and KiB. It's not quite string code unit order, but it's close enough that I would bet it's sorting strings with the default [].sort() somewhere

This is so weird. ?debug is fine! What's going on ...

@patrickhulce
Copy link
Collaborator

@connorjclark is the task state accurate here? What's remaining in treemap that's still P1?

@connorjclark
Copy link
Collaborator Author

Fixed the sorting issue. The shading issue I don't see anymore. There are other improvements to be made but its past time to close this tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants