Fewer big files or many small files?

soupmix said:

Which is better to use with my CSS / JS / etc - fewer big files or many small files?

I am wanting the fastest experience for my end users and my thought up until now has been that I should have more, smaller files, especially if that means that I can host more of them on a CDN. However, I keep hearing things that suggest that it's better to have fewer connections and thus fewer, larger files. Any thoughts?

Click to expand...

I agree with what you heard as a common, generic opinion shared by many.

Reasons - some speed related, some FYI, to back this up:

• HTTP 1.1 makes servers unable to send many resources with a single connection so "less is more" in terms of connections.
  
• You can manually cache the offset of each file within the big file, to avoid the need to read file system directory entries (which can involve multiple seeks per file opened if you miss the cache).
  
• Developers gain full control of the order of the data within the file, so they may arrange it to minimize the need for slow seeks.
  
• Data compression is more effective on a single big file, than on individual files.
  
• Easier deployment of software as needed.
  
• If you get alot of queries, opening files can be expensive, in this case you might need to cache your files, or your search queries for better performance

Gaming systems use large files for the same kind of reasons and CSS sprites are a direct result of the HTTP 1.1 issue I noted above, so a few big usually wins for common situations.

BUT (yep, always a "but") --- all this depends on site traffic, of course, and the quality of the cache system involved in the CDN as you noted that in your question. Remember, using a CDN is yet another connection and is costly enough, but the benefits of security and consolidation, etc., outweigh minor speed and time degradation, my .02.

Ah, don't waste too much mental energy on this --- you'll always get a different answer depending on who you ask and most modern CDN's have robust cache systems which saves a ton of system resources which really is the key to performance.

Don't think of files as needing to be small or large. Think of them needing to be the right size.

For example lets say you have 20 JS functions. Package related functions together in the same file. For some websites this could be all 20. For others it may work breaking it up in to 4 or 5 files. It all depends on what each page needs to load.

Fastest experience possible... it's all relative. If your site has a dozen or so scripts with 1000 lines or less each then the page load times will be meaningless to humans. We are talking milliseconds. Better to spend time on newer tech instead of combining old tech.

Check up on websockets or node.js for the fastest experience when your site starts getting millions of hits per day.

Fewer big files or many small files?

Greetings to all,

I do not agree with couple of you guys. I think the file size is very important if you want to make your site faster. For example it is not the same if your server serves a css file "heavy" couple of hundred kB or couple of tenth kB.

The same rule is for js files, and you must know that each website serves a couple of css and js files per page. So the conclusion is: size or weight of the files HAVE some important role on visitor's loading (not so important like before, because connections are now much more faster)..

But i think, beside the size of the files on your website, you should know how to deliver your css and js files to your client. Is gonna be in couple of links which makes a few http requests or just in one link where everything is summarized..

There's one interesting tool that google like to promote, and that tool is free to use. it is tricky to install it for someone, but it can be very useful. The name of that tool is Minify and it is very easy to find it if you use google search..

Good luck and best regards to you all

@shelle:
You are correct, file size is important, but have you done any statistics on site load times regarding file size? Let me give you an example: I have a site with a fairly large css file; almost 3100 lines at about 59kb. The load time for the is literally a couple of miliseconds, the call and connection is 3 times that duration. So back to the original question, is it better to have several smaller files or one big file and how do you get a couple hundred kb from a css file? Is that thing something like 30,000 lines? At that point, you should just go a trim the fat. There is a whole lota bad in there.

That's where I chimed in with my humble opinion. Sure a Smart car gets better gas mileage than a Diesel Ford F350, so in some drivers minds it is the best choice. But I argue that point all together. Why shrink old tech? Why not pick up something new, like a Tesla Model S. Now you have a fantastic car with zero gas cost, plus no radiator, no oil changes, no emissions.

I feel that a few milliseconds is not worth the effort for 1000 hits a day. If your site is getting big and taking on a million hits a month, then the answer is not minifying but redesigning.

I propose websockets and node.js. Both technologies can decrease page load times 10 - 100 fold, so now we are talking about instead of loading in 3 seconds, we can get it down to 30 milliseconds.

To the OP:

Remember when I said, "Ah, don't waste too much mental energy on this --- you'll always get a different answer depending on who you ask..."



Sure enough, last couple of replies, and everyone is right. For example as Shelle noted, CSS load times can be reduced dramatically by minimization (or by using CSS sprites). Multiple JavaScript and CSS files should be compressed and merged, not just for bandwidth concerns but to resolve issues with older browsers where a limit of individual linked CSS or JS files is capped. And I already noted why bigger is better in terms of indexing and connection processing. And 960design is correct in stating this is all about milliseconds in the end game, although it is worth pointing out large enterprise level clients who spend money based on bandwidth usage and bursts -- every millisecond is costly so designing a CDN and ensuring certain key scripts are compressed, GZIP enabled, etc., is key.

I just want to re-emphasize that real performance comes more from caching and compression, combined, regardless of file size or bandwidth.

Fewer big files or many small files?

Hi,

@960design:

I never saw a css file with 30,000 lines. If there's such a css then it is big, fat file which needs to be delivered to the website visitor. I suppose it is "heavy" more then 500kb, where it can be the same like someones whole site.
Anyway, if some website have or requires a lot of style sheets and framework, which is manifested with 30,000 lines in css, then you will not have one big, fat file. You will have a several css files that determine certain boxes on the site.

In that way you will increase the number of HTTP requests which is against all written advice and recommendations that can be find on the Web..

If you have a couple of css files, the best way of serving them is to use Minify, as i mentioned before, because you will not have served files in this form:



but you can have served files (css for example) in one line:

<link type="text/css" rel="stylesheet" href="/min/b=wp-content&f=chili/recipes.css,themes/orangesky/style.css,plugins/jquery-comment-preview/jquery-comment-preview.css" media="screen" />

where those files will be also compressed. So the accent is on reducing the numbers of HTTP requests and also compressing the same files (.js and .css)

Also if your business is starting to grow up and your website traffic increases madly, then I advice to upgrade your hosting, because you can not have some successful effects by using shared host. For a million hits per month you must have some good dedicated hosting or even cloud webhosting that can stand the rush.

In that case i can recommend Google's PageSpeed Service, although if you are monitoring statistics of your website on StatCounter for example, you will not be able to see some things because the IP address will be lost by crossing with Google's IP address..

Regards

@shelle:

I'll agree that if you HAVE to deliver several css files then minifying a final production file IS better; but you keep using the word BEST. BEST implies that there is no other solution.

BIG sites use node.js, websockets, ect to handle the load.

I completely understand what you are talking about, it may be that you have yet to explore what node.js or websockets does.