3 ms·
It seems to me that unless the likelihood of a cache miss is fairly small you need to balance the probability of a cache hit against the expense of an extra HTT
by spokey 16y ago
It seems to me that unless the likelihood of a cache miss is fairly small you need to balance the probability of a cache hit against the expense of an extra HTTP call, as opposed to bundling the JQuery libraries directly with your custom JS with some JavaScript minimization trickery (and two HTTP calls if you're using both jquery and jquery-ui).
I have no doubt that the likelihood of a cache hit here is growing, but I wonder what the likelihood of an actual hit is? These data show that 4.7% of the top 1000 Alexa sites use some version of JQuery. What you'd need to consider is the likelihood that your visitor has (a) visited one of the those 47, (b) that is using the same version of JQuery as you are, and (c) has done it recently enough that the (relatively large) files are still locally cached. I suspect that for most sites that works out to much more than 4.7%, but is it more than 50%? If not aren't half of your users getting a slower response as a result?
(Moreover, and I don't know if or how this effects the JQuery CDN, but doesn't it seem like many sites drag because of delays in loading the Google Analytics JavaScript files? Wouldn't this pose an even greater problem if you're using Google to serve JQuery, since your UI depends upon it?)
- MicahWedemeyer 16y agoOn the other hand, if you don't want to mess with minimization/packaging trickery, this gets you a nice quick win.
- mike-cardwell 16y agoWhere is the messing? Where is the hassle? wget https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.mi... -O main.js cat local.js >> main.js
- photon_off 16y agoI started off using Google CDN to host my jQuery file, then later ditched it because about 20% of the time there would be a noticeable delay in retrieving it (if I'd cleared my cache). There's really no reason not to just host jQuery yourself. Use GZip, and set a far-future expires header. Ensure the jQuery file is named by version, so that if you update the version the cached filename will be different. That's all you need to do, really. One last note: The benefit of putting script tags at the bottom of the body is very similar to having the scripts cached in the first place. Just in case you didn't know, putting script includes at the bottom of the page lets the browser render the page progressively as it retrieves the HTML text [generally very, very quickly]. Scripts in the HEAD block rendering, as the browser needs to be load each script file sequentially, in case there are dependencies. [Note: not exactly true, it will grab several in parallel and execute them in order, but there's still a delay.] Whether or not the scripts are cached, very fast page rendering will make the page appear to have loaded quickly. Likely, the user will not require javascript by the time the scripts are loaded anyway, if they aren't already cached.
- mnutt 16y agoThose are all good points, although as a different method you can offset some of the load time of putting scripts in the head tag by flushing the head as soon as possible: http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/ http://yehudakatz.com/2010/09/07/automatic-flushing-the-rail... (not a new idea, just new to rails)
- _harry 16y agoYou can also speed up load time using LAB.js http://www.labjs.com http://www.labjs.com It loads and executes all scripts in parallel. Just be careful and hide any elements that rely on javascript before the scripts finish loading.