Re: Reducing js file sizes...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 23, 2009 at 11:10 AM, Boyle Owen <Owen.Boyle@xxxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@xxxxxxxxxx]
>>
>> Would that not prevent browser-level caching of the javascript ?
>> If yes, that would probably more than cancel any advantage of the
>> "minification", no ?
>
> I don't know for certain the OP's motivation but it may not be just to save bandwidth...
>
> There is a security imperative for cleaning up JS - comments, and even variable names, can reveal details about  your server's implementation that may assist an attacker. You can (should?) go the whole hog and obfuscate the code too (re-write variables to "a", "b", "c" etc, remove white-space, etc..)
>
> Rgds,
> Owen Boyle
> Disclaimer: Any disclaimer attached to this message may be ignored.
>

I don't really see how JavaScript could reveal anything about your
server...it's client side, so it shouldn't have anything to do with
your server. I mean, if you're writing things in your comments like
"// Oh yeh, the password to my server is foobar", then that's a whole
other matter, but you probably deserve what you get for that anyway.
Other than that, I'm very curious to know what sort of security
concerns you're thinking of, perhaps it's something I need to address
in my own code.

Anyway, for the OP and others, if your concern /is/ response time, one
thing to keep in mind is balancing network traffic transmission time
with minification processing. If you reduce transmission time from 1
second to half a second, but it takes 3 seconds to do the
minification, you've gained nothing but freeing some bandwidth on the
pipe (which is courteous of you, but probably not what you want). I
think this of particular concern with some of the "better" (read, more
thorough) minifiers which parse the entire script and rewrite it with
small arbitrary variable names, etc., as opposed to just filtering it
like JSMin does. These certainly lead to smaller scripts, but take a
significant amount of extra time to run.

I think a nice alternative is to use a filter that will run the
minification as necessary but simultaneously pipe the output to a file
on the server. For each additional request, it can just check to see
if the minified file is out of date compared to original, and if not,
it can read directly from that file. There will be an initial time
penalty on the first request after modifying the original script, but
from there on out, it /should/ (I think, I haven't actually tested
this) be significantly faster than re-running the minifier while still
getting the reduced size and making sure it's always up to date (as
opposed to serving the minified content statically and having to
remember to regenerate it yourself when you make changes to your
original).


As long as we're on this topic, I'd like to step up on my soap box for
a minute and beseech my fellow web developers to use minification
thoughtfully. Reducing network traffic and speeding up load time is
definitely a worthwhile goal, but we should always bear in mind that
the web should be an open place to exchange ideas and techniques. Few
things about web developing are more frustrating than seeing something
cool on a person's page, and viewing the source only to find it's been
minified to the point of obfuscation. If there are legitimate security
concerns, then obviously that's a separate matter, but if the purpose
is just minification, I think it'd be a real nice touch to precede the
minified content with a brief comment indicating the URL for the
original (unminified) source. Okay, I'll stop preaching now.

-Brian

-- 
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://pgp.mit.edu/

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux