Re-optimization ... where is the limit?

I think you all know that modern browsers, when processing the page code, download plug-in files (styles / scripts / pictures) in parallel. The number of parallel connections by default is limited to two to six at a time. Most of the recommendations to reduce the time of initial loading of the page states that it is better to glue smaller files into one larger one. Further research is intended to establish the reasonable limits of this recommendation.


The experiment involves browsers Chrome 23, Firefox 16, IE9. Ping to the server ~ 41ms, gzip is enabled on the server, the conditions are as close as possible to the combat ones. So, what will we die / watch? Create a test page with style sheets attached to it. The test page is a necessary minimum (Doctype, html, head and body) Connecting styles of different sizes, we will measure the page load time and the load time of a separate file. On the basis of the data obtained, we make conclusions about how long it is worth to glue the files together.

Test number 1.
Single file size - 2.1Kb
Gzipped (including http headers) - 451b
Number of connected files - 10
')
Chrome

onload = 208ms
connecting + waiting = ~ 83ms
receiving = ~ 2ms

FF

onload - 291ms
connecting + waiting = ~ 88ms
receiving = ~ 1ms

IE

onload - 417ms
connecting + waiting = ~ 190ms
receiving = <1ms

Chrome and FF showed almost the same result, the response time is approximately equal to double ping (send a request - we get a response), but IE strangely rasparalel requests, because of which some of them were forced to wait for the end of the previous ones. The data transfer time is much less than the time to create a connection / response. In this case, it makes sense to glue the files.

We glue files, size - 208Kb (1.14Kb gzipped), browsers load the page at this speed:
Chrome - 142ms ( -42% ), FF - 165ms ( -44% ), IE - 389ms ( -7% )

Test number 2.
Single file size - 20.7Kb
Gzipped (including http headers) - 523b
Number of connected files - 10

Chrome

onload = 284ms
connecting + waiting = ~ 110ms
receiving = ~ 1ms

FF

onload - 352ms
connecting + waiting = ~ 90-130ms
receiving = ~ 1ms

IE

onload - 830ms
connecting + waiting = ~ 190ms
receiving = <1ms

We glue the files, the size will be 20.7Kb (523b gzipped), and browsers will load the page at this speed:
Chrome - 203ms ( -29% ), FF - 208ms ( -41% ), IE - 680ms ( -19% );

Test number 3.
Single file size - 207Kb
Gzipped (including http headers) - 1.14Kb
Number of connected files - 10

Chrome

onload = 368ms
connecting + waiting = ~ 70-80ms
receiving = ~ 30ms

FF

onload - 1.03s
connecting + waiting = ~ 88ms
receiving = ~ 0ms (??? Firebug issue?)

IE

onload - 5.55s
connecting + waiting = ~ 300ms
receiving = ~ 8.4ms

If you merge files, the size will be 2.2Mb (8.2Kb gzipped), and browsers will load the page at this speed:
Chrome - 401ms ( + 11% ), FF - 919ms ( -9% ), IE - 1.29s ( -77% );

Test number 4. (from science fiction)
Single file size - 4.9Mb
Gzipped (including http headers) - 17.3Kb
Number of connected files - 10

Chrome

onload = 6.3s
connecting + waiting = ~ 2s
receiving = ~ 2.3s

FF

onload - ~ 19s
connecting + waiting = ~ 600ms
receiving = ~ 0ms (??? Firebug issue?)

IE

onload - 21s
connecting + waiting = ~ 4s
receiving = ~ 3s

If you merge files, the size will be 48.5Mb (169.2Kb gzipped), and browsers will load the page at this speed:
Chrome - 6.78s (+ 7%), FF - 19.65s (+ 3%), IE - 4.9s (-77%);

In most cases, the recommendation to glue the files justifies itself, but on large and extra-large plug-in files, the query parallelization mechanism gives the best results in download speed. The picture is different for IE users. Due to the nature of the mechanism for sending requests in parallel, gluing files gives a noticeable increase in download speed.