Home/ Questions/Q 7789739
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T21:23:25+00:00

Let’s say I’m building a static 10-page website for a client, and there’s only

  • 0

Let’s say I’m building a static 10-page website for a client, and there’s only a few lines of JavaScript for the whole site (less than 1KB). In this situation I’d guess that it’s best (for performance) to put the <1KB of JavaScript code inline between script tags on every page, rather than in an external .js file. The extra bandwidth consumption (when moving between pages) is probably worth it for removing a whole HTTP request.

At the other end of the spectrum, if I had 200KB of JavaScript on the same website, then I’d definitely put this in a separate file to reduce bandwidth when moving between pages on the site.

But I’ve no idea where the ‘cut-off point’ should be. If I have 5KB of JS, should I just put this inline in my HTML? What about 10KB? 20KB?

Obviously the ‘cut-off point’ is going to depend on the situation, e.g. it might be different for mobile sites. But if anyone has any general pointers that would help guide this decision, then I’d like to hear them.

(NB: I’m interested only in performance here, not maintainability etc. I can keep my code in separate files but use some kind of build process or serverside middleware to automatically inline it, so maintainability will not be an issue.)

(Bonus points: please let me know if all the considerations are exactly the same with inline vs. external CSS.)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m strictly talking about performance here, more as a thought experiment (and please excuse the lack of experimental rigor).

    If you’re inlining the javascript, yes you do save time in the fact that everything is done in one http request. However, you should factor in the time it takes for a server to dynamically generate the webpage that you need (SSL also adds time to this).

    Best case

    If you can create a build that generates minified javascript and injects it into an html page, combined with gzip compression, you should result in a much lower bandwidth. The more text you stick in the compression, the bigger your payoff compared to individually gzipping per request. Ultimately, this means if you can have it load a single html page statically with all the javascript/css inline, this means it will definitely be faster.

    Normal case (with dynamic html and shared js libraries)

    A small sample of some stackoverflow posts and how they affect my own bandwidth:

    304ms 9.67KB
204ms 11.28KB
344ms 17.93KB
290ms 17.19KB
210ms 16.79KB
591ms 37.20KB
229ms 30.55KB

    Judging from this, it seems like the overhead incurred (disregarding filesize) is around 150ms for each http connection – perhaps in the worst case. Now, the question is, how big does the text (javascript in your case) have to be for your bandwidth to incur 150ms. According to this article (http://www.telecompetitor.com/akamai-average-u-s-broadband-connection-speed-is-now-5-3-mbps/), for broadband users, we are working with an average of 5.3 mbps (which is .6625 MB/s or 678.4 KB/s or .6784 KB/ms). This means that for the average broadband user, you will need roughly 100KB download of gzipped+minified javascript for it to equal.

    Please adjust the parameters yourself to see what this may mean for your audience. This number, whatever you calculate it to be, is the point at which you may be better off serving it inline (through server-generated response) versus fetching it/caching it externally.

    All in all, I don’t think that for performance reasons, this is a bottleneck at all. The size of compressed + minified javascript is usually negligible and it has to be on orders of unmaintainable magnitude that it would matter.

    • 0