When to minify?

[Jason S]

As a regular user with a high-speed internet connection I don't care
about minification.

As a peek-under-the-hood user, I don't like minification.

As a frugal owner of a website hosted by a pay-by-usage service
(http://www.nearlyfreespeech.net/) I use gzip to keep my costs down &
am aware of minification -- if my site usage goes up, it is an option
that I will use to reduce costs.

 

[Michael Wojcik]

This is ridiculous:

"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."

And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Frankly, as a user who on occasion has to debug scripts on other
people's pages (typically using Firebug) and fix them (generally with
Greasemonkey-injected scripts of my own), I think "minifying" is
damned obnoxious.

I've never felt the need to read web pages, much less attempt to use
ones with grandiose scripts, on a mobile device. If I did, I'd accept
the limitations of the tools I chose to use. I don't expect my toolbox
saw to cut as fast as my power compound mitre saw.

But if you want to cater to the technophiles, that's your business.

 

[Jorge]

And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

..js: 64592 chars.
..js: 43286 chars. (minified).
..js.gz: 14229 bytes. (gzipped).
..js.gz: 11561 bytes. (minified + gzipped).

43286/11561 = 3.74
64592/14229 = 4.54

As you guessed, the several Ks of whiteSpace allow gzip() to get a
better compression ratio.

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

 

[Jorge]

I've never felt the need to read web pages, much less attempt to use
ones with grandiose scripts, on a mobile device.

Yeah, but I'm talking about a webApp, not a page with some scripts.
You can't avoid big scripts with webApps, isn't it ?

 

[Gregor Kofler]

Jorge meinte:

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Gregor

 

[Jorge]

Jorge meinte:


Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Yeah, no need to gzip() either.

 

[Gregor Kofler]

Jorge meinte:

Yeah, no need to gzip() either.

Nope - since we are talking about *transferring* either 60kB or 14kB.
Once on the client it won't make a difference.

Gregor

 

[Jorge]

Jorge meinte:



Nope - since we are talking about *transferring* either 60kB or 14kB.
Once on the client it won't make a difference.

Gregor

I give up.

 

[Gregor Kofler]

Jorge meinte:

I give up.

Victory, at last! The heinous empire of minifiers defeated.

 

[David Mark]

How much javascript would you have when you decide that minifying is
called for?

Why would it matter how much?

The answer to "when to minify" is: right before you start testing the
script. As mentioned, if your server supports HTTP compression, then
the "minification" is mostly a waste (might help with the odd agent
that declines GZIP.)

 

[Thomas 'PointedEars' Lahn]

The answer to "when to minify" is: right before you start testing the
script. [...]

Right. And when the test fails, you go fix the bug ... wait a minute,
*you can't*.


PointedEars

 

[David Mark]

The answer to "when to minify" is: right before you start testing the
script. [...]

Right.  And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

 

[Michael Wojcik]

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Depends on what tradeoff developers want to make, of course, which in
turn probably ought to depend on what targets they're optimizing for.

If you're optimizing for devices with constrained resources (such as
mobile phones), then that 20KB of cache space might justify
minimization. If you're optimizing for really slow links, the 3KB of
additional data transfer might justify it.

If you're optimizing for users with lots of resources who might want
to read the source, you don't want to minimize. If you're concerned
about the possibility (however remote) of transformation effects, you
don't want to minimize.

Clearly, having relevant empirical data (as you now have for this
particular case) helps in determining what tradeoff to make.

 

[Michael Wojcik]

Yeah, but I'm talking about a webApp, not a page with some scripts.
You can't avoid big scripts with webApps, isn't it ?

It depends on the application. I've written applications with web
front-ends that use little or no client-side scripting. But I
recognize that's not common these days.

I avoid using web applications from mobile devices just as much as I
avoid reading web pages from them. But, again, I recognize that some
people like that sort of thing, or have other reasons to do so.

My point was that different users have different preferences, so I
wouldn't advocate minimization to optimize for mobile users, unless I
believed there was a good reason to optimize for mobile users. The
mere existence of mobile users does not constitute such a reason, as
far as I'm concerned.

 

[Thomas 'PointedEars' Lahn]

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

[...]
Clearly, having relevant empirical data (as you now have for this
particular case) helps in determining what tradeoff to make.

Yes, but only for that particular file and not as a general recommendation,
though. For the figures will be different with different code!

In particular, it depends very much on how many unnecessary repetitions
there are in the code already; many people (and it seems especially those
that use minifiers) don't know how to write scripts properly and e.g. repeat
property accesses over and over again. That accounts for repetitions of
characters (byte sequences) as relevant for the Deflate (and any other)
compression algorithm, and is likely to account for whitespace that
minifying would replace.


PointedEars

 

[Thomas 'PointedEars' Lahn]

The answer to "when to minify" is: right before you start testing the
script. [...]

Right. And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?


PointedEars

 

[Jorge]

Thanks. That's a useful data point.


Depends on what tradeoff developers want to make, of course, which  in
turn probably ought to depend on what targets they're optimizing for.

If you're optimizing for devices with constrained resources (such as
mobile phones), then that 20KB of cache space might justify
minimization. If you're optimizing for really slow links, the 3KB of
additional data transfer might justify it.

If you're optimizing for users with lots of resources who might want
to read the source, you don't want to minimize. If you're concerned
about the possibility (however remote) of transformation effects, you
don't want to minimize.

You forgot this one: if the server doesn't support HTTP compression or
if you're optimizing for UAs that don't accept-encoding:gzip, the 20k
of additional data transfer might justify it.

 

[Jorge]

(...)
many people (and it seems especially those that use minifiers)
don't know how to write scripts properly (...)

ROTFL

 

[Jorge]

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix.  You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Too complicated for you.

 

[David Mark]

David Mark wrote:
The answer to "when to minify" is: right before you start testing the
script. [...]
Right.  And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix.  You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Is this supposed to be a joke? For one, save the original
(obviously.) For two, who debugs by line number?