Mathias Bynens

Inline <script> and <style> vs. external .js and .css — what’s the size threshold?

Published · tagged with CSS, HTML, JavaScript, performance

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, 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”.


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.

About me

Hi there! I’m Mathias. I work on Chrome DevTools and the V8 JavaScript engine at Google. HTML, CSS, JavaScript, Unicode, performance, and security get me excited. Follow me on Twitter, Mastodon, and GitHub.


James wrote on :

Thanks for the info!

Kyle brought up an interesting point — how does one decide how to split a large JS codebase to best optimise it loading? Splitting code into logical chunks, each one in a separate file (e.g. myapp.core.js, myapp.form.js etc.) may make a lot of sense at first but then would it be better to put it all in one single file? Or, if the risk of maintenance is high, possibly splitting it up according to the maintenance risk of each file? …but then, how much can one split it all up before HTTP overhead becomes an issue?

E.g. let’s say I have 5⨉10 KB file (after min/gzip), each one contains a logically separate chunk of code that governs a specific part of my app. Every page in the app requires all of these files. All of the files are subject to change… Should I keep them separate, or perhaps combine them as 1, 2 or even 3 files? … It’s a tricky compromise — cache vs. maintenance vs. HTTP overhead etc…

Btw, @mathias, your comment textarea seems to deny regular keyboard shortcuts (like CTRL-Z to undo something)… It looks like you’re cancelling the keydown event.

wrote on :

Re-reading Kyle’s comments, I should probably add there’s more overhead to an HTTP request than just the headers. It’s probably a good idea to consider server latency as well. This can decrease performance significantly, especially when working with multiple files.

It’s good to consider HTTP headers, but let’s not forget there are other things that drive up the cost of an additional request.

Martin wrote on :

I found that the hightest cost is on loading external files is the DNS lookup and server connection times.

If the file is smaller than 5k the cost of load is bigger than inline.

Cthulhu wrote on :

Just the article I was looking for. I have a ~500 byte print.css file and a bigger (shared) CSS file, and was considering merging them using the @media command in CSS. But then I wondered where the limit was — from which filesize and upwards should one consider separating the download?

On JavaScripts, I had a bunch of jQuery libraries (both our own and third-party) that weren’t used on all pages, and wrote a simple bit of code that check if the required function is available. If not, it imports the script using a modified jQuery.get() method call (modified because by default jQuery will add a nocache parameter to the request, which isn’t what we want when fetching JavaScript files). This should more than halve the amount of JS / CSS downloads / requests on our websites.

artero wrote on :

I have developed an eCommerce suite where I do both CSS and inline styles.

My original CSS files where large as I combined everything into just 2 files, however as the webpages are created dynamically and specifically for the user’s setup, many of the styles in the CSS are not used on the page the user is viewing.

I reduced the CSS to global styles only and moved the specific styles to inline. This reduced the CSS file size by 60%. On dial-up speeds this has reduced load times dramatically.

With the maintenance of the inline I have no problem as this is stored in a database as a variable specific to its section of the page so when selected is used.

I’m now doing the same split with my JS scripts.

wrote on :

artero: Keep in mind that separate CSS or JS files only need to be loaded once — they can be cached afterwards. Inlining the CSS or JS code in the HTML means that this code has to be reloaded every time the page is reloaded.

Leave a comment

Comment on “Inline <script> and <style> vs. external .js and .css — what’s the size threshold?”

Your input will be parsed as Markdown.