Why is my javascript bundle so slow to download?

Question

I have bundled all my js libraries into one large file in order to spare a number of http requests.

But for some reason it takes 9.29 seconds (sometimes +15) to download this bundle of 1.2mb.

In this case the bundle isn't minified, but even when it is, it takes like 4-7 seconds for 783kb, so not much better.

But the biggest mystery is: if I refresh the page 5-6 times fast, then load time gets normal (~150ms). It keeps being normal everytime I refresh then. But if I wait for like 5min. and make no requests. Then the load time is slow again.

And also when I run my application in local environment, it always loads fast.

Now I have two questions for you all:

1: Is it wrong to concatenate ALL my libraries into one single file?

2: Why does it take almost 10 seconds to download ~1mb in my case?

Please do also take a look at the pictures, showing the request load time and my request-headers

Answer 1

The cause of very slow loading of JS scripts can be multiple and many answers have covered very well some possible causes.

I have myself run into such an issue, having a minified JS script of about 800KB which was taking 26 seconds to load (!). In my case, the file didn't have the X attribute set on the JS file on the server. And there was no gzip compression enabled on the server. I fixed these two and things sped up a lot. Loading times are now under 1 second.

Answer 2

1: "Is it wrong to concatenate ALL my libraries into one single file?"

There is no right and wrong answer here, it very much depends on whats in the bundle, and how its used (so im assuming your concerned with load speed in general). Some thoughts:

In general its pretty much always a good idea to combine & minify JS, CSS (and images should be combined into sprites). Fewer bytes on the wire will transfer quicker, fewer requests create less overhead, oh and it costs less. But...

• When you say "ALL my libraries" are you including libraries that are available via a public CDN? If so, i would consider using those alternatives. Theres a reasonable chance the end user already has a given file from a large/trusted CDN like google, and if they dont it will be downloaded quickly, in parallel to your site loading, and at no cost to you. (if your security conscious this might be unacceptable relying ona 3rd party to host a required library - but its a trade off with a potentially large saving in load time - depends on what libraries your including).
• Browsers limit requests per hostname (so it depends how many requests in total you make), so it can make sense to use more than one subdomain/domain/cdn in order to load in your assets (id keep it to 1 or 2 additional domains).
• Depending on how many libraries your combining, and how often they are used, it could make sense to load specific libraries only on pages that require them (you could even lazy load them on pages that dont require them so they are already cached, but dont hold up rendering other page). Scripts that are only required on a single page could justifiably be moved to the HTML or a separate script file and would improve the average pageload speed.

2: "Why does it take almost 10 seconds to download ~1mb in my case?"

You said it yourself - "local environment ... always loads fast". Your problem is the distance the data has to travel, not how well packed it is. Travelling over localhost is going to be pretty much instantaneous however many scripts you load, going out over the internet and back adds latency to establishing connections. Your transfer speed is restricted by the slowest "link in the chain" between browser and server.

In order to reduce the distance between your computer and the server you should consider caching your files and hosting them behind a CDN. Requests from browsers are routed to a CDN Edge Location server thats geographically local to the requester. If the CDN has previously cached the request, its returned immediately (and over a much shorter distance, so faster). If the CDN Edge location hasnt yet cached the file, it will make a request on your end users behalf (via a super quick private network) to your server (referred to as the Origin), and if headers allow cache the file for future requests.

Caching can cause big problems, so my advice is to use a cache busting query string. This gives the benefit of CDN & browser level caching - ie huge speed improvements, but still allows you to easily update your code and ensure visitors will retrieve the most recent version. Assuming you had a minifed file ~/minified.js, you would reference it as ~/minified.js?v=1 (the name/value isnt important). In the future you can then replace ~/minified.js, and update your markup to ~/minified.js?v=2. This requires your actual HTML isnt cached, or at least uses a short lived cache, but means the browser will treat v=1 and v=2 as 2 separate requests, so will download/cache them.

A few other thoughts:

• Depending on the application it might be viable to split your javascript into 2 bundles. A critical path script that is small and downloads quickly and contains the bare minimum to allow the page to start rendering. Then a larger, lazy loaded script containing everything else that will download at some point later in the page load. While this increases the total overhead in transferring the files, and is basically side-stepping the problem it could allow your pages to begin rendering much sooner making them "appear" faster. Also, you can embed your critical path code into the HTML - adding a couple of KB to the initial payload, in return for the script being available as soon as the HTML is parsed.
• CloudFlare offers a free CDN package - its basic, but might be suitable (and includes free SSL).

Answer 3

1: Is it wrong to concatenate ALL my libraries into one single file?

Ans: We should concatenate all libraries into single file. But it should be a proper manner. Like it should not conflict any variable while merging all file in single. You have to use minify tools for that Like Gulp.. https://www.npmjs.com/package/gulp-concat

2: Why does it take almost 10 seconds to download ~1mb in my case?

Ans: Might be possible to not proper minify your js file. But it should work fine. Please follow below steps:

HTTP requests are how browsers ask to view your pages. When your web page loads in a browser, the browser sends an HTTP request to the web server for the page in the URL. Then, as the HTML is delivered, the browser parses it and looks for additional requests for images, scripts, CSS, Flash, and so on.

Every time it sees a request for a new element, it sends another HTTP request to the server. The more images, scripts, CSS, Flash, etc. that your page has the more requests will be made and the slower your pages will load. The easiest way to reduce the number of HTTP requests on your pages is to not use many (or any) images, scripts, CSS, Flash, etc. But pages that are just text are boring.

How to Reduce HTTP Requests Without Destroying Your Design Luckily, there are several ways you can reduce the number of HTTP requests, while maintaining high-quality, rich web designs.

Combine Files – Using external style sheets and scripts is important to keep them from bogging down your page load times, but don’t have more than one CSS and one script file. Use CSS Sprites – When you combine most or all of your images into a sprite, you turn multiple images requests into just one. Then you just use the background-image CSS property to display the section of the image you need. Image Maps – Image maps are not as popular as they once were, but when you have contiguous images they can reduce multiple HTTP image requests down to just one. Use Caching to Improve Internal Page Load Times By using CSS sprites and combined CSS and script files, you can also improve load times for internal pages. For example, if you have a sprite image that contains elements of interior pages as well as your landing page, then when your readers go to those internal pages, the image is already downloaded and in the cache. So they won’t need an HTTP request to load those images on your interior pages either.