3 ms·

Wouldn't tiny code like this better included in the HTML itself? A fraction of a packet size versus a HTTP request.

by aw3c2 16y ago

udp 16y ago
That would become an awful mess pretty quickly. One extra HTTP request per script dependency is a pretty acceptable trade-off for keeping things tidy, especially nowadays with things like keep alive and pipelining. If you have a custom backend, you could always give it a list of frontend scripts to send and send them all to the browser as one big virtual "scripts.js" file. Then you get the best of both worlds - all the scripts in one HTTP request, but in a separated, maintainable file structure on the server. (The modified date to compare to/set scripts.js for caching purposes would be the highest out of all the script files, obviously)
- rbranson 16y ago
  ^^^ this. Sprockets is a good way to do this if you're using Rails. If you don't need something quite as sophisticated, Rails has built-in asset caching that will combine your JS and CSS files into a single file automatically by just putting :cache => "identifier" on the asset tag helpers. You should probably still try to use the major CDNs for very popular libraries like Prototype, jQuery, etc. These are more likely to pull from cache and not incur any additional transfer time.
  - DTrejo 16y ago
    And for scripts that google is too slow to put on their cdn... http://www.cdnjs.com/ http://www.cdnjs.com/
amadeus 16y ago
When deploying to live, you should compress all JS and aggregate into a single file.
- morganpyne 16y ago
  This has been shown to not necessarily always be the best option for performance. See http://blog.getify.com/2009/11/labjs-why-not-just-concat/ http://blog.getify.com/2009/11/labjs-why-not-just-concat/, and http://yepnopejs.com/ http://yepnopejs.com/ The best and brightest in the JS performance area now mostly advocate using some form of loader to load the JavaScripts, bearing in mind that the overall page speed and perceived performance can be affected by more factors than simply the number of script files that need to be requested. Hence the recent proliferation of things like yepnope.js, require.js, lab.js etc. The fastest and best approach for your particular site will be specific to your site and there is no generic solution guaranteed to be optimal.

Wouldn't tiny code like this better included in the HTML itself? A fraction of a packet size versus a HTTP request.

by aw3c2 16y ago

Wouldn't tiny code like this better included in the HTML itself? A fraction of a packet size versus a HTTP request.

udp 16y ago

That would become an awful mess pretty quickly. One extra HTTP request per script dependency is a pretty acceptable trade-off for keeping things tidy, especially nowadays with things like keep alive and pipelining. If you have a custom backend, you could always give it a list of frontend scripts to send and send them all to the browser as one big virtual "scripts.js" file. Then you get the best of both worlds - all the scripts in one HTTP request, but in a separated, maintainable file structure on the server. (The modified date to compare to/set scripts.js for caching purposes would be the highest out of all the script files, obviously)

rbranson 16y ago
^^^ this. Sprockets is a good way to do this if you're using Rails. If you don't need something quite as sophisticated, Rails has built-in asset caching that will combine your JS and CSS files into a single file automatically by just putting :cache => "identifier" on the asset tag helpers. You should probably still try to use the major CDNs for very popular libraries like Prototype, jQuery, etc. These are more likely to pull from cache and not incur any additional transfer time.
- DTrejo 16y ago
  And for scripts that google is too slow to put on their cdn... http://www.cdnjs.com/ http://www.cdnjs.com/

amadeus 16y ago

When deploying to live, you should compress all JS and aggregate into a single file.

morganpyne 16y ago
This has been shown to not necessarily always be the best option for performance. See http://blog.getify.com/2009/11/labjs-why-not-just-concat/ http://blog.getify.com/2009/11/labjs-why-not-just-concat/, and http://yepnopejs.com/ http://yepnopejs.com/ The best and brightest in the JS performance area now mostly advocate using some form of loader to load the JavaScripts, bearing in mind that the overall page speed and perceived performance can be affected by more factors than simply the number of script files that need to be requested. Hence the recent proliferation of things like yepnope.js, require.js, lab.js etc. The fastest and best approach for your particular site will be specific to your site and there is no generic solution guaranteed to be optimal.