I was optimizing the page load time of a website. One of the ways was by combining multiple HTTP requests for CSS into one combined HTTP request. But one of the reviewers asked an interesting question: wouldn't paralellizing the download of multiple CSS files reduce the page load times?
I never considered this option, as the only thing I read on the internet is that reducing the number of (blocking) HTTP requests is key to a faster web page (although Google Pagespeed Insights doesn't seem to clearly state this 1).
I see a few reasons why parallellization would not improve performance, or only matter very little (outweighed by the benefit of using fewer HTTP requests):
- Setting up a HTTPS connection takes some extra data. I've read this can easily be a few KBs of data. This is some extra data that has to be sent over the wire, instead of the CSS we actually want to send.
- Due to the TCP Slow Start algorithm, the more data that has been sent over a connection, the faster the connection will be. So longer lived connections would actually send the data much faster than new connections. See for example the SPDY protocol, that uses a single connection to improve page load times.
- TCP is an abstraction: there is still (normally) only one underlying connection. So while multiple requests are used, the data send over the wire may not necessarily benefit from multiple connections at all to improve speed.
- Internet connections are inherently unreliable, especially on mobile. One request may be finished significantly faster than the other. Using multiple requests for CSS means rendering the web page is blocked until the last request has finished, which may be significantly later than the average connection.
So, is there any benefit at all in parallelizing HTTP requests for CSS files?
Note/update: all CSS files are render-blocking. CSS files that are not have already been moved outside the critical path.