6

I have used 5 JavaScript compressors to compress a JavaScript library (JSMin, YUI compressor, Packer, closure compiler and UglifyJS)

Now I know that closure compiler is the winner in reducing the filesize. However, I also want to test out the performance gains. What would be a good way to do this?

I made a simple test page that uses all the library's public methods. Is there a tool for testing out the page speed of this test page? Eg. running it X times on a browser and return the average loading speed.

Thanks for your answers!

Chielus
  • 632
  • 8
  • 18
  • What do you want to measure? Load time via HTTP over the public network? The time the JavaScript parser spends parsing the JavaScript text? The time the interpreter spends running the result? The majority of the tools you've listed will only help with the first (HTTP load time), the Closure compiler being the odd man out because it actually modifies your code (inlining functions, etc.) whereas the others are largely about symbol length reduction and (in some cases) obfuscation. – T.J. Crowder May 24 '11 at 08:22
  • possible duplicate of [What is the best way to profile javascript execution?](http://stackoverflow.com/questions/855126/what-is-the-best-way-to-profile-javascript-execution) – Felix Kling May 24 '11 at 08:25
  • The whole package. I want to test the speed gain for the user. Stopwatch from getting the testpage till every public method has finished. – Chielus May 24 '11 at 08:27
  • Some say compressed code with google's closure compiler can actually reduce the performance... So I would like to test what gives the best efficiency: Uncompressed, Compressed or Compiled. – Chielus May 24 '11 at 08:30
  • @Chielus use the search. That topic has been covered many times. The best is closure compiler the slowest is Packer. – sra May 24 '11 at 08:30
  • All you need to know is the size of the compressed scripts. The download times are proportional. Browsers should execute both compressed and uncompressed code similarly. – HyderA May 24 '11 at 08:39
  • @gAMBOOKa: *"The download times are proportional."* It's more complex than that, because of connection setup time, keep-alives, etc., but yes -- generally, smaller = faster. :-) Re compressed vs. uncompressed code, some packers introduce overhead, and things like the Closure compiler actually modify the code. – T.J. Crowder May 24 '11 at 08:52

4 Answers4

1

There's no need to be complex about it: 

<html>
<head>
    <script>
    var time = new Date();
    </script>
    <script src="..."></script>
    ... more scripts ... 
</head>

<body>
<script>
    document.write("Time: " + String((new Date() - time)/1000) + " seconds");
</script>
</body>
</html>

Scripts in the <head> generally load serially, so this should be a reasonable method for measuring script execution time. If you have scripts executing form <body onload="...">, then do the time elapsed calculation at the end of that function instead of the end of the body.

This method would not measure execution time for "asynchronous" functions executed via setTimeout or setInterval, but those shouldn't count against load time.

An alternative and likely simpler option is to use the javascript profiler built-in to Chrome or Safari's web inspector.

Seth
  • 45,033
  • 10
  • 85
  • 120
0

I suspect the PageSpeed tool is what you're looking for.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 1
    I knew about pagespeed, its timeline feature can be useful. However, it's only useful for running once. It would be better to run it X times and take an average. Can this be done somehow? – Chielus May 24 '11 at 08:35
  • In practice its very difficult to use this to measure actual improvements in performance without using a network throttler. – symcbean May 24 '11 at 08:47
  • @symcbean: Yeah. Or my equivalent of a network throttler: A slow VPS server somewhere on a 100Mbit (or even 10Mbit) connection. :-) – T.J. Crowder May 24 '11 at 08:58
  • It doesn't need to be precise, It just has to provide a comparison between the compressors – Chielus May 24 '11 at 12:07
0

Use PageSpeed or YSlow on firefox or HTTPAnaylser on IE to test the time load differences.

sushil bharwani
  • 29,685
  • 30
  • 94
  • 128
0

It really depends on what your audience cares most about the site. Time to appear on screen? Time to load-complete? Animation smoothness? Interactive responsiveness? Or raw calculation speed?

You should profile your site compressed with different minifiers based on what the most important metrics are.

Side Note: The Closure Compiler in Simple Mode only yields minimal speedup's. It gets file size down, but the JavaScript program remains the same. To get significant code reduction and speed optimizations, you have to use Advanced Mode.

Stephen Chung
  • 14,497
  • 1
  • 35
  • 48