How would I go about testing the performance benchmarks of different css selectors? I've read articles like this. But I don't know if it is applicable to my website because he used a test page with 20000 classes and 60000 DOM elements.
Should I even care,does performance really get downgraded that much based upon the css strategy you take?
Fo example, I like doing this ...
.navbar { background:gray; }
.navbar > li { display:inline;background:#ffffff; }
<ul class="navbar">
<li>Menu 1</li>
<li>Menu 2</li>
<li>Menu 3</li>
</ul>
... but I could do this ...
.navbar { background:gray; }
.navbar-item { display:inline;background:#ffffff; }
<ul class="navbar">
<li class="navbar-item">Menu 1</li>
<li class="navbar-item">Menu 2</li>
<li class="navbar-item">Menu 3</li>
</ul>
Some would say (and might be right) that the second option would be faster.
But if you multiply the second method across all pages I see the following disadvantages:
The page size will increase because all the elements having classes
Number of css classes can get quite large which would require more css class parsing
My pages seem to be ~ 8KB with ~1000 DOM elements.
So my real question is how do I create a test bed where I could test performance deltas based on strategy taken for realistic web page sizes? Specifically how do i know how long it takes for a page to be displayed? javascript? how exactly?
Help and just plain opinions are welcome!
Check out the Page Speed extension for Firefox. Once you run it for a page, under "Use efficient CSS selectors" it gives you a list of the offending CSS selectors along with brief explanations.
Also, there's another extension for Chrome - Speed Tracer. Amongst other things, it offers insight into time spent on CSS style recalculation and selector matching. This may just be what you are looking for.
From reading the article you listed it looks like the difference between the two type of selectors is not worth worrying about. Make certain the css is clear enough to understand it, and only worry about speed after that proves to be the bottleneck.
there really is no need to do
Menu 1
you can have a css class
navbar li
remember too that external css files can be minified and cached whereas the html cannot. Performance is also a relative term: do they visit frequently? Is the network slow? are they state employees with ancient computers running IE6?
I don't have a direct answer to your question of how to build a page speed testing program. However, I will offer you some best practice guidelines to follow that will steer you in the right direction.
The page size will increase because
all the elements having classes
The size of adding numerous classes is very much negligible for two reasons:
1) The additional size in your stylesheet will be cached (assuming you use externals, which you should).
2) The HTML markup from adding numerous classes to the DOM is 1kb at most. If it's more, than you need to take better advantage of inheritance.
Number of css classes can get quite
large which would require more css
class parsing
You will have more CSS classes, yes... but binding rules to a CSS class is actually faster than the alternative of using descendant or adjacent selectors.
As long as you avoid descendant/adjacent selectors as much as reasonably possible, you use external stylesheets, and you take advantage of inheritance to reduce duplicate rules, you shouldn't need to worry about CSS performance stress tests.
Related
I have been told, as well as read that using the style attribute in html is considered bad/sloppy/poor form. Further, that all rendering specific bits should be divorced into css and other parts as appropriate. I am trying to understand why exactly this is.
I can see why you might want to keep the HTML a pure semantic DOM, that speaks about the structure of the document, but for practical pages, the importance is that the page looks right and functions appropriately.
Is there some more compelling reasons for this separation?
Separation of concerns This makes it easy to replace the styles without changing the markup, or vice versa. Plus you can have one person working on CSS and another working on content
Don't Repeat Yourself You can apply a style to many elements without having to repeat it over and over. Smaller pages means quicker load times using less bandwidth. Plus it's easier to modify later, because you can change it in one place in one file, instead of many places in many files.
Cachability If the same style sheet is used on every page of your site, browsers can download it once and then cache it, instead of downloading the styles with the content of every single page. And they won't have to re-download it whenever the content of those pages changes.
Multiple Versions It is easy to create multiple versions of the visual layout and appearance of your site since you just need to swap out the stylesheet file to change the appearance of every page. For instance, you can create a white-label version of a web application which your partners can re-skin to match their brand. See CSS Zen Garden for some great examples of how flexible this approach can be.
Start with this code:
<ul>
<li style="color: blue;">One</li>
<li style="color: blue;">Two</li>
<li style="color: blue;">Three</li>
<li style="color: blue;">Four</li>
</ul>
Let's say that today, you decide to change the link color to red. Since these styles are inline, you tediously have to walk through each element and change the style attribute. Imagine doing this for 10, maybe 20 HTML pages and you'll see why this becomes a problem.
Using a stylesheet separates the content:
<ul>
<li>One</li>
<li>Two</li>
<li>Three</li>
<li>Four</li>
</ul>
From the style:
ul li {
color: blue;
}
Had you used a stylesheet from the beginning, changing the color is as simple as changing blue to red in your stylesheet.
Aside from making the document easier to style, there's also selector specificity. Imagine that you inherited the first code chunk from a previous developer and would like to change the color again, but you (being a nice developer) prefer stylesheets:
ul li {
color: red;
}
You'll soon become frustrated and resort to using !important, as your selectors can't override the inline styles.
CSS should be another file included in HTML because, if you want to change one style of an element that is included in more than one pages you will just change one style from CSS and the changes will be applied to all of the files. If you have the style in HTML, you would need to go on the pages one by one and change the styling. Its a good template building practice.
By separating markup and css. You can use css to change the look of everything, without affecting the markup.
Benefits include:
Creating different designs for the same html.
Dividing work within a team. One front-end developer can focus entirely on the css.
Back-end developers, do not have to hassle with the css.
Easier to change the look in the future.
Easier to migrate the html-markup to a new platform or content management system in the future.
I'm never sure what the best (most efficient) way to select an element is.
Lets say I have the following layout (extremely simple example)
<div id="navigation">
<ul>
<li>Link 1</li>
<li>Link 2</li>
<li>Link 3</li>
</ul>
</div>
I want to select my unordered list (ensuring I don't affect any other UL's throughout my site), should I do #navigation ul {} or assign a class to the UL?
I want to select my list items, again ensuring I only affect those. Should I do navigation ul li{} or assign a class?
And finally, If I want to select my first link and style it, should I do #navigation ul li:first-child {} or assign a class?
I appreciate these questions are pretty much the same, but I'm curious when you should use a class and when not to.
There's no hard and fast answer here.
A general rule of thumb might be to use classes when you want to group certain elements together, treat them the same and using a class is the only means of doing it.
In your last example for instance, there is strictly no need for a class.
But, using a class in example 3 will result in better performance, as the browser will located the relevant items quicker. Traded off against this is a slight reduction in code-legibility..
If you have class names on everything then it becomes harder to read the rest of the markup.
In short, in what you have shown above, what you have written is fine imo.
You should read this article though which covers selector efficiency.
Basically the order of efficiency is as follows:
ID, e.g. #header
Class, e.g. .promo
Type, e.g. div
Adjacent sibling, e.g. h2 + p
Child, e.g. li > ul
Descendant, e.g. ul a
Universal, i.e. *
Attribute, e.g. [type="text"]
Pseudo-classes/-elements, e.g. a:hover
The performance difference between classes and Id's is normally irrelevant.
Going further down the list though, things slow down considerably.
This isn't an argument to add classes and id's everywhere - it just allows you to judge the trade-off between performance and maintainability.
#id should be unique and class shouldn't.
so if you need to add some JS - you need #id, if you just want to style different elements, .class is fine.
I would think it really depends on how complex the structure underneath the #navigation element will end up being. Referencing everything using the #navigation element is probably OK if it is a simple structure like you have shown, but to me if it is more complex or will have different ul, li elements that will need different behaviors then I would id/class the nested elements.
For Javascript usage, I think to is more faster than use native selector, and no class or id.
For more details, I think just testing this theory with complex code ( for see the different time ).
Don't forget the javaScript's faster depends to your browser.
For CSS, a good article is here for more details.
I think very often tabs are implemented as <ul> and a series of <li> inside. Is there advantage of that over
just using <div> with a few <div>s inside?
Usually with <ul> as tabs, the padding-left of it needs to be reset to 0, and list-style needs to be set to none, while <div> doesn't have this issue.
Short and clear answer: Why should I use 'li' instead of 'div'?
Excerpt:
"For semantic correctness. HTML has the ability to express lists of things, and it helps the Google robot, screen readers, and all manner of users who don't care solely about the presentation of the site understand your content better."
"For the visually impaired, it can be helpful to distinguish what's in a list and what's not. Say if you have a list of ingredients in a recipe for example, and the user wants to skip to the instructions or just read the list, you need a list."
Don't forget to visit the link to learn more.
Looks better when CSS isn’t applied, and is (I believe) easier to interact with in screen-readers.
In terms of adding/changing the code, it is more readable and makes more sense. Tabs/navigation naturally seem like a list where the items are associated with each other.
Once implemented via CSS, it is extremely easy to add/modify when the time comes to change your navigation/tabs.
Which renders faster?
// Just HTML
<div id="holder">
<div style="float:left;">test1</div>
<div style="float:left;">test2</div>
<div style="float:left;">test3</div>
</div>
OR
// CSS
#holder div{
float:left;
}
// HTML
<div id="holder">
<div>test1</div>
<div>test2</div>
<div>test3</div>
</div>
In terms of actually displaying content, the speed differences between the two sections of code is negligible. Different browsers most likely have different implementations for rendering a webpage so the minute speed boost you get with one browser won't necessarily be reflected in another.
Now in terms of load times, it's a different story. Yes, inline styles are technically faster than an external stylesheet because you are making one less request on top of the page but using an external stylesheet is much preferred for code maintainability. It's only when you're loading multiple stylesheets that performance starts to become an issue since each time you refer to an new stylesheet the browser must submit another request. The solution? Simply concatenate stylesheets together into one.
I would imagine (due to the HTTP-Request involved) that external CSS would be slower but inline styles are horrific for maintainability and negates the whole point of CSS which is to centralise values for colour and layout so you don't have to iterate through every element to change a style.
Also see this
Even if you assume that you don't want to use an external stylesheet, using a style tag in the <head> with classes on the elements will make an automatic inclusion easy later with a server-side programming language, rather than having dozens of inline styles. Unless you have a trivial numbers of styles, your total bytecount will be lower as well.
Check out Google's new 404 page: they even have the images in the style tag:
http://www.google.com/123412312
In terms of browsing there shouldn’t be any difference you can test this with browsers' developer tools. Apart from code maintainability already mentioned in other answers, there is also the issue of specificity of inline rules. Since they have the highest specificity (1,0,0,0) they would override all other cascades. So you should carefully examine your use case rather than making the decision based on performance criteria
Do you guys ever use inline styles for one-offs?
For example, I wanted to make just one particular list on my site use letters:
<ol style="list-style-type:lower-alpha">
Is that really so bad? Or would you slap on an ID and then bury it in your big master CSS file where it will be a pain to ever find again?
The presentation of your problem reveals a further issue that is affecting your decision: either inline the style or hide it in a large CSS file.
You know that placing the relevant styling rules in a CSS file is the better choice. You want to place the relevant styling rules in a CSS file but are daunted by the task of managing the CSS file.
Defining the styling rules inline is less painful than maintaining a large CSS file. The problems you are facing with a large CSS file are only going to get worse the more the project grows.
You need to break the large CSS file into a set of more managable CSS files.
A set of CSS files can be much easier to manage if they are sensibly named and contain appropriately-grouped rules. You may opt for one CSS file for layout, one for typography, one for colours and perhaps one per page for each page that is significantly different.
A set of CSS file is easier for you, a single CSS file is better from an end-user performance perspective.
Resolving these two conflicting needs is straightforward: develop with a set of CSS files and have your build process combine these into a single (minimised!) CSS file.
No,what you did is right.Inline styles are meant to use for only once.Of course i find many times this is over(ab)used.
No... don't ever do this. Wherever you think there is a one-off, just around the corner lurks a two-off. Then a three. Then a four.
Take the extra 60 seconds to do it right--you, and whomever follows you with maintenance, will be glad you did.
I would still put it in the file as a class, if that is what you are doing everywhere else. Imagine if someone else tried to find that style in the master CSS file and spent hours looking for something that was not there.
Additionally, what happens if you decide you like this style and want to use it elsewhere? You would have to put in the master CSS file anyway.
For me the #1 reason to always avoid inline styling is predictability in large projects involving several designers/developers.
Say you've added your one-off inline style to that ordered list, then another participant want to add some general styling to all ordered lists through your mammoth style sheet. Since your site/project is so large, he is likely to never notice your one-off hack, and therefore will believe that the new styling also applies to your ordered list, not realizing you've overridden the styling with your inline styles.
But if you're the only person maintaining this project... go ahead!
I would put it in a class, but define the class in inline CSS in the page. Then, if you need to expand to using it elsewhere, you can just move the class into a shared CSS file.
Also, I agree with the other answer noting that Firebug or similar can track down where any particular piece of styling comes from, so making "where's that coming from?" obvious is no longer a highly-weighted concern in my book. It's good to do when it's trivial, but not worth trading off on other measures for.
I vote for inlining. If this style is truly special to this one particular instance, that's a perfectly fine place to define it, and it saves you from a bloated and hard to maintain CSS file, especially if you have a large site and you're using a single CSS file for your entire site.
The argument that "CSS is where I look for styles" simply means you're being lazy.
The argument that someone would take hours to find this if it was inline rather than in the CSS means they are not a very good web developer.
The argument that someone else is going to want to globally change the style for say "<li>" later and will miss this instance is actually a good reason TO inline it. If you know you want this to be a unique style, than make it so, either via specificity in your CSS or inline, but I vote the latter.
I do this, but strictly only with the following rules:
1) An inline style rule must have exactly one property
<!--// Acceptable --//-->
<ol style="list-style-type:lower-alpha">
<!--// No!!! --//-->
<ol style="list-style-type:lower-alpha; font-weight: bold; ">
2) Any element with an inline style rule may not contain any descendant elements that have an inline style rule.
<!--// Acceptable --//-->
<ol style="list-style-type:lower-alpha">
<li>Item One</li>
<li>Item Two</li>
</ol>
<!--// No!!! --//-->
<ol style="list-style-type:lower-alpha;">
<li>Item One</li>
<li style="font-size: small;">Item Two</li>
</ol>
<!--// Instead (example) --//-->
<ol class="product-details">
<li class="shortdesc">blah blah</li>
<li class="longdesc">Blah Blah Blah</li>
</ol>
I wouldn't slap an id on it, I'd slap a class on it and quickly find it later using my editor's search feature.
I would class it. If the site will one day be inherited by anyone else, do them a favor and stay consistent. Besides, it will be easier to change if some day you decide lower-alpha no longer works for you.
You should still put it in the CSS file. I have a mental model that says styling = CSS. If it's not in the CSS, I would frankly get confused down the line.
Also, what if you find yourself wanting to use the style again. I mean you say it's for ONE item now, but who knows.
It's just good practice to use css/classes, and it'll usually pay off.