Do media queries cause a rendering performance hit? - css

While refactoring my main css into a modular approach I'm using #media all {} to wrap css modules in the IDE. This approach makes it much more easy to scan the files' content as we can't use a preprocessor like less or sass right now.
My only concern is that all those media queries (one for each css module / set of coherent selectors) might cause a performance hit while rendering the site. I am NOT concerned about the file size of our css files as this is a minor issue with a slim modular css framework and proper zipping.
Do media queries like #media all {} have an impact on the performance (both on desktop and mobile/other) devices if used to frequently?

The answer is no... and yes. Having a bunch of media queries will not make the site harder to render. But more lines of code makes a file larger and that technically takes longer to load. Still this isn't much of a performance hit.
But when resizing the browser, it will be taxing on the browser to recalculate a bunch of different mq settings. Read more here: Web Performance: One or thousands of Media Queries?
But...if you want to be proactive about this, with out a preprocessor, just use Pleeease. Pleeease gives you preprocessor like ability with vanilla css. AND it provides a PostProcessor function called mqpacker. It will find all similar media queries in your style sheet and merge them into related media queries. But again, if you are gzipping your stylesheet on the server, you don't need to worry about it.
Good luck! Stay awesome!

Related

Media queries as replacement for code regions?

I thought it would be a neat idea to put my default css which has no width/height/.. dependencies in a media query like this:
#media only all and (min-width: 0px){ ... }
Are there any possible drawbacks I've missed?
It's not as readable to be honest with you. If I were to see that in a CSS file, I would assume it's some weird CSS hack.
The other downside is you're adding an unnecessary media query. Setting all your default attributes through a media query is making more work for the CSS compiler.
Finally is support. Not all browsers support media queries, especially if you work in enterprise or with clients who have very old browsers. If you have all your defaults set through media queries you don't have an easy fallback if those queries fail.
It's not a good idea to use anything that isn't really adding to your webpages.
The unnecessary use of media queries can also cause problems with old browsers (eg. IE 7,8,9) if there is no polyfilling. It will also add to the page load time.
There are other numerous ways to increase readablity:
1.opening and closing comment lines to a set of CSS blocks
/******default code******/
html{
.....
}
body{
.....
}
/****--default code--****/
separate CSS files
code collapsing in IDE
other tips are mentioned here at Improving Code Readability With CSS Styleguides

Column's wise grid designs for device portabilty how it works

