3 ms·
Interesting to see that the parsing does not work on a stream anymore, but on a whole 'file'. This gives up the real world optimisation of starting work on a p
by illumen 15y ago
Interesting to see that the parsing does not work on a stream anymore, but on a whole 'file'.
This gives up the real world optimisation of starting work on a partially downloaded file on slow network connections.
Even fast internet connections take a while to download 1MB of javascript. Not to mention the majority of internet users on slower connections.
I think this work could be improved to go back to the old behaviour.
- bzbarsky 15y agoThat optimization never existed for <script> loads in Gecko in the first place. And it turns out that the optimization is overrated, especially for the common case of the 1MB file being in your cache anyway.
- spjwebster 15y agoAccording to the stats gathered by HTTP Archive, the average response size (i.e. after compression) of a JavaScript file is 15kB: http://httparchive.org/interesting.php#responsesizes http://httparchive.org/interesting.php#responsesizes This will make JavaScript parsing faster for the vast majority of sites, and for the majority of users. If you have a single JavaScript file that is 1MB after gzipping, you really should think about modularising your code and lazy-loading the bits that aren't immediately required. See http://ajaxpatterns.org/On-Demand_Javascript http://ajaxpatterns.org/On-Demand_Javascript
- nonane 15y agoAlso, don't forget that in most cases the JS code is probably loaded from the browser's cache anyway.