-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
viewer: use treemap for bundle visualization #10312
Conversation
commit ecb6260 Author: Connor Clark <cjamcl@google.com> Date: Wed Dec 11 15:17:52 2019 -0800 no index commit 52796db Author: Connor Clark <cjamcl@google.com> Date: Wed Dec 11 15:17:02 2019 -0800 no unshift commit 943e19c Author: Connor Clark <cjamcl@google.com> Date: Wed Dec 11 15:14:21 2019 -0800 deletionBraceCount commit caa269b Author: Connor Clark <cjamcl@google.com> Date: Wed Dec 11 15:13:25 2019 -0800 comments commit e6fde71 Author: Connor Clark <cjamcl@google.com> Date: Wed Dec 11 15:02:50 2019 -0800 semver commit 6480198 Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 21:18:36 2019 -0800 update frontend commit 5d17268 Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 21:07:44 2019 -0800 rm some ts ignores commit 7129ef9 Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 21:04:09 2019 -0800 trim unneeded code commit 0b655b6 Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 20:46:11 2019 -0800 better cdt lib gen commit 3333c4f Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 20:19:20 2019 -0800 add sections to source map type commit 73eca7b Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 20:00:02 2019 -0800 move SDK up b/c global pollution is gone commit 47e8a41 Author: Connor Clark <cjamcl@google.com> Date: Tue Dec 10 19:44:59 2019 -0800 comment commit 9f47880 Author: Connor Clark <cjamcl@google.com> Date: Mon Dec 9 15:02:57 2019 -0800 remove unused js commit 7d50227 Author: Connor Clark <cjamcl@google.com> Date: Sat Dec 7 00:36:07 2019 -0800 nul commit ed4bb21 Author: Connor Clark <cjamcl@google.com> Date: Sat Dec 7 00:33:39 2019 -0800 remove ParsedURL commit 43da869 Author: Connor Clark <cjamcl@google.com> Date: Sat Dec 7 00:30:08 2019 -0800 tmp commit 0d73a8b Author: Connor Clark <cjamcl@google.com> Date: Sat Dec 7 00:22:10 2019 -0800 reduce code commit 4a9127d Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 23:52:44 2019 -0800 delete some stuff not needed commit dff8358 Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 23:24:48 2019 -0800 errors commit 808736d Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 22:56:20 2019 -0800 Common.console commit 122f2a2 Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 22:54:42 2019 -0800 ts commit 2f80d5a Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 22:50:18 2019 -0800 remove hacky globalThis.cdt commit 7ad9389 Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 21:24:00 2019 -0800 do not pollute global array commit fa07a80 Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 21:17:56 2019 -0800 mapping test commit f9408f3 Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 20:49:23 2019 -0800 count lines commit 6d27caa Author: Connor Clark <cjamcl@google.com> Date: Fri Dec 6 20:41:09 2019 -0800 initial
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! |
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 Unclear to me if this would be more cool than useful :)
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)
Ah it's super old anyhow, not useful anymore. things drifted and it wasn't updated.
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.
Advising against bundles with |
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 ;)
I also see your point :)
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.
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.
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! |
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
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 intreemap/index.html
.