2

From the Ruby on Rails documentation:

The first feature of the pipeline is to concatenate assets. This is important in a production environment, because it can reduce the number of requests that a browser must make to render a web page. Web browsers are limited in the number of requests that they can make in parallel, so fewer requests can mean faster loading for your application.

This is widely considered a best practice around the web. But doesn't conventional logic tell us that loading even three files in parallel is faster than loading a concatenated version serially. So even if there is an upper limit on the number of parallel connections, it should be faster than waiting for one huge file on a single connection. Or does it have to do with the overhead for each request?

Neil
  • 3,100
  • 5
  • 29
  • 36
  • 1
    Coupled with a caching plan, you're much better off. Javascript, for instance, stops page loading while it downloads. – Jared Farrish Dec 31 '12 at 12:53
  • So if page loading is stopped while it downloads, you want all the js to download as quickly as possible. Having multiple streams of data is faster than having one, so while this highlights why downloading the assets quickly is important, it doesn't resolve how serial is faster than parallel. – Neil Dec 31 '12 at 12:57
  • There *is* an upper limit on the number of parallel connections (I believe its 5). If you have 1 CSS file and 1 JS file, that doesn't leave much room for things like images, video, etc. – cimmanon Dec 31 '12 at 12:58
  • 1
    It sounds *great*. In some cases, maybe it is. Do some profiling with Chrome, Firebug of Fiddler, though, you'll see. Take a look at the Yahoo home page source sometime. It's designed to be that way. – Jared Farrish Dec 31 '12 at 13:00
  • The site this guy was working is NSFW (no nudity, though), but he was having some real problems with his page loads. So I analyzed his timings. See the result here: http://stackoverflow.com/questions/12649681/waiting-status-caused-by-incorrect-placement-of-elements-nsfw/12650160#12650160 – Jared Farrish Dec 31 '12 at 13:16

1 Answers1

1

The HTTP specifications suggest 4 concurrent connections at the same time. So every browser will be by default set around this number. So, when your page has more than 4 files (including images) it makes sense to concatenate.

For most browsers it is possible to change the number of parallel connections, but that works than only on your machine and not for the user.

Sven Bieder
  • 5,515
  • 2
  • 21
  • 27
  • In that case, having 4 concatenated files would be optimum. If you're only downloading 3 streams at once, that's a wasted opportunity right? So say you configure the asset pipeline to always generate 4 files. Then you're wasting opportunities on a browser set to say 5 connections. Taking that to its logical conclusion, isn't it better to have the assets defined in small chunks, and then let the browser download as many as possible in parallel. Each of those parallel streams then acts as a serial one so it would be similar to downloading those assets in one concatenated file, right? – Neil Dec 31 '12 at 13:03
  • 1
    @Neil Don;t forget all the other little files you download while page load. every image, icon, video and so on. I don't think that your page will be free of such files. The best is to try the different possibilities out (with the different browsers) and see in what file-configuration your page loads fastest. It is also important to look how big your js and css files are. If you have a lot of small script files, the request for each one needs longer than the download. That would be another point to concatenate them. – Sven Bieder Dec 31 '12 at 13:06