When is it acceptable to use inline <script> elements? When is it better to use separate .js files? The same question can be asked about inline vs. linked CSS — where do you draw the line?

I had been pondering about this for a while, but while writing my post about optimizing the asynchronous Google Analytics snippet I was reminded I didn’t have a solid answer to my question yet. Is it worth it to separate the Analytics snippet into a separate .js file, so it can be cached? Or would that be a bad idea, considering the additional HTTP request needed to retrieve just a few hundred bytes of data?

Obviously, I wasn’t gonna figure it out by myself. So I decided to ask Kyle Simpson, creator of LABjs; and Billy Hoffman, of Zoompf fame. (Thanks, guys!)

Here’s what Kyle said (emphasis mine):

I’d say the threshold for me on ‘size’ would be around 400–600 bytes, or approximately 6–8 lines of JavaScript code. Generally speaking if something is less than ½ KB, it’s not worth being in its own file, nor is it worth the HTTP overhead (even factoring in caching). This opinion takes into account the following things:

1. HTTP request overhead size is roughly 500-700 bytes on average (including request and response headers — but not including cookies!). So, if I’m spending more bytes of transmission to get content than the content itself, that’s probably a bad sign.

2. A non-trivial amount (don’t know the exact statistics, but probably roughly 3–5%) of users have no (or practically none) caching ability at all. This is even more true when you consider really small caches like those found on mobile phones. So, in those cases, a separate file request for the sake of caching is completely lost on them. They are paying the ‘penalty’ of loading that file every time. And for mobile users especially, this is bad because they also are generally on slower/less reliable connections, so the impact can be doubly negative.

3. Many people suggest combining all local .js files into one file as a way to address the HTTP overhead issue. In general, reducing HTTP requests is good, but going all the way down to one file may not be optimal. Consider loading and caching behavior with a single big file that has a dozen other files concatenated together in it. Firstly, the single bigger file will load slower since it loads byte-by-byte serially than if say two files, each half the size, were loaded in parallel. Secondly, a big concatenated file is more likely to have changes more frequently, which means that if even one character of that big file changes, every single user now has to re-download the entire file with lots of unchanged (and now unfortunately uncached) content wasting bandwidth/time.

So, since the ga.js loading/initialization code should pretty much never change, you would want to make sure that you combine it with other local script code that also doesn’t change very often — for instance, if you have a stable library file that only changes once every 3–6 months, this would be a better file to tack the code onto than say a file that has experimental or user-experience oriented script logic in it that might change frequently as you tweak your site’s content.

Billy raised some interesting points as well (again, emphasis mine):

The first thing to keep in mind is we are talking about approximately 320 bytes. The choice is should we include this 320 bytes in every HTML page, or place them in a JavaScript file that will get cached.

The main benefit to the async snippet is to not block the browser when downloading the ga.js file. According to Builtwith.com, so many sites are using GA that it is almost certain a cached copy of ga.js already exists on the machine so this blocking is hardly ever a big deal. The only other real benefit is that maybe you’ll be able to register a hit even if the user doesn’t fully load the page because you can put the async snippet at the top.

Making an HTTP requests costs roughly 100 ms (the average TTFB I’ve seen, though it can be as low as 50 ms or 60 ms). Let’s say 100 ms. Let’s also say someone has a low powered DSL connection, say 786 kilobits per second. Thats means they can download 786 * 1024 / 8 = 100,608 bytes a second, or roughly 10 kilobytes every 100 ms. Someone would have to visit approximately 32 pages on your website for the overhead of them downloading that 320 bytes of the GA snippet over and over again to equal 100 ms, the amount of time to fetch the snippet in a JS file.

So if you don’t have any external JS files already, creating one just for the GA snippet is silly and not worth it. However, if you already have a JS file, and you are loading it async using LabJS or something, then including it could help you. Of course, at the end of the day, we are talking about 320 bytes ;)

Update (December 2011): Guy Podjarny wrote an interesting article on this, in which he concludes that “[t]he HTTP overhead of a request & response is often ~1 KB, so files smaller than that should definitely be inlined” and also that “testing shows you should almost never inline files bigger than 4 KB”.

Conclusion

It’s probably a good idea to place small code snippets of just a few hundred bytes inline in the document, unless you’re using separate files for scripting or CSS anyway. In that case, it’s better to just merge the code in there, since the ratio of bytes lost in making the HTTP request vs. file size is much smaller compared to creating a separate file just for the tiny snippet.