What's more important, as little http requests as possible or splitting files for easy development?

Question

A lot of times when reading about web developping on the internet I hear that you should split up your javascript and css files into multiple files.
Like split up your css files in a:

• clear.css
• base.css
• page_specific.css

Or that you should even split those up into files containing positioning, colour and typography information.

But isn't it true that a browser is only allowed to make two simultaneous http requests? Splitting the files up into that many would create a whole load of http requests. Isn't it better to just split them into two files, a page specific and and a base/clear css file? and then send them with loads of cache headers?

I understand that splitting up the files is easier for development but shouldn't speed be more important?

Answer 1

I think that it's better to make separate files - it's much more 'supportable' approach.

But in production you could use some sort of solution to join CSS (or JS) files in one file:

Automatically join Javascript and CSS into a single file

Answer 2

I split them moderately as required for sane maintenance; HTTP 1.1 multiple requests per connection, pipelining, and caching go a long way to mitigating the overhaed of having multiple files. That said, I wouldn't want to have hundreds of the little buggers. But, 3-7 CSS files, sure. And absolutely separate JS and CSS out of the HTML.

Answer 3

Premature optimization is the root of all evil. First make your code easy to write and maintain. If later-on you find that the number of files is a bottleneck, you can add a step in your build process that will combine them into a single file. This step can also remove comments and white space.

Answer 4

It's the whole premature optimization thing.

I think It's better to organise your code in a way that makes most sense to you, and then find a tool to combine the files for when you put the site live. There are a number of scripts out there that will do this for you.

Having a large number of files per page will certainly knock performance.

IE7- support two concurrent HTTP connections per server, IE8 increases this to 6.

I would imagine pipelining, as supported in HTTP 1.1, would mitigate the connection limit issue, but it is disabled by default in FF and IE, Opera has it enabled.

The MS Ajax Control Toolkit actually has built-in script combining with the ToolkitScriptManager control.

A good MSDN article, a tool for ASP.NET, and another.

Answer 5

Why not have the best of both worlds?

What I do with my projects is keep multiple CSS and JS files in a src directory and then have a script to combine them together and compress (pack) each one into a "myproject.pack.js" or "myproject.pack.css" file. Creating a shortcut to run this script in my IDE makes this entirely painless and gives you the benefits of having heavily commented and logically separated JS and CSS files, combined with the benefits of single HTTP requests and minimised code.

Answer 6

G'day,

I was going to recommend having a look at the rules developed at Yahoo by Steve Souders and maybe install the associated YSlow plugin but...

Googling YSlow led me to an interesting article by Jeff Attwood at his Coding Horror site about tailoring the YSlow advice based on the fact that, as Jeff puts it

... Yahoo's problems aren't necessarily your problems.

This article is full of useful info for the question you ask and offers more than the rote "just use the YSlow plugin and follow the suggestions" advice.

Definitely a value add. Thanks Jeff.

cheers,

Rob

Answer 7

Here's my two cents: It doesn't matter if you have 100 JS/CSS files, weighing 1MB each. It's only going to slow down the first opening of your page. After that they will get cached on the client and all will be fine. So definately go for maintainability and logical seperation.