Reportes sizes don't match reality

[PierBover]

The reported bundle size is double the size of the actual bundle:

The file deployed to Netlify with brotli compression weights 7.3kB and not 17.59kB:

Here's the stats.html file:

https://gist.github.com/PierBover/05bfd099b7d150e5fadf42e195b8ba34

[btd]

Hi, thanks for the question. I got such usually at least once a year.

Short answer: yes it is different, stats file will always show bigger numbers by design and rollup functionality provided.

Longer answer

I think first i need to explain treemap/sunburst diagram works.

For each bundle rollup provided set of dependencies that included in bundle. Each of them contains some properties (useful for my purpose only module id and renderendLength). The first problem is exactly in property renderedLength. It is string.length of code after treeshaking. It means that if you file contains only ascii characters it will be accurate byte representation, otherwise not. This is a first place where results shows bigger numbers for individual files. At rollup 2.44 were added functionality to get treeshaked code (i sent this PR) and sooner or later i will fix this to use byte size.

Returning to treemap. After all individual files gathered it starts to compute numbers for top directories until root. Meaning that bundle size shown is a sum of every single file size. This is a second biggest difference from actual size. It is not possible with rollup only to get individual file sizes after whole bundle transformation (read it after for example minification with terser). For this at the beginning we added sourcemap option, which get sizes from sourcemap. But it is still number of characters, but at least after all transformations.

Plugin order is matter also. For sourcemap option it is important to include plugin to be last in plugins array. Without sourcemap it is not that critical, but still you can miss some individual transformations.

The last i think need to add about gzip and brotli size, before rollup 2.44 these numbers where based on real files in your FS, i just read them put through gzip/brotli and show byte size. Now it is using treeshaked code for size estimation.

And at the end of all this mess. It is still OK. You need to understand whole purpose of this plugin. This plugin allows you to visually see biggest/repeated parts of your bundle for further optimizations. This plugin is not representation of your filesystem.

Let me know if you have more questions.

[marcofugaro]

@btd what about adding an option to hide file sizes?

If as you say

This plugin allows you to visually see biggest/repeated parts of your bundle for further optimizations. This plugin is not representation of your filesystem.

Then I'd like an option to hide file sizes as they are confusing if they don't match.

^ The tooltip would show only the percentage ideally.

[btd]

That makes sense, i will think about it

[btd]

I will close this one in favor of #98

[smalllong]

Still. it is very unintuitive that comments are contributing to the size in visualizer, although they won't contribute to the final minified file, which is misleading. Hope the visualizer can visualize based on output file rather than source file