Let’s just get it out there: the only size that matters for a CSS or JavaScript file is its gzipped size.
And by gzipped size I mean: the size of the file after it’s compressed using gzip’s compression algorithm. All browsers since IE6 have supported gzipped assets, and enabling gzip on web servers has been a best practice for years now; therefore it’s relatively safe to assume that everyone who cares about the size of CSS or JavaScript files is gzipping them.
So if you’re trying to find how big a front-end library is, the answer you need is not in Finder or Windows Explorer. While the uncompressed file size can give you a rough idea, you have no idea what the user will actually download until you gzip the files.
Running gzip
If you’re on OS X or Linux, you can run the gzip
command on any file to compress it. For example the following shows the before and after of compressing jQuery 2.1.0.
There are two things to note here:
gzip
made quite the difference in file size - 82K down to 29K.gzip
replaces the original file;jquery.js
is nowjquery.js.gz
.
Because replacing the original file is a bit annoying, you can make gzip
generate a new file with a little shell magic, shown below.
gzip
command has a --keep
option that preserves the original file. So you can run gzip jquery.js --keep
instead of gzip < jquery.js > jquery.js.gz
.Why It Matters
There is no set percentage that gzip
will reduce the size of a JavaScript or CSS file by. There is no way to know for sure other than running gzip
.
To show this, let’s look at the specific situation that made me feel the need to write this.
414K! Yikes! But remember, this is the file size that is shown in Finder, not the size that the user is actually going to download from a server with gzip enabled.
To see what the user will actually download, we have to run gzip
. Below we run gzip
on each of jQuery Mobile’s files.
As you can see, gzip
reduced our two files down to a combined 88K. Quite the difference! Take note of one more thing: the drastic difference running gzip
made on jquery.mobile.css
- 216K to 25K. A savings of 88.5%!
Why was the compression so successful here?
jQuery Mobile 1.4 made a big change to the way they handle images - namely, they now embed images directly within their css file to avoid separate HTTP requests. Because of this change, their CSS file is packed full of data URIs.
How does this relate to gzip
?
At a high level, the compression algorithm that runs under the hoods of gzip
finds repeated strings and replaces them with symbols. Because of this, the files that compress best are the ones with a lot of repeated strings - such as a file with a bunch of data URIs.
Just look at all the repeated strings in jQuery Mobile’s CSS. gzip
is practically salivating.
Note: If you concatenate your files gzip
gets better. Bigger files = more repeated strings to substitute.
Wrapping Up
Anyways, the point is: if you’re assessing the size of a library, framework, or whatever - run gzip
on it first. Since it’s what the user actually downloads, it’s the only size that matters for front-end assets.
Because size is paramount in jQuery core, they actually make changes to improve how well the library is optimized by gzip
’s compression algorithm.