views:

157

answers:

2

I started with 5 normal human-readable JavaScript files - they were around 10 KB in total.

After using YSlow, I decided to merge the 5 files and pack them using Dean Edwards' packer. Now I have 1 file that is 4.5 KB.

When I re-run YSlow, it is now showing the JavaScript file in the primed cache under 'statistics', where previously (when I had the separate files) the 5 files would have been cached.

So I now have 4 fewer HTTP requests but the total page weight for the primed cache is up by 4.5 KB.

Am I doing something wrong?

I am still planning to put a far-forward expiry date header on my JavaScript folder so this issue will likely disappear, but I'm still interested to know why it won't cache the JavaScript files.

A: 

I don't think you are doing anything wrong at all, you are following all basic best practices.

When you download something from a webserver that doesn't have expires set properly, which I assume is the case since you want to fix that, the primed cache will always be higher because YSlow thinks that the browser needs to download it even when it has cached everything.

This is because the cache is set to expire when its downloaded it because there is not Expires header. Updating your expires to have a long living expires will definitely sort your issue out.

AutomatedTester
Well the thing that puzzles me is that the original 5 files also came down with no expires header and yslow indicates that they would not be fetched again with a primed cache. Afer the merge into 1 file and the basic packer (without encoding) it wants to get the js file every time.
Nils
I'm going to close this question - although the behaviour is odd, the thing to do to solve it is definitely to set the expires header so I've accepted this answer. Thanks!
Nils
A: 

Read this article. Here they show how to reload the cache after upgrade of your files.

valli
Thanks, but my new file does have a different name to all of the original 5 files and the names do include this version number technique.
Nils