minify and gzip before checking file size

[hughsk]

minify and gzip before checking file size

[hughsk]

So the problem with gzip, as I understand it, is that it requires all of the content to get an accurate result. Once you've got the content gzipped, there's no clear indicator for how much of the final bundle is taken up by an individual file as parts might be shared across multiple files, and you're working with an unparseable binary at that point.

@Raynos @ForbesLindesay any suggestions on how to make this work?

[jasonkarns]

I see two different features here. It's certainly useful to see the impact individual modules have on the final minified/gzipped size. And this could be accomplished as @Raynos described above.

But a much more simple metric could cover 60% of the use case. That is, just include the total filesize of the entire gzipped bundle in the output report. Personally, I would be happy to make my decisions per module/filesize based on the uncompressed ratios and existing graphs. But then my changes can be validated by seeing the gzipped filesize continue to drop after making changes.

So I would be happy just to see the gzipped filesize of the single bundle. That's good enough for me.

[Raynos]

this would be great behind an options flag.

[hughsk]

Definitely - I need to rewrite file-size-tree so that it can handle extra metrics. After that this should be easy to add as a flag, and/or a toggle so that you can compare minified/unminified size :)

[josephg]

👍 would be sweet

[Raynos]

@hughsk it would work for minified stuff.

[Raynos]

@hughsk as an unreliable heuristic I would recommend gzipping all "packages", i.e. all files in each package. Then adding that up, which will be bigger then the bundle gzipped.

Then show percentages i.e. which package contributes more.

The heuristic is that most of the sharing happens for files within a package, and that showing the break down at a per package level might be a useful rough count