webpack-bundle-analyzer
webpack-bundle-analyzer copied to clipboard
Visualize time spent inside plugins/loaders
At ReactiveConf Tobias, Sean and I were asked multiple times "why is my build so slow". Also at other events I notice people don't know how to improve their webpack build time because they have no insights.
At the event we'd start explaining some basic performance optimizations, but also saying "it depends on what you're trying to do", or "make webpack do less work" (looking at you @TheLarkInn).
This lead me to think about bundle analyzer; this awesome tool allows us to visualize what's actually going in our bundle, size-wise. By giving these insights, you can actually tackle the problem that's resulting in huge builds.
What if we could do this, but for visualizing the build times? So instead of node packages you'd see "babel-loader", or "resolver plugin" or whatever takes up the most build time.
Some really spaceship ideas;
- Clicking on something like "babel-loader" would show more details, maybe files that took the most time?
- When hovering over default plugins of webpack, show an explanation how to improve performance with it
Feel free to close if this is really not something we want to do, but I wanted to just throw it out here and discuss. (not sure if this has been suggested before btw).
cc @sokra @CompuIves
Wow that sounds like a super neat idea! I'm not sure if it fits within webpack-bundle-analyzer, as we're only concerned about the generated output files
We could definitely extract useful bits out of this plugin to visualize loaders/plugins similarly to how webpack-bundle-analyzer visualizes bundle output.
I'd be excited to help with a proof of concept about this.
The most crucial part to even get to visualize this would be to get hands on to something similar as stats.json from webpack. We'd need to get data on the build timings itself, and even better, to drill deeper down to what is taking so long.
I don't know how much a webpack plugin can do to extract these timings, but it might be a nice adventure to go digging around webpack code to figure out places to attach such profiling code to :smile:
atm doing this is not really possible, I did a fair bit of research into making this exact tool.
The next rev of tapable will expose the primitives that are needed, however plugins will need to upgrade https://github.com/webpack/tapable/issues/35
tweet storm of findings https://twitter.com/samccone/status/897301366086942720
I'm not sure if it fits within webpack-bundle-analyzer
Not sure either, perhaps we could first build this in a fork of this repo and then look at whether to integrate it or make it a standalone repo.
@samccone very cool, if the next tapable/webpack 4 will fix this it's perfect. This issue was not meant to be a quick fix so that's fine :). Do you plan to continue working on this when webpack 4 is released?
@SpaceK33z - IMO this feels like something that could be standalone and visualized via something like webpack-dashboard or the electron version //cc @kenwheeler and or printed out with the existing performance stats ( bundle size & so on ).
@samccone - We can certainly ensure all the plugins that live here are updated accordingly and help drive the adoption for those plugins that live outside of contrib.
If you are going to continue running with whatever this ends up being & want it to live inside of contrib, shoot me an DM & i'll get you into the org with the appropriate access to make the magics happen.
I believe you're right @d3viant0ne, that's also how the conversation lead to this idea. Would love to help with this.
More than happy to help.
webpack 4 is going to be a hard requirement though, once that is out and we have enough plugins updated we can go from there. I think the next best step is to come up with a design doc around what this tool will show and what the user stories are around this tool and its findings.
Thanks.
Feel free to continue the conversation here, even though this issue isn't particularly about webpack-bundle-analyzer ☺️.
Seems like webpack 4 requirement is a must indeed.
I hope someone of you will keep the ball rolling on this issue, as I don't have time to take a lead on this 💞
@samccone did some work related to this https://twitter.com/TheLarkInn/status/945486181575340032 Couldn't find if he released it or would be include in webpack v4
This is the PR I would recommend following https://github.com/webpack/webpack/pull/6207
The plans are to land this in webpack#next as it required a pretty major plugin change to become possible

@samccone as I understand you've made your own visualization tool, right?
No, I made the export format loadable by chrome://tracing
which is what is captured in the screenshot above.