Show gzipped file sizes.

[tylergraf]

Please excuse my naiveté.

I'd assume you'd want this as a flag passed in, I wasn't sure how to pass that param along.

Changes

• While calculating the spans, concat the string of each source and then gzip that to get the size
• I created the snapshots for the tests. I'm not sure if they're accurate. Please help. :)

[coveralls]

Coverage increased (+0.09%) to 96.637% when pulling f92115d on tylergraf:gzip into fe52007 on danvk:master.

[nikolay-borzov]

I was thinking about providing both stat and gzipped sizes.

"totalBytes": [
	stat: 357,
	gzip: 90
]

The more flags the more complex app becomes

[tylergraf]

Oh, ok. And just display both sets of data in the ui? I like that.

[nikolay-borzov]

Or we can add a dropdown (SIze: Stat, Gzip) that toggles displaying bundles with stat/gzip sizes as values

[danvk]

I'd vote for a command line flag or option in the UI to toggle this. Showing both numbers in each box might be a bit much. It's not always clear how to account for a module's contribution to the gzipped size. If I depend on A@1 and on B, which depends on A@2, then both versions of A will take similar amounts of space in the bundle. But presumably they're similar to one another and gzip(A@1 + A@2) will be similar in size to gzip(A@2). So how do you account for this? Is B's dependence on A free?

…

On Fri, Jul 5, 2019 at 12:40 PM Nikolay Borzov ***@***.***> wrote: Or we can add a dropdown (SIze: Stat, Gzip) that toggles displaying bundles with stat/gzip sizes as values — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#123?email_source=notifications&email_token=AAAX77LQ2DE6FPXQW6G5JE3P552QVA5CNFSM4H5MPDTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJ5XUA#issuecomment-508812240>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAX77NLIZ5KMLOO5QNBJTLP552QVANCNFSM4H5MPDTA> .

[tylergraf]

@danvk I don't know the answer. I assume they'll be similar in size?

Also, I've updated the PR to show a select box at the top to select either gzip or stat.

[tylergraf]

Hey guys, any thoughts on this?

[nikolay-borzov]

Sorry, I've been away from open source (and programming in general) for a while.
It needs more work. I don't like that adding gzip sizes had such impact on code base - there are many places that have changes. Perhaps we need to refactor some functions to reduce such impact (e.g. collect spans as characters and then calculate both stat size and gzip size). Also, the app should not by default output gzip (e.g. when outputting TSV) - we will have to add a flag that specifies preferred size type.
Give me this weekend and I'll try to make some changes. Otherwise, I will help you to make these changes.

[danvk]

Thinking more on this, a simpler way to frame my concern is that a treemap visualization implies that sizes are additive. When you visualize raw files and directories, this is true. When you gzip everything, it's not.

[nikolay-borzov]

Do you mean that a sum of individual files gzip sizes won't be equal to bundle gzip size?

[danvk]

Exactly. Or put another way, if you remove a 1k file from your JS bundle, it will get 1k smaller. But if you remove a file that's 1k after gzipping from your bundle, the gzipped bundle might not get 1k smaller.

It would help to understand the use case for showing gzipped sizes.

[sean9keenan]

I can chime in on why I'm interested in this. I care about the final size that goes over the network (as that's what most impacts users - which is why I love this tool so much!).

Since I normally gzip when deploying, I want to know which files/libraries I should target for removal. While you're right that removing a file that's 1k gzipped doesn't always mean my bundle gets 1k smaller - I'm hoping that gzipped sizes will provide a better proxy for final gzipped size than non-gzipped file sizes (In particular for files that are highly compressible).

Given the confusion around this I totally understand not wanting this to be the default, with perhaps a warning to the effect of "due to the nature of compression - removing a 1k gzipped file in a bundle may reduce the bundle size by less than 1k".

Ideally I'd like to know how much space I can save by optimizing away which files/libraries - but that seems like more work than is worth (especially if you want to be able to select any set of libraries for removal - and not just a single one).

Thanks for your work on this!

[tylergraf]

I agree with @sean9keenan. I feel like it's better to be gzipped and close than to be technically right.

Almost everybody on my team has run the analyzer and wondered if the numbers were gzipped. The uncompressed number is valuable for knowing your memory footprint, but the most helpful info is to see gzipped information, even if it's not exact. Whenever I look at these tools, I always take them with a grain of salt anyway because they don't show what will be loaded on my page, they just show bundle sizes. My page will probably have several of the chunks.

So in my opinion, I'd like to get this feature in sooner rather than later, and just message the

"due to the nature of compression - removing a 1k gzipped file in a bundle may reduce the bundle size by less than 1k".