When to separate files to save bandwidth

Question

I'm doing some optimising for my site and am trying to figure out just how big some inline code can be before it can justify having it's own file instead of being written inline.

My guess on how to measure it would be that the amount of code (CSS or JS in this case) would need to be bigger than the HTTP packets sent and received to get a 304 response.

Please ignore the fact that it's a good practice to keep styles and javascript out of the HTML page and think only in terms of browser performance. :)

Answer 1

Honestly, in terms of browser performance, separating your CSS & JS files out and properly setting expires headers so they are cached will increase performance, not degrade it. The browser will cache it and never request it again, which reduces the amount of data transferred during multiple page views.

Only if a majority of your audience is coming to your website with an empty cache and only viewing 1 page would inlining CSS & JS help.

See:

• http://developer.yahoo.com/performance/
• http://www.ryandoherty.net/2008/10/12/optimizing-openspacebook/

Answer 2

I'd also like to add that you should combine your JS/CSS into one download (each) if possible, to save on HTTP connections to the web server. I believe Yahoo suggest this in their URL that Ryan posted. I ended up writing my own .NET component that can combine scripts and CSS, and also minimize them if needed and cache them (server side.)

Answer 3

Agreed with Ryan, however, IF your audience will ever only see your site once, or if you never want files to be cached then include CSS and JS inline.

Best practice is to have your server combine and gzip all CSS/JS files into one cacheable file to save requests and bandwidth.

This can easily be setup in at least Tomcat and Glassfish.

Answer 4

Looking into it myself a bit more; I think I'm on the right track.

The actual HTTP request looks something a little like this:

HTTP/1.1 304 Not Modified
Cache-Control: max-age=604800, public
Last-Modified: Tue, 17 Jun 2008 17:20:41 GMT
Date: Mon, 20 Oct 2008 03:49:58 GMT
Server: ucfe

Which is about 163 bytes right?

By having a look here (http://www.freesoft.org/CIE/Course/Section4/8.htm) it looks like a TCP packet itself can range from about 20 bytes upwards.

So I would guess the total request + response look like about 250 bytes (guessing 30 bytes for tcp packet + a bit of padding for the request and response text) all up. Nothing really.

I think then that everyone is right. It's not a big deal. Still interested on how this impacts mobile browsers however as latency of multiple requests is going to be the big issue.

Please speak up if I've made a mistake in my calculations