Optimize only when you have a reason to.

Measuring Javascript Parse and Load

While studies like this are fascinating to observe and to learn from, be very careful — unless you’re doing something like distributing JS libraries, these optimizations probably do not apply to you.

Keep in mind that the parse-and-load test runs 1000 iterations; in the first table, the actual average parse time is really only 0.125ms at worst and 0.003ms at best. Compare that to the average HTTP request — you might see sub-30ms responses just for a HTTP 304 on a good day, but 1000ms+ responses are not unheard of on unprimed caches (even more with DNS lookups). To put this into perspective, a snappy HTTP request at 30ms is more than 200 times slower than the slowest parse time of 0.125ms.

In other words, the net improvement you might gain from such parse-and-load optimizations is insignificant compared to the improvement from removing just one HTTP request.

So before you go adding more lines of code to accomplish yet another new trick, profile your code to see where the actual bottlenecks are. Otherwise, this smells like a lot like premature optimization.

Update: I’ve wrongly interpreted the results table and Carlos has corrected me. This means that the cost of script parsing and loading is significant, and optimizing this should help reduce CPU load which is hard to benchmark in real world conditions but could certainly be perceptible to users.