Wednesday, May 2nd, 2007

Squeeze CSS and JS into one file

Category: Articles, CSS, JavaScript

If you wanted a hack to allow you to put JavaScript and CSS into the same file you got it:

Posted by Dion Almaer at 7:49 am
22 Comments

+++--
3.3 rating from 6 votes

22 Comments »

Comments feed TrackBack URI

I was thinking about this possibility, too, but some client may need different MIME headers for CSS and JavaScript, so it’s not really a solution, as I think. But a nice hack anyway. :)

Comment by András Bártházi — May 2, 2007

minimizing the number of http-requests could be the aim.
but as andrás stated, not really a solution :)

Comment by leo — May 2, 2007

Cute, but a bit rediculous.

I’m still hoping FF will implement css:expression() someday!

Comment by Marty — May 2, 2007

Oh, hell no. Want to save file requests? Go back to inline styles and scripting and leave the rest to professionals…

Comment by The Hater — May 2, 2007

Nice little hack, but useless!

First, broadband connections get faster every day!
Second, you can minimize http-requests by simply put your js and css into your html file using ASP, PHP, RUBY etc. That minimizes the http-requests to 1 + n, where n is the number of images you need in your design.

Comment by Georges — May 2, 2007

This prevents effective caching. Every time my JS changes, the “CSS” file also has to be downloaded and vice versa. Separating the files allows them to be separately cached.

Comment by Jeff Schiller — May 2, 2007

Why on earth would you want to do this? Separating behaviour and style is GOOD, thowing them in with each other is BAD. This is a hack, to allow you to do something that nobody should be trying to do in the first place.

Comment by JoeBoy — May 2, 2007

An interesting approach. I do wonder about the time required to send out those extra <– characters, as opposed to the latency of two separate HTTP requests. The latter might just be faster.

Comment by Mark Wubben — May 2, 2007

“If you wanted a hack to allow you to put JavaScript and CSS into the same file you got it”… Well, we don’t want it… ;)

Comment by Will Gillen — May 2, 2007

ARGH! Hideous!

Want a trick on how to style without CSS?! Font tags!!

These things are supposed to be separated.

Comment by Dan Atkinson — May 2, 2007

Well, there are some misunderstanding in the comments above I would like to make clear. At first, it isn’t a bad idea to pack together the CSS and JS file, I recently deployed a project where I had the same problem and was thinking about doing the same somehow. Removing one element from the request row not just means removing the time of building the connection, but letting an other element to download parallel. The browser can download two elements a time, and if the JavaScript and CSS files are downloading, images and others cant. Just removing one element can mean that the first image will appear faster. Anyway, my final decision was that just don’t change how the net working, and leave them two separated files. :)

Ideas about moving the styles and javascript files into inline HTML are just stupid (you were ironic, I know). We have to optimize for 2 things: first time download and average downloads. After the first time, the files outside of HTML will be cached, and even if the browsers pings the server if they were changed, it’s much faster than inlining them. So, if you plan that your visitors will see just one page at all at you, or your site with extras like CSS/JS is very small, you can use inline CSS/JS. On the other side, moving the out of HTML will mean caching and separation, which will income on average download times.

Comment by András Bártházi — May 3, 2007

“two separate HTTP requests”
If the webserver supports Keep-Alive, it can happen (depends on browser behavior), that all the objects on the page will be downloaded in one single HTTP connection.

Comment by Magyusz — May 3, 2007

Just gzip the stuff, set an expire header so the browser never asks for a file a second time, and use versioned paths. Done. No hacking around

Comment by Martin Bialasinski — May 3, 2007

Good to see my blog being discussed here… I implemented this technique keeping in mind the non US customers, especially people from fareast countries like India and China for whom saving even a single request (especially a blocking request like JS, CSS) adds a good value. It did give noticeable improvement for our pages.

This technique is not for all – if you are a person loosing your night sleep thinking about improving your webpage load time then you would want to use this – others please don’t bother.

Comment by Shiva — May 3, 2007

To answer the people who say to put the css and js inline, this prevents caching across pages. If you had one include file containing css and js and it was the same for all pages, it would stay cached for the entire visit.

Limiting the number of http requests is a good idea for very busy sites. Having been slashdotted recently, I know that servers can only handle a certain number of simultaneous http requests. If you have 9 graphics on your home page, a css file, a js file and the page itself, that’s a total of 12 http requests. Removing one of these hits theoretically increases your server capacity by over 8% which.

Will I use this technique, probably not. But if I do think its remarkably clever and would be fun to play with.

Along these same lines, one of my co-workers found that you can base64 encode an image and embed it right in the page. :-) <img src=”data:image/png;base64,iVBORw0KGgoAAAA…”

Comment by Matt Nuzum — May 3, 2007

Nice trick. And not really useful, which makes it even better :)

Matt Nuzum: bare in mind that the 9yo RFC 2397 data: URI scheme is still not supported by IE ( not even 7 )

Comment by Mathieu 'p01' Henri — May 3, 2007

This is actually cool, despite most of the awkward and weird negative comments. This could actually be practical for full blown web apps where speed really matters.

Comment by Dustin Diaz — May 4, 2007

Haha Shiva that base64 string in the image tag is incredible. WOoo!

Comment by Kurt — May 10, 2007

Whoops I meant Matt, thnx Matt.

Comment by Kurt — May 10, 2007

Ok, the reason for reducing requests is not because people are “dumb” or should go back to inline styles. The issue is that as broadband speeds increase protocol overhead becomes more of an issue than download size. So reducing requests can really improve performance. Most people with large sites have elaborate build processes that allow keeping css, js, html all separated for ease of development (keeping functional pieces seperate, which we all know is a best practice). So during build time we can assemble the files however we like. If every page in a site uses the same JS and CSS file, it would make sense to serve the both together. The mime-type issue makes this a non-starter, but it would be nice. In general, I like to keep it down to three requests outside of images. On home pages I embed all the js and css in the page, because most users don’t make it past the home page so they should get the fastest load time possible, then inner pages separate to allow deep users of the site to take advantage of caching.

Comment by Stephen — May 14, 2007

ASP.Net has a concurrent connection limit of 2 per session, therefore if more than 2 requests hit the server at the same time, only the first two requests are processed, the others a queued.

Therefore rather than “hacking” resource files together and taking internet development back 10 years, why not increase the concurrent connection limit in your web.config.

Obviously a little common sense is needed when setting this value; you need to take into account server hardware, traffic and bandwidth etc.

Also, your local IIS (localhost) has no connection limits so you will only notice performance benefits on a production server (Unless you’re running 2003 as your desktop).

More information can be found at http://msdn2.microsoft.com/en-us/library/aa480507.aspx

Comment by John Howard — August 8, 2007

ASP.Net has a concurrent connection limit of 2 per session, therefore if more than 2 requests hit the server at the same time, only the first two requests are processed, the others a queued.

Therefore rather than “hacking” resource files together and taking internet development back 10 years, why not increase the concurrent connection limit in your web.config.

Obviously a little common sense is needed when setting this value; you need to take into account server hardware, traffic and bandwidth etc.

Also, your local IIS (localhost) has no connection limits so you will only notice performance benefits on a production server (Unless you’re running 2003 as your desktop).

More information can be found at

Comment by John Howard — August 8, 2007

Leave a comment

You must be logged in to post a comment.