Am gonna try a template which needs to support all devices most of them recommended me to grid framework because using media query by self may cause time but using framework makes fast.Now the thing is i don't about grid and my task is to finish it with foundation framework.! and which is the best way
*)writing media query by own (or)
*)using framework like foundation
and tell me the way and how to use it thanks a lot in advance..!
There are two opposite ways to accomplish your task.
Using a non-semantic CSS grid framework
There are a number of CSS grid frameworks. The most popular of them probably are:
Twitter Bootstrap;
Zurb Foundation;
Blueprint.
The advantage of using any of those is that you can prototype your grid very quickly by applying the non-semantic classes to your HTML elements. They also contain a lot of handy decorative styles.
But this approach is considered faulty by many CSS developers. There are a number of problems:
By using non-semantic classes you mix structure and presentation, which is fine to make the job done quickly but unacceptable for a serious project.
You force your users to download a huge CSS library while you barely use 10% of it on your website (i have to admit that Foundation allows to import different portions of its CSS library separately, and there exits pure grid frameworks like 960gs that don't contain decoration styles at all).
You are limited with the sizes and breakpoints provided by the grid system. There's no elegant way to override them. Most of grid systems provide only two responsive styles: small and large, while you may want more (e. g. phone portrait, phone landscape, tablet portrait, tablet landscape, laptop, desktop).
Using the power of SASS and Compass
SASS turns CSS into kinda programming language. You can use variables, functions, methods, you can include libraries of code and execute them with your parameters. The possibilities are almost endlest. You write your styles in SASS and then complile them into vanilla CSS accepted by all browsers.
Compass is a bunch of things under one name:
a handy tool to compile SASS efficiently;
a huge library of handy SASS styles for all occasions;
an ecosystem of extensions that you can install and use in your projects effortlessly.
There exist a number of SASS grid frameworks. They allow you to span your elements semantically. Instead of adding classess to HTML, e. g.:
<aside id="sidebar-left" class="grid-2-of-6 grid-4-of-12">
...you apply CSS to existing selectors, e. g.:
#sidebar-left { #include float-span(2); }
Another advantage is that you're not limited with the defaults. You can alter the number of columns, their width, the breakpoints. You can even have different grids for different portions of the web page! And the most tasty feature is that you can have different number of columns for different screen widths (instead of just making your columns ridiculously narrow).
In my opinion, the best SASS grid system out there is Singularity responsive grid framework. It is extremely powerful and flexible and at the same time it's very smooth and simple to use (once you study it).
For responsive media queries you can use Breakpoint or it's jet-propelled sidekick Breakpoint Slicer. Building a responsive grid with Singularity and Breakpoint Slicer is a pleasure.
SASS and Compass provide other fantastic advantages. For example, you can structure your code very efficiently. It's not a proper place do describe all the ways with which SASS and Compass make your life better. I'll just say that CSS compared to SASS is like a copybook and abacus compared to a spreadsheet processor. I suggest that you google for SASS to learn more.
The downsides of the SASS approach are:
You'll have to study it. It takes time.
You'll have to keep your styles in SASS. If you want to edit your CSS, you'll have to edit SASS and recompile. That's not much of a hassle and there are ways to automate this or even integrate into the deployment process, but it takes time and effort to adopt them.
Your teammates are obliged to use SASS too because any changes in CSS are overwritten during each compilation.
Once you start using SASS, you'll never want to code vanilla CSS anymore. That's not a true disadvantage actually. But you should be aware that your life as a frontend developer will never be the same!

Can I make font loading in CSS Optional for mobile devices?

My current Website-Design is built with the Bootstrap responsive framework. It uses several custom fonts, which make up about 50% of the document size. The fonts are included via CSS, the way of inclusion can not be changed.
My goal now is to stop mobile devices from requesting these fonts, in order to reduce their bandwidth consumption.
Is there a CSS way, like #media (min-width: 480px), to not load the fonts in the responsive layout?
In most implementations, background images that are referenced in CSS media queries get pre-downloaded. (Unless you do some fiddling with your use of display:none;, but that won't be supported in all browsers.)
The same applies to any fonts you've included via media queries — even if they're specified for a larger/different viewport.*
Why?
This allows for a smoother transition if viewport size is changed, e.g. from portrait to landscape.
Solution?
Considering the constraints you mentioned, I don't see a clean way to do this only with CSS. You could do something with JS (but make sure it degrades gracefully), or PHP.
But the easiest ways to reduce HTTP requests and how much your visitors have to download include doing one or all of the following:
Using less fonts, or web-safe fonts instead.
Using a CDN for fonts.
Including 'minified' font files that only have the characters you'll
be using them for.
Check out Google Web Fonts for the latter two.
If you expect or get a lot of mobile traffic that's important for the site, it's always worth re-thinking a website's design and markup from a mobile-first approach: what's necessary and what isn't. (That approach can often help to even reduce clutter on the desktop version of your site.)
* The fiddling approach could be useful for fonts too, but you'd have to do browser testing yourself, as so far it's undocumented.
You could create two different stylesheets, one for mobile and one for desktop, then use PHP browser detection or various other methods to see if the user is on a mobile device or desktop device, and provide them with the corresponding stylesheet.
Take a look at the PHP get_browser function: http://php.net/manual/en/function.get-browser.php
All background images aren't necessarily pre-downloaded if referenced in your media queries -
http://timkadlec.com/2012/04/media-query-asset-downloading-results/
perhaps this technique would also work for fonts too. Not if you're using anything that'd need JS (like typekit, google) your font's will be requested because of the JS anyways afaik.

Media queries versus other methods / Universal Mobile support

I am building a mobile site and have looked into media queries but don't really like the lack of support. I'm really wondering what methods or approaches are commonly recommended.
On our site we are using head.js (http://headjs.com/) which adds classes into the tag about the client, notably: browser, width and supported features. What do people think about using this javascript method as a better supported way of handling different users and changing the design layout accordingly.
I do feel that perhaps this JS approach is used as our main method but that it might be worth using a number of others a fallbacks. Here is perhaps a chain of support.
1st: All universal styles plus layout for narrowest device window.
2nd: Use some method of CSS targetting to add a desktop style sheet if desktop viewing is assumed, possibly media=screen
After this we are handling the lowest and the highest denominator.
Finally: Use the styles (width etc) created by the javascript to fine tune the design for different layouts.
Thoughts?

Is it better to define css for all #media in one css file?

As this article suggesting
http://www.456bereastreet.com/archive/201002/css_efficiency_tip_use_a_single_stylesheet_file_for_multiple_media/
or different external CSS for different media would be better option?
in terms of maintainability, site performance.
Basically, if you can programmatically add CSS files to your client based on the media (as long as you only send ONE css file in the end), then yes, build multiple CSS files based on the #media.
If you cannot add css programmatically, then I would suggest combining them into a single css file (since you have to send them all to the client regardless), thus reducing the number of http requests by the client.
fewer http requests = faster page loads.
Combined Style Sheet Pros:
Optimal/Fast
Good reduction in size after compression
and yes fewer http requests
Combined Style Sheet Cons:
Messed up; all different style sheets in one place
Difficult to maintain
Less readable
You could use media-dependent #import rules like so:
#import url("print.css") print;
#import url("projection.css") projection, tv;
it should work in everything but IE5-7 (as per: http://www.westciv.com/wiki/CSS_Guide:_Media#mediaspecific )
I can't test for IE8 so you might be disappointed there too.
it would result in a very small initial CSS load, then upload just the needed stylesheets based on media.

Resources