viewer: use treemap for bundle visualization

[connorjclark]

April 30 Demo
March 17 Demo

One of a few features I'm extracting from the bundle-analysis (#10064) branch.

Design doc: https://docs.google.com/document/d/10FQJqkRPFXhR1PDny_c0kvm7qQtokR5o7Oyw0n2_N44/edit?usp=sharing

In draft b/c UX hasn't been considered yet.

try it locally

yarn && yarn build-viewer && yarn viewer

# other terminal
node lighthouse-cli https://www.coursehero.com/sg/ --preset experimental --view

To save a distributable copy, Ctrl+S, "Complete Webpage", and distribute the HTML + the _files. Optionally trim the HTML by replacing the <main>...</main> with what is in treemap/index.html.

[joshribakoff]

cc @joshribakoff, fyi we saw your PR to source-map-explorer (danvk/source-map-explorer#145). Thought you might be interested in this effort. happy to hear any suggestions you may have :)

What would be really cool is if the tool could visualize how the code executes over time. I've also studied your definitions of TTI, and done much research into the topic & I think there is a use case to visualize CPU usage, over time, as a heatmap gradient mapped onto the treemap. Often TTI fails to capture main thread blocking events that happen after the metric, rather than giving a TTI metric, a full blown visualization of how work unfolds over time would be more useful.

There's also a use case for a tool that ingests user access patterns, and does knapsack algorithms + a heuristic to determine optimal bundle splitting. For example, if 40% of users land on the home page, and 40% of users land on the "channel" page, it is reasonable to infer those 2 entries should be their own bundle, by looking at the correlations in the user access patterns. There is a use case for a tool to visualize this.

I requested access to the design doc, thanks for tagging me!

The key take away I would stress is that there are 2 dimensions to split bundles - you ideally want to be able to visualize & split bundles by how frequently the code changes (to minimize cache invalidation), and the other dimension is user access patterns - you want to visualize the "minimal code" for all app boots, and you want to categorize app boots into entry points to inform your bundle splitting, generally speaking, or at least this is my take away.

I would actually also tag @TheLarkInn who has some opinions about how vendor bundles are an anti-pattern, it his musings which prompted me to make the original heatmap demo!

[connorjclark]

What would be really cool is if the tool could visualize how the code executes over time. I've also studied your definitions of TTI, and done much research into the topic & I think there is a use case to visualize CPU usage, over time, as a heatmap gradient mapped onto the treemap. Often TTI fails to capture main thread blocking events that happen after the metric, rather than giving a TTI metric, a full blown visualization of how work unfolds over time would be more useful.

We've found that using color gradients to denote information is very confusing. For one, it's not very color-blind accessible. Even as a color-normal person, I find it difficult to get any relative sense by comparing colors. That's why we cut "color by" from the first demo.

In a similar vein, I was thinking: a slider that starts at no execution time for anything to bucketing execution time to the correct node as it happens. On the slider, we could put critical moments like FCP, LCP, etc...

Unclear to me if this would be more cool than useful :)

There's also a use case for a tool that ingests user access patterns, and does knapsack algorithms + a heuristic to determine optimal bundle splitting. For example, if 40% of users land on the home page, and 40% of users land on the "channel" page, it is reasonable to infer those 2 entries should be their own bundle, by looking at the correlations in the user access patterns. There is a use case for a tool to visualize this.

At the moment Lighthouse consuming outside data (from GA, for example) is out of scope.

Besides that, normally when we talk about code splitting the goal is to only provide the code needed for the page, not try to make subsequent page loads on different parts of the site more likely to be in a warm cache. What you're suggesting almost seems like the opposite of what we'd want to do in Lighthouse–if the landing page doesn't use any of the code that the channel page uses, we'd want to suggest splitting it out. (FYI–I'm not sure how we'd do this yet).

BTW I have seen tools that consume user access patterns to create predictive preloads/prerenders. https://www.youtube.com/watch?v=UwjzFGCAuLw (s/o @shortdiv)

I requested access to the design doc, thanks for tagging me!

Ah it's super old anyhow, not useful anymore. things drifted and it wasn't updated.

The key take away I would stress is that there are 2 dimensions to split bundles - you ideally want to be able to visualize & split bundles by how frequently the code changes (to minimize cache invalidation), and the other dimension is user access patterns - you want to visualize the "minimal code" for all app boots, and you want to categorize app boots into entry points to inform your bundle splitting, generally speaking, or at least this is my take away.

Even with the most integrated toolset, I think we can only hope to know about user access patterns.

Code splitting advice is a hard problem, fortunately it's not part of this tool's initial release.

I would actually also tag @TheLarkInn who has some opinions about how vendor bundles are an anti-pattern, it his musings which prompted me to make the original heatmap demo!

Advising against bundles with vendor in the name might be something we could do. I recall hearing this advice, but would need to brush up on it to know if it's universally applicable.

[joshribakoff]

@connorjclark

We've found that using color gradients to denote information is very confusing. For one, it's not very color-blind accessible. Even as a color-normal person, I find it difficult to get any relative sense by comparing colors. That's why we cut "color by" from the first demo.

Code cov can be mapped to grayscale. Some of the color choices shown in the screenshots in the PR are quite unintuitive. I see your point, and I did not fully read through the PR to learn about the "color by" discussion ;)

Unclear to me if this would be more cool than useful :)

I also see your point :)

At the moment Lighthouse consuming outside data (from GA, for example) is out of scope.

Besides that, normally when we talk about code splitting the goal is to only provide the code needed for the page, not try to make subsequent page loads on different parts of the site more likely to be in a warm cache.

But if users pre-fetch, that can mess with your heuristics right? Maybe this is out of scope for this PR & I'm not super familiar with your tool.

What you're suggesting almost seems like the opposite of what we'd want to do in Lighthouse–if the landing page doesn't use any of the code that the channel page uses, we'd want to suggest splitting it out. (FYI–I'm not sure how we'd do this yet).

I guess what I'm saying is that if 45% of users hit the "home" page & 45% of users hit the "channel page", and 80% of the code for those 2 pages is shared, and 80% of users who hit one page visit the other page, this information is ideally leveraged, if we're talking about an ideal bundle splitting strategy. Maybe its out of scope here for this PR.

Advising against bundles with vendor in the name might be something we could do. I recall hearing this advice, but would need to brush up on it to know if it's universally applicable.

Its not the naming, its the anti-pattern of having "common" chunks, which has every piece of code used on 3 or more pages (a common webpack default). This "common" chunk is then often served on every page. This often results in lots of "common" code being present for pages that don't use all of the "common" code, even if its not executed the parse/eval time has a large cost, especially on mobile devices.

Sean's advice was to use the Chrome code coverage in the devtools & shoot for bundle splitting that gives you 80% coverage on FPL. I found Chrome's dev code coverage feature to be unusable because its just raw data, hence why I built the heatmap tool that mapped the raw code coverage data from chrome devtools onto a color coded treemap.

I'm not familiar with what you're trying to solve here, but I hope this helps. Thanks for making this awesome tool & making the web/world better!