Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display gzipped size #87

Open
thom4parisot opened this issue Jun 5, 2018 · 11 comments
Open

Display gzipped size #87

thom4parisot opened this issue Jun 5, 2018 · 11 comments
Labels

Comments

@thom4parisot
Copy link

Hello!

I find this project super useful. Thank you so much for making it real 🙂

I was wondering what is the cost to add the gzipped value of a module (and its dependencies)? It might be more realistic if most of the I/O to the npm registry happens to be compressed (I have no idea about the stats).

I quite liked this info on https://bundlephobia.com/[email protected] (compared to https://packagephobia.now.sh/[email protected]).

What do you think?

@styfle
Copy link
Owner

styfle commented Jun 5, 2018

Hi Thomas!

I'm glad you like Package Phobia 😄

I'm not sure I understand your request.
Are you suggesting that Package Phobia should display the same information that Bundle Phobia displays?

In the example you linked to (webpack), I don't think the results that Bundle Phobia displays actually mean anything, since webpack doesn't bundle itself.

Can you elaborate?

@thom4parisot
Copy link
Author

thom4parisot commented Jun 5, 2018

@styfle eh eh 🙂 Sorry if I was unclear and thanks for encouraging me to rephrase the idea 👍

I can see on Package Phobia the cost of downloading webpack is 14MB (during npm install).
I took for granted the 14MB figure is uncompressed, on disk (after https://registry.npmjs.org/webpack/-/webpack-14.11.0.tgz is unpacked).

I found out the I/O cost to be interesting too—how much a package weighs on the bandwidth before hitting the disk. Therefore I was wondering if the transfer size was a difficult information to display for both publish and install size… if that's considered useful?

That's the bit I liked in Bundle Phobia (knowing the very end result, what's supposedly transfered over the wire).

Let me know if there is some more details to add to make it more understandable 😅

@styfle
Copy link
Owner

styfle commented Jun 5, 2018

I understand now.

Do you think displaying the size of the tarball (the unpacked size) would be sufficient?

Or do you think it would be better to actually attempt to calculate the bits transferred on the network (I would image there is more than one HTTP request)?

@thom4parisot
Copy link
Author

Let me try to answer with one picture 😄

screenshot-2018-6-5 package phobia

@styfle
Copy link
Owner

styfle commented Jun 5, 2018

Nice mockup 👍

How can we effectively measure the "transferred" data?

@thom4parisot
Copy link
Author

thom4parisot commented Jun 6, 2018

It seems to be advertised in the HTTP response headers:

$ curl --head https://registry.npmjs.org/webpack/-/webpack-4.11.1.tgz
HTTP/2 200
date: Wed, 06 Jun 2018 09:38:54 GMT
content-type: application/octet-stream
content-length: 246611

Unpacked size is 1.2MB according to npm metadata (npm view webpack dist.unpackedSize) and 247KB according the HTTP header. The first figure is interesting disk-wise whereas the second is interesting I/O wise. The latter reflects the performance cost of retrieving that stuff from the Internet.

I guess the total transfer size would be the module content-length + all the dependencies of dependencies content-length as well. It looks like the easiest starting point from my standing point.

What do you think?

@styfle
Copy link
Owner

styfle commented Jun 6, 2018

The dist.unpackedSize from npm is almost identical to the publishSize that Package Phobia reports. See https://packagephobia.now.sh/[email protected]

There is some discussion going on in an RFC which got moved to here.

I guess the total transfer size would be the module content-length + all the dependencies of dependencies content-length as well. It looks like the easiest starting point from my standing point.

That makes sense, I'm not sure if there are other HTTP requests made besides tar balls so that might be worth further investigation.

My other concern is how to display this data point in the bar chart.
Do we add a third color? It might feel a bit busy.

@thom4parisot
Copy link
Author

thom4parisot commented Jun 6, 2018

From what I read on the other two issues, it seems the space on disk and the bytes transfered are two different levels of reading (and expectations).

The first thing which comes to my mind is a toggle Disk Space (o ) Transfered Data (on top of the left hand side column ?). Which means it should imply no change to the layout aside of sourcing a different data store to populate the charts and the readable figures.

@styfle
Copy link
Owner

styfle commented Sep 7, 2018

@oncletom Sorry for the delay.

I think the toggle is a good idea to show a different chart!

However, I think it's best to implement #124 first and then come back to this feature. I believe file count will be much easier to implement when compared to "transferred" data. Once that gets nailed down, we can revisit this feature.

I hope you don't mind waiting a bit longer 😄

@thom4parisot
Copy link
Author

No worries, and there is no issue waiting.

I like #124 in how it shows an additional way of measuring package install performance hit.

Thank you for your work 🙂

@styfle
Copy link
Owner

styfle commented Dec 14, 2018

FYI, there is a tool that accomplishes what you are looking for: https://arve0.github.io/npm-download-size/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants