Does separating CSS code into multiple declarations cause more overhead for users?
I have seen some .css files organized like so:
/* Font Styles */
#text{ font-size: 12px; color: white;}
.highlight{ color: red}
/* END */
/* Div Positioning */
#text{ position: absolute;}
/* END */
Could this cause any potential inefficiencies? I understand that something on this scale will have no noticeable effects, but what about on massive style sheets?
Common sense says that the more rules you have, the more overhead there will be. However, CSS parsing is usually quite fast, so I wouldn't worry about it unless your stylesheets are truly ginormous.
It can, but only if you have thousands of selectors. Read this article for more info:
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
I think theoretically the answer has to be yes.
The browser must parse the new rule, it must look up the #text element again in the DOM and it must perform any new layout/rendering calculations.
Though as you point out, wait until this is a problem before you start optimizing.
Related
I use the 2 ways but I prefer the first due to reuse code. some prefer one or other. But I would like to know if the load in big stylized pages is better in one way than the other.
1)
<style>
.red{ color:red}
.right25{ margin-right: 25px}
.bold{ font-weight:bold}
</style>
<p class="red right25 bold">this is a red text, bold and right margin 25px</p>
2)
<style>
.class1{ color:red; margin-right: 25px; font-weight:bold}
</style>
<p class="class1">this is a red text, bold and right margin 25px</p>
That depends on how much of the code that you can actually reuse, but the performance difference won't be that big.
The biggest difference between the approaches is what the classes mean. Generally you should have classes that represent what you are trying to show, not exactly what styles you use to show it. Names that represent the intent rather than the implementation fares better when you make changes.
For example if you have the class right25 and want to change the margins to 20 pixels instead, then you either will have a class name that doesn't represent what it actually does, or you have to change it to right20 everywhere that you use it.
Two is your answer. The browser reads each class from right to left. Reading one class is faster than reading two classes.
http://csswizardry.com/2011/09/writing-efficient-css-selectors/
http://css-tricks.com/efficiently-rendering-css/
Use the external stlye sheet. The browser can cache that.
http://www.w3schools.com/css/css_howto.asp
You're absolutely talking about the first method that could be slower than the second method?
To answer: There's no difference in speed of styling css.
To illustrate:
div{
color: blue;
padding: 10px;
}
div{
color: red;
font-size: 16px;
padding-left: 5px;
}
When css is applied over the rule, the following css will be applied by the browser:
div{
color: red;/*later one*/
font-size: 16px;
padding: 10px 10px 10px 5px;/*padding-left 5px is taken from later rule*/
}
And which is parsed by the browser at the same time when the div gets styled from the stylesheet.
Why there's no difference?
In any other programming language like JavaScript if one line gets error then another line doesn't run and so from that line of code the interpreter won't go to read the whole code.
But in css language there's no problem even if you write rules whether html has no such classes or id, there's no problem reading next line of code even if you have some mistakes in your stylesheet, whatsoever the browser will load entire stylesheet file and read the code and gives the output in same time (when stylesheet is fully loaded) and both of your code doesn't seem to be any difference in the speed.
By the way, it could be slower (that even you can't catch with your eyes) where there is slower internet connection below 32kbps because of stylesheet downloaded the line by line of code.
First of all I want to tell you why I'm asking this question. I usually update projects that have been written poorly and without a reset. I want to improve the project's quality so it seems that applying a CSS reset is absolutely necessary.
I don't want to do a hard work of pixel perfect testing in every browser every time I change something and I don't want to completely rewrite all CSS.
So:
When I'm writing:
*{
margin:0;
padding:0;
border:0;
}
I know what trouble to expect: <p> will loose padding and <input>, <select>, etc. will loose padding and border. So I have to specify them manually.
This code is more difficult to understand:
*{
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
And I'm completely confused with this:
body {
line-height: 1;
}
*{
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
This sets all elements in the document to inherit font and font-size from parent elements by default unless specified otherwise, which can prevent user-agent stylesheets from applying font styles with less specific rules.
vertical-align: baseline; is another widespread rule to avoid user-agent rules which don't always apply this (I believe) expected default behaviour to all elements.
Here's a brief look at what this does: demo. In the demo, try setting a rule to middle rather than text-top.
body {
line-height: 1;
}
This is the same. If you're not familiar with line-height, it's quite simple. You may have dealt with it without realizing it: Sometimes it appears to be a margin issue when in fact, the line height of an element is exceeding what you expected. This often happens when you place a typeface into a design which has a very dissimilar x-height to other typefaces.
If you don't understand its function, throw some dummy text into a document and start playing with it. It's very useful (essential) for producing good typography in different situations.
It seems you're not clear on css attributes and how they effect elements. The better your understand this, the better you can utilize a reset. No reset really fits all for a few reasons. For example, you might not be using any elements where vertical-align may end up being mismatched. You may have rules in a large reset that apply to elements you don't even have.
As with anything in web design, if you don't understand it, hands on experience will teach you a lot.
Check out this fiddle with simple input control on a form:
http://jsfiddle.net/KXYHw/
Toggle reset and see how input font and font size changes.
I hope this question isn't too weird and arbitrary. When I'm viewing some CSS using Firebug, I've noticed that the CSS properties for each tag are in alphabetical order.
Is it trying to tell us something?
Apart from the obvious benefit of being able to find the property you're after more quickly, I was wondering this: Is it quicker for a browser to apply the properties if they are in alphabetical order in the original stylesheet?
For example is this...
body {
background: #222;
color: #DDD;
font-size: 0.85em;
}
#content {
background: #444;
padding: 1em;
}
p {
border-bottom: 0.9em;
line-height: 1.2em;
text-align: justify;
}
...better than this...?
body {
font-size: 0.85em;
background: #222;
color: #DDD;
}
#content {
padding: 1em;
background: #444;
}
p {
text-align: justify;
line-height: 1.2em;
border-bottom: 0.9em;
}
Can this be tested effectively?
This would obviously be replicated throughout the entire stylesheet so would a browser benefit from doing things in order and, if so, would it be worth revisiting past stylesheets to reorder things?
-- edit --
Ok, a slight alteration to my question: What if the attributes are always in the same order for each tag. Background always before border always before color etc and so on (I know I've missed some!) for each and every tag. Alphabetical would aid you in keeping things in order rather than being the optimal method.
Looks like the overwhelming consensus is that it matters not, however!
There's definitely no speed benefit in ordering your styles alphabetically.
If you want real speed benefits, you should minify your CSS.
There are so many programs to do that, but here's one of them: CSSTidy. This program also has the option to put your styles in alphabetical order (if you want that for your benefit).
I don't think order of statements affects speed in any way, however, the efficiency of the statements can affect performance. (Slightly tangential, I guess...)
See: http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
The performance benefit is for visual parsing only - FireBug will re-arrange your style attributes into alphabetical order when you inspect an element, which I find much quicker to locate a style attribute.
Firebug do it so that developers can search for an attribute value easily, and if you want speed benefit, write your css judiciously, which includes mainly avoiding repetition and redundancy and being DRY
Also when a page loads and CSS is parsed and layout is rendered once, next time its not done again, so stay calm, and try to make it more maintainable instead
Writing CSS in an alphabetical order just makes one thing easy: finding your attribute. It has nothing to do with speed.
To Increase speed, you can use shorthands rather than using separate attributes. Things like border-color, border-width, border-style can be used in a single attribute called border.
With the recent launch of http://csslint.net, I'm questioning some ways I've constructed my stylesheets in the past. The following method is one that I've used recently:
/* Fonts */
h1 { font-size:20px }
p { font-size:12px }
/* Colors */
h1 { color:green }
p { color:grey;
background-color:white }
/* Margins */
h1 { margin:0 }
p { margin:0 0 5px }
The problem, according to the linter, is that I'm re-declaring heading selectors over and over again. The reason of course is to keep logical separation between types of rules. If I wish to change colors, I would visit the colors region. If I wish to change dimensions, I would visit the dimensional areas.
Is CSSLint worried that I may be in danger of overwriting styles, thus wasting chars, or are there performance issue related to how many blocks contribute to the overall presentation of heading elements?
Is this a bad practice, or merely a false-alarm?
Styles get computed for all h1s and all ps either way. The overhead of selector matching is little compared to the equally-negligible performance "impact" of actually computing and rendering the styles.
I'm guessing what you think CSS Lint is worried about is the case. In fact, I kinda like how you organize your styles myself, and don't see any other problems than overwriting declarations by accident.
From their documentation -
Heading elements should have a consistent appearance across a site.
I think it is more to do with usability/consistency rather than performance. A heading of size 20px on one page and 14px on another just looks unprofessional.
Usually when I build a site, I put all the CSS into one file, and all the properties that relate to a set of elements are defined at once. Like this:
#myElement {
color: #fff;
background-color: #000;
padding: 10px;
border: 1px solid #ccc;
font-size: 14pt;
}
.myClass {
font-size: 12pt;
padding: 5px;
color: #ee3;
}
I've been considering splitting up my definitions into a number of different files (colours.css, layout.css, fonts.css ...) as I have seen recommended. Something like this:
/* colours.css */
#myElement {
color: #fff;
background-color: #000;
border-color: #ccc;
}
.myClass {
color: #ee3;
}
/* layout.css */
#myElement {
padding: 10px;
border: 1px solid;
}
.myClass {
padding: 5px;
}
/* fonts.css */
#myElement {
font-size: 14pt;
}
.myClass {
font-size: 12pt;
}
To reduce HTTP requests, I'd be combining the files and stripping whitespace prior to rollout, so that's not an issue, but my question is: does having all those selectors repeated over and over cause any performance issues in browsers?
Alternatively, are there any tools which avoid this (potential) issue by merging definitions from different files? ie: take the input given in my second example (3 different files), and combine them into one file, like the first example.
The browser will have to find all the definitions and then add them up and override the different properties based on the latest definition. So there will be a slight overhead.
That being said it would be rather minimal and not very noticeable even on hardware 5 years old. The browsers are quite efficient at it these days.
I can't comment on performance, but I tried this approach on my website and ended up reverting to one large file.
My reasons:
I got tired of creating a rule for div.foo in three or four different files, and opening three or four files if I wanted to change that div.
Sometimes it's not as easy as it should be to separate functions. To center a div in IE, you may have to center the text of the parent element, even though that's not the standard way. Now my layout is mixed in with my fonts.
As the code grows, the easiest way for me to find things is to do a text search for the element I want. But I have to open several files to see all the rules, and maybe that element doesn't have a rule in this file so I get no matches.
So I went back to having main.css and iehacks.css. And breathed a sigh of relief.
As William said, you're not going to see any issue from the browsers parsing the CSS. What you might see, though, is an issue with the number of HTTP requests that a client can open to a single host. Typically this defaults to two. So, if you do put your CSS in multiple files, you might want to put them on a separate sub-domain and they will be treated as a different host which will allow the HTML page to be loaded at the same time as your CSS files.
There shouldn't be any noticeable difference in rendering/parsing speed. As everyone else said, computers are fast enough that they can render CSS pretty quick.
Your problem is really going to be with the number of requests required to load the page. Extra web requests increase overhead when loading a page. It is much faster to load one large file than it is to load several smaller files. It has an impact on both the client (browser) and the server serving up all of those CSS files.
As long as you combine your files in production, you should be fine.
Yahoo's YUI Compressor is a pretty good tool for compressing your CSS files into smaller files. The last time I checked, it can't definitions (at least the last time I looked at it) but there shouldn't be enough of a performance hit to really need to.