Suppose 1 css file, and 3 #media formats, say:
#media (min-width:1280px)
#media (min-width:640px) and (max-width:1279px)
#media (max-width:639px)
Is there a significant performance difference between using each #media format once and cramming all appropriate CSS rules inside, such as:
#media (min-width:1280px) {
/* all css for this format */
}
#media (min-width:640px) and (max-width:1279px) {
/* all css for this format */
}
#media (max-width:639px) {
/* all css for this format */
}
VS
Using as many #media declarations as necessary (about as many as you have CSS rules/sections)... such as:
div.some-class-name {
/* styles */
}
#media (min-width:1280px) {
div.some-class-name {
/* styles for this format */
}
}
#media (min-width:640px) and (max-width:1279px) {
div.some-class-name {
/* styles for this format */
}
}
#media (max-width:639px) {
div.some-class-name {
/* styles for this format */
}
}
I personally prefer version 2 (though maybe not so excessive), as it's much easier to track a specific pair of styles for each #media query.
thx for feedback!
I'm not an expert on this, but I found a decent article addressing this:
https://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
It doesn’t matter if you use one big or multiple media-queries in your code assuming your values are mostly the same. It shouldn’t matter if your values are different for each(!) of your hundreds of media-queries but could affect performance (found no way to track this down). The only thing I could add here is that using many inline media queries often is that they’re increasing the size of your CSS (unless your gzipping it) and that affects performance as it’s loaded blocking.
Makes sense to me. I personally like to group element styles rather than grouping media queries (version 2 in your question). In my mind, CSS's goal is to style your elements and styling them based on screen size is a secondary goal.
In practise no there shouldn't be a significant performance difference, there shouldn't be one at all. Browsers generally serialise and strip out duplicate media queries.
The only potential issue is if the extra MQs add bloat to your css file and thus it takes longer to download, delaying the render. It is pretty unlikely for this to happen.
You can read a little more about it here
The performance difference issues in your examples are extremely small. The only thing I can tell you about performance is this: If you use stylesheets, ALL stylesheets will be loaded by the browser. Only the one that matches the media query will be applied.
Basically, just use whichever method is easier to change, organize, etc. . . my guess is stylesheets.
About the NUMBER of queries, there will be no performance changes. Most browsers automatically calculate the width, height, screen, type etc., even without media queries.
Hope that helps!
Your version 1 is very similar to v2. The difference I see is you wrote "all CSS" versus "styles for this format". In the case of writing all of the CSS you will have a much larger file than V2. Loading a larger file takes extra time than a smaller file, so version 2 will be more efficient.
In any case, use these 2 rules for performance:
1) Shorten your CSS as much as possible. Avoid redundancy wherever you can. If in the top media query you use "h2 {padding: 0 }, then don't use that in the other queries as that would be completely unnecessary.
2) Look at the number of characters or file size of your CSS. The smaller file will always load faster.
Related
I trying to understand the logic behind media queries in sass.
For example, if I want to set media queries for my container in css in will be:
#media only screen and (max-width: 37em){
.container{
some code
}
}
But in sass it will be:
.container {
#media only screen and (max-width: $bp-medium){
some code
}
}
As you can see it the upset!
how the sass look after it compiled?
In sass you can e.g. set standard values - just like in your example $bp-medium. If you set this value to 37em, it will behave similar to your css example.
By the way, you can just as well use the css way for sass. Wouldn't recommend though, since this is what sass makes powerful.
By moving the media query inside a selector, you are organising all styles relevant to a component in the same place. When you choose to do it the CSS way, you'll organise the styles based on the media queries. This will give you a bad overview of what the component would look like in big projects and large files.
I have a very large and complicated stylesheet. Because of the way I've built the organization of the styles, it would make sense to me to put in some media queries for smaller resolutions throughout the stylesheet, rather than group them all into one at the end like I normally see.
For example, here's some pseudo-code for what I mean:
.navbar { width: 300; height: 20px; background: gray; }
.navbar ul { etc etc }
#media screen and (max-width: 800px) {
.navbar ul { something to make it smaller..... }
}
.....30 some-odd lines later....
#contentblock { some styles }
#media screen and (max-width: 800px) {
#contentblock a { something that makes this one smaller and stuff }
}
^^Hope that all makes sense.
My question is: although I am allowed to do this, does it dramatically impact the load/processing time? Is it a memory hog that should be avoided by grouping all the media queries at the bottom of the sheet, or for the sake of my own convenience, I can go ahead and do it with minimal negative impact?
Negligible.
Have you not seen the big sites and their 30k+ line stylesheets? Browsers can load it very fast, it shouldn't make a difference whether or not they are grouped together.
The real difference is on your end. Make it so that it's efficient for you to develop. Personally I think it looks better for them to be next to related styles rather than on the bottom. But be mindful that newer styles override older ones, that may be where the practice of grouping media queries on the bottom came from.
Unless you're sending your code back in time to the AOL dial-up days, this will not have any noticeable impact on performance/processing time.
That being said, don't forget your order of operations. You'll have to be careful not to overwrite your media queries. Keeping them all at the end of the stylesheet helps in preventing that and ensures that your media queries are at the end of the cascade.
I recently got started with LessCSS, and I've been having quite a bit of success in regards to how clean and readable my CSS has become. However, I don't think I'm using Less to its fullest advantage.
I'm now in the process of coding up my first fully-responsive site using Less, and I'm concerned with performance and speed. One thing to note is that I don't stick to a "breakpoint" methodology - I scale things up and down until they break, then I write CSS to fix them; which usually results in anywhere from 20 - 100 media queries.
I'd like to start using Less to nest the media queries inside my elements, such as the example below:
.class-one {
//styles here
#media (max-width: 768px) {
//styles for this width
}
}
.class-two {
//styles here
#media (max-width: 768px) {
//styles for this width
}
}
Through my initial testing, I have found that when reviewing the compiled CSS output - this methodology results in multiple (many!) instances of #media (max-width: ___px). I have scoured the internet, and haven't found anything that explicitly explains the performance implications of nesting/bubbling media queries.
Update 1: I realize that more CSS information results in a larger CSS file to download - but I'm not as worried about site load time as a sole metric. I'm more interested in the browser's handling of memory and performance after the DOM is ready.
Update 2 & Semi-Solution: I found this article which discusses the four main categories of CSS selectors and their efficiencies. I highly recommend the read which helped me sort out how best to tackle my over-media-query'd CSS.
So my question is this: after the DOM is ready, will having this many media queries in my compiled stylesheet affect load times & performance?
Its almost impossible to give you a totally accurate answer.
When asking about performance the typical answer is to profile it and see what you get. Fix the slowest part first, then repeat.
You can profile CSS selectors in the Chrome Developer tools:
Ultimately I don't think the media queries will have anywhere near as much impact on performance compared to even a slightly complicated selector.
You can see more information about writing efficient CSS here:
https://developers.google.com/speed/docs/best-practices/rendering
Also with regards to file size and repeated CSS, gzip almost completely nullifies this as the gzip algorithm works best with repeated data.
> also u can write like this :-
// breakpoints
#mobile: ~"(max-width: 767px)";
#tablet: ~"only screen and (min-width: 768px) and (max-width: 991px)";
#desktop: ~"only screen and (min-width: 992px) and (max-width: 1199px)";
#desktop-xl: ~"only screen and (min-width: 1200px) and (max-width: 1350px)";
body{
background:black;
#media #mobile {
background:red;
}
}
I am trying to hide a media query from being printed, so I came up with #media not print and (min-width:732px). But for whatever reason, this (and many variations I have tried) does not display as I would expect in browsers.
The only option I can think of is to use #media screen and (max-width:732px), but I would like to avoid this as it excludes all the other media types besides screen.
Media queries grammar is pretty limited to say the least.
But with CSS3 (not CSS2.1) it seems that you can nest #media rules.
#media not print {
#media (min-width:732px) {
...
}
}
This basically executes as (not print) and (min-width:732px).
See https://stackoverflow.com/a/11747166/3291457 for more info.
How about something like this?
body { min-width:732px; }
#media print {
body { min-width:initial; }
}
The min-width will be set to 732 for everything, except print, which will get some other value that you specify. Depending on your situation, you can set a different width, or try something like "thiswontwork" (which sometimes causes the value to be set to the initial value) or "inherit" or something like that.
If I'm correct in my assumptions about the behavior you expected, the issue is that the precedence of not is lower than and.
#media not print and (min-width:732px) means "any media except for printers with at least 732px-wide viewports" (so it will apply to any non-printer and skinny printers) not "any media except printers, as long as that media has at least a 732px-wide viewport" (which is what I assume you expected).
Since parentheses aren't valid around media types and #media rules cannot be nested, working around it is kind of annoying. For simple cases, brentonstrine's answer is a good solution, but for queries which enclose many styles it can be burdensome to make sure they're all overridden properly.
I put together some example media queries when I was trying to figure this out myself earlier today.
As you can't put something like this
#media screen,handheld,projection,tv,tty and (max-width:732px) { ... }
you should write pairs for each media like following:
#media screen and (max-width:732px), handheld and (max-width:732px), projection and (max-width:732px), tv and (max-width:732px), tty and (max-width:732px) { ... }
You could try something like:
#media screen,handheld,projection,tv,tty { ... }
The above nested query didn't work for me, but after a little reading on Media Queries Media Types at MDN, you can exclude you're media query from print styles by specifying the screen type
So if you have a media query like this which doesn't specify a type, it will have an implied type of all, (which will affect print styles)
#media (min-width:400px) {
...
}
To exclude the style from print styles, you'd need to change it to this:
#media screen and (min-width:700px) {
...
}
I am wondering if CSS can be 'heavy', e.g. use a lot of parsing time from a browser.
For example I use a CSS sheet with a lot of specific selectors, like
:last-child,
:nth-child(n)
table.sortable thead tr th:not(.table-th-nosort):hover
etc. Can that noticably influence performance?
Same for using media-queries. I want to make a site accessible for mobile devices using CSS3 media queries:
#media screen and (max-width: 600px) {
#sidebar {
display: none;
// etc
}
}
For now I have about 600 lines of CSS (not minified) in my main file, and for some specific pages include extra CSS files (between 10-300 lines).
Using media queries would add substantially to that I expect. Will that have an effect on performance?
The easiest way to check is to grab a webkit nightly, or Chrome Canary, then check out the new audit for CSS performance. It lets you see how long each selector takes to run, as well as the % of overall time taken. The new builds of Opera also have a similar tool.
Here's a small screenshot of what it looks like: