: Improve web site performance via parallel CSS downloads? 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
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 new connection is expensive. While setting up multiple connections can be done in parallel, browsers will use at most about 4-6 connections (depending on the browser), so downloading CSS in parallel would block downloading other assets like JavaScript and images.
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.
More posts by @Voss4911412
1 Comments
Sorted by latest first Latest Oldest Best
CSS files linked from HTML documents are added to the parallel download queue as the HTML is parsed; the key thing is that non-asynchronous JavaScript links block the HTML parser, preventing later tags from being added to the download queue until that JavaScript is downloaded, parsed and executed.[1]
Here's an example that forces the browser to download three of the four files sequentially (at least three round-trips):
<head>
<script src="js/fizz.js"></script>
<link rel="stylesheet" href="css/foo.css"/>
<script src="js/buzz.js"></script>
<link rel="stylesheet" href="css/bar.css"/>
</head>
Here's the example reworked so all 4 files are downloaded in parallel (at least one round-trip):
<head>
<link rel="stylesheet" href="css/foo.css"/>
<link rel="stylesheet" href="css/bar.css"/>
<script async src="js/fizz.js"></script>
<script src="js/buzz.js"></script>
</head>
Another note: CSS files are (by default) render-blocking, not parser-blocking; the page will continue to be parsed and the DOM constructed, but the render won't begin until the CSSOM is constructed.
The main reason to split your CSS up, is to get the minimum rules necessary to render the above-the-fold content to the client and parsed as soon as possible. The rest of the rules, for things that aren't immediately visible, can be marked as not-necessarily-render-blocking with media queries in the link tag, or added to the page by asynchronously loaded JavaScript.
So, there is no clear benefit to parallelizing your CSS downloads just for its own sake. But as always, measure and test!
For further reading, I recommend these articles on 'Web Fundamentals: Optimizing Performance' from Google: developers.google.com/web/fundamentals/performance/
[1]: This is ignoring the Speculative Parsing feature of some browsers:
docs.google.com/document/d/1JQZXrONw1RrjrdD_Z9jq1ZKsHguh8UVGHY_MZgE63II/preview?hl=en-GB&forcehl=1 developer.mozilla.org/en-US/docs/Web/HTML/Optimizing_your_pages_for_speculative_parsing
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.