[Phpmyadmin-devel] not uglifying js for production

[Rouslan Placella]

On 06/19/2013 08:49 AM, Dieter Adriaenssens wrote:
> 2013/6/19 Mohamed Ashraf <mohamed.ashraf.213 at gmail.com>:
>> On Tue, Jun 18, 2013 at 3:44 PM, Michal Čihař <michal at cihar.com> wrote:
>>> Hi
>>>
>>> Dne Tue, 18 Jun 2013 12:01:22 +0200
>>> Mohamed Ashraf <mohamed.ashraf.213 at gmail.com> napsal(a):
>>>
>>>> A web server that is configured to support gzip would help alot more
>>>> than minification anyway and provides a much smaller size whether the
>>>> files are minified or not. Most web servers and web browsers already
>>>> support gzip compression so it is not a problem. also the javascript
>>>> files are already aggressively cached so it is not a big problem.
>>>
>>> Indeed gzip can save transfer size, minified code has also benefits for
>>> parsing and execution time due to shorter identifiers. Or at least
>>> Google claims so:
>>>
>>> https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
>>
>> I just did a small test to see how much does minifying and/or gzipping
>> affects file size. I chose to use the list of scripts requested in the
>> main page as a reference for a large number of scripts downloaded at
>> the same time to maximize the differences.
>> original js 1.4M
>> minified js 629K
>> gzipped original 331K
>> gzipped minified 181K
>>
>> when using gzip the difference of 150K is negligible since this is
>> only downloaded once in every session and every other request only
>> gets one or two extra js files since your ajax script takes care of
>> that caching. an extra 150K for the first page download is not too
>> much to ask since it is more than likely to be cached by the browser
>> itself. for normal page accesses only one or two extra scripts are
>> requested. here is the same breakdown for a single js file. I chose
>> server_database.js arbitrarily
>> original js 4.3K
>> minified js 1.8K
>> gzipped original 1.4K
>> gzipped minified 811B
>>
>> the difference between the gzipped original and minified is just 600B.
>> that is not much.
> 
> This seems reasonable to me.
> 
> I'd suggest to drop the js minification to being able to get a stack
> trace for the error reporting.
> Thanks for investigating, Mohamed.

Thought I'd mention that third party libraries (jquery, jquery plugins,
etc) can stay minified IMO. All we really care to debug is our code.
Besides, the public API of any external library will remain unmangled.

>>>> considering that with minified files you would get zero to no
>>>> information on the source of a javascript error. I think it is a small
>>>> price to pay for error reports; otherwise most error reports would be
>>>> "ReferenceError: a is not defined in line 7" where line 7 is the
>>>> entire jquery source minified. Having understandable error reports is
>>>> worth paying a few extra KB. notice that not all scripts are fetched
>>>> at once every page load thus it is at most a few KBs more per request
>>>> is not much
>>>>
>>>> I think this is the best course of action for proceeding with the
>>>> collection of error reports since we are giving deployers the option
>>>> of turning this feature off altogether and provide minified files to
>>>> their users if it really came to that.
>>>
>>> That's option as well, though it increases size of our package...
>> since the package is gzipped it is not that big of an increase also
>> the package is usually just a one time download so a small increase in
>> size is not muxh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20130619/d37992d7/attachment.sig>