Stat size, parsed size...?

[jamesplease]

Are there definitions somewhere of exactly what "stat size", "parsed size," etc. means? I'd be happy to add these definitions to the README if they're somewhere else right now. Just lmk!

Thanks for the great plugin ✌️

[valscion]

Stat sizes are fetched from the webpack stats object directly, and use the actual source code of your modules as-is and report the size before minification or gzip

Parsed size is calculated by reading the actual compiled bundle files and making a link back to the modules from webpack stats file. So if you use a minifier, such as UglifyJS, the parsed size shows you the size after minification.

Likewise, the gzip size is calculated by reading the actual compiled bundle files and running gzip for each one of the module sources separately. Thus the gzip size shows you the size after minification and gzip, but it isn't a 1-to-1 mapping with the actual file sizes as gzipping each module separately yields less "wins" in terms of compression as the separate sources have less opportunities for gzip to compress together.

Here's the relevant two lines in the code, that is ran for each module.

https://github.com/th0r/webpack-bundle-analyzer/blob/v2.3.1/src/analyzer.js#L80-L83

It would be nice if you would be able to put this together into the README somehow :). This question has been asked a few times already, so it would make sense to display it in the README.

[th0r]

Thus the gzip size shows you the size after minification and gzip, but it isn't a 1-to-1 mapping with the actual file sizes as gzipping each module separately yields less "wins" in terms of compression as the separate sources have less opportunities for gzip to compress together.

Just one note: it gzips each module separately but also gzips the whole bundles so you will have relevant gzip sizes for your bundle scripts.

[valscion]

Yeah true, forgot to say that for the entire bundle, the gzip size is correct, but for individual modules it might lie. Thanks for correcting me!

[th0r]

@valscion Thanks for your answer)

[jamesplease]

This is immensely helpful. Thanks for all of this detail!

I'll whip up a PR to add this to the README shortly.

[jamesplease]

As much as I want to write this up, I've been suffering from some sudden RSI and think it'd be better if I didn't. At least not until I see a doctor. Might be able to pick it up, but for now it's going on my back burner. Sorry! 🙈

[valscion]

That's entirely understandable @jmeas ❤️ no hard feelings! I understand RSI 😅

[jamesplease]

My RSI has chilled out, so I'm gonna PR this this weekend!

[chenop]

My stat size is less the the parsed size - does it make sense?
I expected after minification to get a smaller size...

[valscion]

Open a new issue with more details if you think something is wrong :)

[Fewwy]

I want to understand the Stat-Parsed-Gzip behavior. What should be bigger than others?
For example, I have a stat size of 7.52 MB, parsed size of 13.04 MB, and gzip of 2.04 MB.
So? My understanding is that I should look at the "stat" first and if it's too big - try to make it smaller by using webpack tools. Am I correct?

[valscion]

It seems strange that stat size is smaller than parsed size by that big margin. You should not be able to make stat sizes smaller by changing webpack configuration as the stat size represents the original source code size as explained earlier in this issue here: #61 (comment)

I can't help with figuring out why parsed size is larger than stat sizes, I'm afraid. Maybe asking in stackoverflow could allow someone to help you?

[Fewwy]

@valscion Yeah, I think there is an issue with one of the libraries that I use. It imports too many icons that we're not utilizing in the UI. But I managed to optimize the bundle size using the Terser webpack plugin. My parsed bundle 13 MB became 5 :), gzipped reduced to 1.3 MB(previously 2 MB).

[toolness]

Hello! I also experienced issues with parsed sizes being much bigger than stat sizes, but once I told my webpack to make a production build instead of a development one, this changed. While the parsed sizes of some dependencies were still bigger than the stat size, a lot of them were significantly reduced.

Here's my theories about what's going on:

• Some devtool options, such as eval-cheap-module-source-map, actually transform dependencies in such a way that they are bigger than their original size. Adding an inline source map probably massively increases the size too.

• Transpilation might also make your source modules bigger. For example, if the module source is ES6 but you're transpiling to ES5, the final source may be significantly larger.

Anyways, these are just my guesses, I'm not sure if they're actually true.