If I'm designing a one page website, is it better to create external file for my JS code, or just put it in the html code? Is putting it on the page faster to load? Can I change the permissions to deny the users requests for the code, but the html page can still call the code?


You should put your JS code in a separate file because this makes it easier to test and develop. The question of how you serve the code is a different matter.

  • Serving the HTML and the JS separately has the advantage that a client can cache the JS. This requires you to send appropriate headers so that the client does not issue a new request each time. Caching is problematic if you want to perform an update and thus want to invalidate the client caches. One method is to include a version number in the filename, e.g. /static/mylibrary-1.12.2.js.

    If the JS is in a separate file you cannot restrict access to it: It is difficult (technically: impossible) to tell if a request to a JS file was made because you referenced it on your HTML page, or because somebody wants to download it directly. You can however use cookies and refuse to serve clients that don't transmit certain cookies (but that would be silly).

  • Serving the JS inside the HTML increases the size of each page – but this is OK if a client is unlikely to view multiple pages. Because the client does not issue a separate request for the JS, this strategy loads the page faster – for the first time at least, but there is a break-even point where caching is better. You can include the JS e.g. via PHP.

    Here the client does not need separate access to the JS file, which can be hidden if you like. But a anyone can still view the JS code inside the HTML.

Other strategies to minimize load times include

  • JS minification which reduces the size of the JS file you serve. As minification only happens once when deploying the code, this is a very efficient method to save bytes. OTOH this makes your code harder to understand for interested visitors.

    Related to minification is the practice of combinining all your JS files in a single file. This reduces the number of necessary requests.

  • Compression, which adds a computational overhead for each request on both the client and the server. However the time spent (de-)compressing is usually smaller than the time spent transmitting the uncompressed data. Compression is usually handled transparently by the server software.

These techniques also apply to other resources like images.

  • Images can be inlined into HTML or CSS with data-URLs. This is only practical for small, simple images as the base64-encoding inflates the size. This can still be faster than another request.
  • Multiple small images (icons, buttons) can be combined into a single image, and then extracted as sprites.
  • Images can be reduced by the server to the size in which they are actually used on the website, which saves bandwidth. Compare thumbnail images.
  • For some graphics, text-based images like SVG can be a lot smaller.
  • "Easier Test And Development", I'm not sure it's always helpful to have JS in it's own file for this purpose. In one project I use very small HTML files, and it is actually more organized to include them with the HTML. As far as caching goes, it can improve speeds across multiple visits (maybe), but for the first page load it is always going to be faster to include the javascript directly in the HTML. – YungGun Jul 8 at 14:13

I'm designing a one page website

If you literally just have one page then yes, it is better (from a performance point of view) to serve everything in the one file... stylesheets, JavaScript and even images (small images inlined with data-URIs). This eliminates the additional HTTP requests required to retrieve external resources which are relatively slow.

The resulting file should be gzipped before serving, which will massively reduce the size of the all-text response.

You should still consider having large images external to the page, as there are limits to the size of data-URIs and browser compatibility. (eg. IE8 has a limit of 32KB, which equates to an actual file size of about 23KB due to the nature of the base64 encoding.)

Can I change the permissions to deny the users requests for the code, but the html page can still call the code?

No. At best the code can be obfuscated in order to "hide" it from the casual observer, but it offers no real protection.

  • 1
    Why the neg vote? Whilst it is better for development and multi page sites to have separate/external files, the OP in this case is specifically asking about a "one page website" and whether it is "faster to load". Minimising HTTP requests should be a priority in this instance. You can (and should) still develop with multiple files, but that is not the question being asked. – MrWhite Jan 12 '14 at 16:52
  • By putting the js, css and images in separate files, you allow the browser to cache the files. So if the page content changes, only the html will have to be reloaded. – Thierry J. May 3 '17 at 7:50
  • @ThierryJ. Okay you can cache the files but on first page load (Which is very important to acquire new users) it is still much faster to include all files since caching is not in effect. Also, the computer still has to load the cached file, a step which is skipped completely if you include the file in the HTML. It is probably going to be faster to just have the file included in the HTML in the first place in almost every case. You're going to have to reload the HTML anyways, and the javascript portion cant be more than a hundred kB, it's negligible. – YungGun Jul 8 at 14:16

Client side JS code has to be seen by the browser (that is, if the page needs to use JS directly) - that means it has to bee downloaded by the browser.

You cannot have a browser use JS on the page if it cannot download it.

In that respect, it doesn't make a whit of difference if you inline the JS or put it in a file, though common practice is to use a JS file (separation of concerns for one).

If you have code that you do not wish to expose through to the browser, you will need to use server side code (say node.js, php, perl, asp.net, jsp - there are so many options) and interact with it from the browser - either on initial page loads or using AJAX.


Well it depends on amount of code, and how serious are you about being a programmer/software engineer versus just a coder. I worked with bunch of designers who put short snippets of code directly into HTML, and while I cringed – it actually worked.

Though it's not something I would do myself, and if you do want to know best practices of software development I strongly advise you to pu everything in external *.js file and load it via <script> tags.

Regarding your second point, no you can not deny user or browser to view your code, there is something called obfuscation which will make your code harder to read, however performance will degrade.


is it better to create external file for my JS code, or just put it in the html code?

It is better to create an external file for your JS code. It is also better to have one or two files that you serve to the client. But, it's also better to have your JS code split across multiples files for maintainability issues. To be able to do this, you can use preprocessors like Gulp that'll combine your different JS files to one file.

Serving less files is better since the client will have less HTTP requests to handle.

Is putting it on the page faster to load?

Yes, obviously it is faster since you only do one request for the HTML, while you'd do many requests (at least 2) with your JS code as an external. This is only if your JS code isn't minified in either side, and this doesn't take into account how harder it'll be to maintain your code if it's all in one single HTML page.

Can I change the permissions to deny the users requests for the code, but the html page can still call the code?

No you can't. JS code, like CSS code and HTML code is static content. That means once it's in the browser, the client can download it and its content entirely. Every single file, image, script is open to be downloaded. But, you can minify/uglify your code so that it's harder for a human being to use it. That is only a consequence of uglification, which was made for performance first.


Many Benefits of separating html and javascript content into separate files:

  • increases readability of individual files ofcourse
  • since the javascript code is not confined within an html file anymore, the other html and javascript files or libraries can use your javascript code
  • similarly javascript code put into a separate file can easily use other files and advanced libraries to do complex calculations (machine learning , 3D graphics, framework, etc libraries)
  • javascript can be cached on the client side and through that only html content needs to be reloaded on page refresh
  • good/modern software engineering practices can be applied more easily to a separate javascript file/module/library (design patterns, read about typescript/babel, etc)
  • javascript code can be easily obfuscated or 'hidden' from the visitors to the webpage by minification/uglification
  • javascript files can be bundled together into a single file/module through gulp, webpack, etc
  • 1
    this doesn't seem to offer anything substantial over points made and explained in prior 6 answers – gnat Aug 29 '18 at 11:13

protected by gnat Aug 29 '18 at 11:12

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.