CSS media queries: one file vs. separate files and impact on loading speed

2.3k views Asked by At

For a site I currently use style.css and a bunch of other stylesheets, 960.css, etc., loaded like this:

<link rel=​"stylesheet" media=​"screen" href=​"css/​style.css">
<link rel=​"stylesheet" media=​"only screen and (max-width:​ 960px)​" href=​"​css/​960.css"​>
....

Now I am concerned about speed. I know I could combine the files into one big file, but that would mean downloading also irrelevant data.

So basically, my question is: What is a better approach, minimizing the amount of requests, or minimizing the amount of data passed to one user?

3

There are 3 answers

0
Alex Tape On BEST ANSWER

It is basically about the performance of your system.

even if you are on mobile devices the best approach would be to minimize the amount of requests because of a (maybe) slow network connection and a (maybe) slow resource handling. besides your page is on e.g. a cordova context this approach would be the way to go because the resource were installed directly on the device. multiple files => multiple handles => slow (er) performance.

if you want to minimize the amount of data passed to the user - the amount is IMHO the same because the tag will query the css file on the server and will parse/read/download it. IMHO there is no relevant performance issue. what you can do is to generate and "non-redundant" css file. but thats not really petty :)

0
Kkart On

So basically, my question is: What is a better approach, minimizing the amount of requests, or minimizing the amount of data passed to one user?

I would say both. Note that the requests will be cached by the browser so for returning visitors your concerns are irrelevant. In general less data = quicker download times. The best approach would be to serve minimal amount of data needed for a user.

1
pwdst On

On a reasonable speed link the latency and overhead involved in the extra request will probably outweigh the gains by not downloading a small amount of (hopefully minified and gzipped) text data that is none-the-less not required for that user to display the page at that resolution. See Ilya Grigorik's excellent post on latency for more details on how this is proving to be the primary performance constraint for many users.

The latency cost of the extra data will be especially true for users on mobile devices (which will power save their radios when not in use), and even more so on mobile 2G or 3G connections which have a relatively high cost in establishing connections (4G apparently substantially improves on this).

The key, as with all these things, is to test and measure - but I would almost certainly expect that bundling the styles would prove faster for your users. Don't forget each valid stylesheet (where the media query evaluates to true) will block the rendering of the page.

It is also worth noting that Ilya (who works for Google so should know) cites that WebKit will still download stylesheets media queries that return false, albeit with a low priority and in a non-blocking manner.

if the media query evaluates to false then the stylesheet is marked as NonBlocking and is given a very low download priority

and

The only caveat, as Scott indicates, is that the browser will download all enabled stylesheets, even though the screen on your device may not ever exceed the [cited] width

Looking briefly at the webkit source it does seem like this still happens, presumably to allow instant response to screen rotation or window resizing.

 // Load stylesheets that are not needed for the rendering immediately with low priority. 

223 ResourceLoadPriority priority = isActive ? ResourceLoadPriorityUnresolved : ResourceLoadPriorityVeryLow; 

224 CachedResourceRequest request(ResourceRequest(document().completeURL(url)), charset, priority); 

225 request.setInitiator(this); 

226 m_cachedSheet = document().cachedResourceLoader()->requestCSSStyleSheet(request); 

For questions like this I can highly recommend High Performance Browser Networking which you can read online for free.