Considerations for organizing and authoring media queries
We will take a brief tangent at this point to consider some of the different approaches that authors can take when writing and organizing their media queries. Each approach offers some benefits and some tradeoffs so it's worth at least knowing about these factors, even if you decide they are largely irrelevant for your needs.
Linking to different CSS files with media queries
From a browser perspective, CSS is considered to be a 'render blocking' asset. The browser needs to fetch and parse a linked CSS file before rendering of the page can complete.
However, modern browsers are smart enough to discern which style sheets (linked with media queries in the head) need to be analyzed immediately and which can be deferred until after the initial page rendering.
For these browsers, CSS files linked to with non-applicable media queries (for example if the screen is too small for the media query to apply) can be 'deferred' until after the initial page load, providing some performance advantage.
There's more on this topic over on Google's developer pages: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css
However, I would like to draw your attention to this part in particular:
"...note that "render blocking" only refers to whether the browser will have to hold the initial rendering of the page on that resource. In either case, the CSS asset is still downloaded by the browser, albeit with a lower priority for non-blocking resources."
To reiterate, all the linked files will still be downloaded, the browser just won't hold up rendering of the page if they don't immediately apply.
Therefore, a modern browser loading a responsive web page (take a look at example_02-03) with four different style sheets linked with different media queries (to apply different styles for different viewport ranges) will download all four CSS files but probably only parse the applicable one initially before rendering the page.
The practicalities of separating media queries
Although we have just learned that the process of splitting media queries potentially offers some benefit, there is not always a large tangible advantage (apart from personal preference and/or compartmentalization of code) in separating different media query styles into separate files.
After all, using separate files increases the number of HTTP requests needed to render a page, which in turn can make the pages slower in certain other situations. Nothing is ever easy on the Web! It's therefore really a question of evaluating the entire performance of your site and testing each scenario on different devices.
My default stance on this is that, unless the project has considerable time available for performance optimizations, this is one of the last places I would look to make performance gains. Only once I am certain that:
- All images are compressed
- All scripts are concatenated and minified
- All assets are being served gzipped
- All static content is being cached via CDNs
- All surplus CSS rules have been removed
Perhaps then I would start looking to split up media queries into separate files for performance gains.
Tip
gzip is a compression and decompression file format. Any good server should allow gzip for files such as CSS and this greatly decreases the size of the file as it travels from server to device (at which point it is decompressed to its native format). You can find a good summary of gzip on Wikipedia: http://en.wikipedia.org/wiki/Gzip
Nesting media queries 'inline'
In all but extreme circumstances, I recommend adding media queries within an existing style sheet alongside the 'normal' rules.
If you are happy to do the same, it leads to one further consideration: should media queries be declared underneath the associated selector? Or split off into a separate block of code at the end for all identical media queries? I'm glad you asked.