webpack-bundle-analyzer icon indicating copy to clipboard operation
webpack-bundle-analyzer copied to clipboard

Visualize time spent inside plugins/loaders

Open SpaceK33z opened this issue 8 years ago • 12 comments

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

SpaceK33z avatar Oct 26 '17 11:10 SpaceK33z

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.

valscion avatar Oct 26 '17 12:10 valscion

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:

valscion avatar Oct 26 '17 12:10 valscion

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

samccone avatar Oct 26 '17 14:10 samccone

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 avatar Oct 26 '17 15:10 SpaceK33z

@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.

joshwiens avatar Oct 26 '17 19:10 joshwiens

I believe you're right @d3viant0ne, that's also how the conversation lead to this idea. Would love to help with this.

CompuIves avatar Oct 26 '17 19:10 CompuIves

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.

samccone avatar Oct 29 '17 04:10 samccone

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 💞

valscion avatar Oct 30 '17 08:10 valscion

@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

montogeek avatar Jan 02 '18 09:01 montogeek

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 avatar Jan 02 '18 14:01 samccone

@samccone as I understand you've made your own visualization tool, right?

th0r avatar Apr 11 '19 11:04 th0r

No, I made the export format loadable by chrome://tracing

which is what is captured in the screenshot above.

samccone avatar Apr 18 '19 14:04 samccone