Is it better to load many small JavaScript files or one large JavaScript file?

Question

I have noticed in chrome that if I load an image as a base64 string and then scroll through that part of the page it will slow down.

I have also noticed that when I navi

Answer 1

Well there is a very popular concept called concatenation. The idea is to have as few HTTP requests to your server as possible. Because each request means a new connection, for which DNS lookup happens, then handshake is negotiated and then after a few more protocol-based steps, the server sends the requested file as the response.

You can check http-archive for a list of performance best-practices.

So yeah, you should combine all JS files into one (there are certain exceptions, like js at head and js in footer)

This is the answer for your question-title and points 2 & 3.

As for the other part, I am not clear about the scenario you are talking of.

Answer 2

I recently had the same problem, and then I developed and released a JS library (MIT licence) to do this. Basically, you can put all your stuff (js, images, css ...) into a standard tar archive (which you can create server side), and the library reads it and allows you to easily use the files.

You'll find it here : https://github.com/sebcap26/FileLoader.js

It works with all recents browsers and IE >= 10.

Answer 3

Generally, loading more files incurs more overhead in HTTP than combining them into fewer files. There are ways to combine files for all kinds of content:

• For images, use CSS sprites.
• For javascript, compile your client-side code and libraries into one file, and minify to reduce size.
• For css, you can do something similar to the above. hem compiles stylus into one css file, for example, and this can help organizationally as well.
• Additionally, when you concatenate Javascript and CSS, your webserver or reverse proxy can send them in compressed form for faster page loads. This will be more efficient for larger files as there is more to gain from compression.

Answer 4

There are way too many maybes for this to have any guaranteed solutions, but here you go:

1) load CSS at the top -- load it all there, if you're doing a site with multiple pages. If you're building a one-page application (where you're running galleries and twitter feeds and articles, etc on the same page, and you can open and close different sections), then you can consider loading widget-specific CSS, at the time you're loading your widget (if it's not needed at startup).

Do NOT use @import in your CSS, if you want it to load quickly (you do).

2) load the vast majority of your JS at the bottom of the page.
There is practically nothing that can't be lazy-loaded, or at least can't be initialized at the bottom of the page, after the DOM is ready, and if there really is, serve those as separate files at the top of the page, and consider how you might rewrite to depend on them less.

3) be careful with timers -- especially setInterval... ...you can get your page's performance into a lot of trouble with poorly-managed timers.

4) be even more careful with event-handlers on things like window-scroll, resize, mouse-move or key-down. These things fire many, many times a second, so if you've written fancy programs which depend on them, you need to rethink how you fire the program (ie: don't run it every time something the handler goes off).

5) serving JS files is a trade-off: Compiling JS takes a while. So if you're loading 40,000 lines in one file, your browser is going to pause for a little while, as it compiles all of that.
If you serve 18 separate files, then you have to make 18 different server calls.
That's not cool, either.

So a good balance is to concatenate files together that you KNOW you're going to need for that page, and then lazy-load anything which is optional on the page (like a widget for adding a comment, or the lightbox widget, etc).
And either lazy-load them after all of the main products are up and running, OR load them at the last possible second (like when a user hits the "add comment" button).

If you need to have 40,000 lines loaded in your app, as soon as it starts, then take the hit, or decide what order you can load each one in, and provide "loading" indicators (which you should be doing on lazy-load always) for each widget until it's ready (loading the JS one at a time).

These are guidelines for getting around general performance issues.
Specifics are hard to answer even when you have the site directly in front of you. Use the Chrome dev console for profiling information and network performance, and rendering performance, et cetera.

Answer 5

The number of files to load has an impact on the load speed of the whole site. I would recommend to pack into a single javascript file all the required functionality for the website to display properly.