What is best size of CSS file ?

hi i am making a site and using CSS file. having size of CSS 46 KB can anyone tell it will not effect on my site speed i dnt have images in CSS.

 

46 KB is pretty small. I don't think it would affect your site. most sites have images which tend to be from 500KB to 1MB big and a lot of them and the site still has a reasonable loading time

 

Thanks for information shemseddine i have decreases my CSS size 46KB to 18KB with same layout used colors no images.

 

18 sounds more "right" -- 48k is what I consider the upper limit for an entire forum or CMS; so you were probably 'ok' where it was, but it's nice to hear you got it down smaller.

It's kind of sad as today people seem to see nothing wrong with using hundreds of K or more CSS thanks to idiotic halfwit frameworks like bootcrap or blueprint to do the job of 20k or less code. It's pathetic how many sites now seem to 'need' 200-300k of code NOT counting the frameworks to do with a framework what I can do in 20k or less without.

Same goes for all the idiotic halfwit bull like LESS, SASS, etc, etc... crutch for the inept at best, pissing all over the Internet at worst.

Bottom line? 18K? Keep up the good work!!! Glad to see somebody out there gets it.

 

Thanks dear for valuable advise.

 

If I may add my two cents...

While DeathShadow is totally right, there are other important factors for CSS:

1 - 48k -> iPhone won't cache it. I think the cache limit for iOS was in 25kb (can't recall right now)
2 - Try to serve from a cookieless domain. You wish the css to be cached as long as possible. Having it stored in a CDN is the best.
3 - Minify it! Use a tool like cssminifier to reduce the size even more. It will take out unnecessary spaces.
4 - Don't use more than 3 nested selectors (while they're "cascading", has an impact on parsing selectors with 3 or more levels (like: .some .thing .beyond a:hover {} is slower than .beyond a:hover {})

Have a nice day!

 

That restriction was lifted in iOS 4... though there are plenty of iOS3 devices still in circulation, really if it's less than 48k the re-request isn't the end of the world... at least not compared to the folks I've seen using hundreds of K of CSS for christmas only knows what. Of course, when I say 48k I mean uncompressed, since 48k of CSS should gzip down to a third that size.

That said, I usually use 8 to 12k total per site -- A quarter my "upper limit" statement. An entire forum software shouldn't need more than that upper limit other than developer ineptitude.

Which is why bootcrap is so laughably pathetic. 100k of CSS before you even start coding?

Decent advice, but really if you keep the page lean resorting to the CDN should be a last resort. Better advice would be to keep cookie usage to a minimum in the first place -- but if you can't offloading to another domain where cookies are not in place will reduce the header size and speed up the file requests.

To me minification is just a way for developers to sweep crappy code under the rug when mod_deflate is in the mix. By the time you gzip that minification ends up saving at most 100 bytes on anything well written, hardly worth the effort for the handful of people who don't get files gzipped.

I get the idea, but honestly if you have to resort to that you're probably doing something wrong that should be fixed elsewhere.

Sorry but to me this is a bullshit claim akin to the one the anti-table zealots use about rendering time. If you have enough DOM elements and enough CSS for that to even be noticeable on ANY device, either your device is $50 crap or you have such massively bloated HTML and CSS it probably shouldn't have been deployed in the first place.

As I say to the people who talk about the rendering time of tables "IF a 386/40 running windows 3.1 and IE4 can render a table in an acceptable amount of time, that's bull in the age of 1 ghz and faster processors in the palm of your hand."

I've seen people use the "nested selectors are slower" bull to justify throwing classes at everything -- which means more rules to parse and more HTML to transfer; which is so idiotically stupid I have to fight the urge to pimp-slap the people who say it. I suspect the vast majority of people crapping out bloated/slow turdpress templates fell for that particular LIE! Yes, I said LIE!

Kind of like how I get every time someone mentions garbage like LESS, SASS, OOCSS, jQuery, Bootcrap, YUI, Mootools, Prototype... Things that make MORE work, MORE code, make it HARDER to maintain, SLOWER to develop, that for some noodle-doodle halfwit reason people claim magically does the opposite; the only reason I can think of for that is said nitwits not knowing enough HTML, CSS or JavaScript to be making websites in the first damned place.

 

I don't think you understand how the stylesheet is applied. The style engine walks the DOM and for each element and its attributes, it scans the stylesheet in order, building a ruleset for that node. If it worked the other way 'round, your statement might have merit. As deathshadow pointed out, though, the amount of merit is so small as to be lost in the noise.

cheers,

gary

 

Selectors have an inherent efficiency, and to quote Steve Souders, the order of more to less efficient CSS selectors goes thus:

1. ID, e.g. #header
2. Class, e.g. .promo
3. Type, e.g. div
4. Adjacent sibling, e.g. h2 + p
5. Child, e.g. li > ul
6. Descendant, e.g. ul a
7. Universal, i.e. *
8. Attribute, e.g. [type="text"]
9. Pseudo-classes/-elements, e.g. a:hover

Cheers.

 

That makes no sense. What is your reference?

For example, an ID selector does not reduce the amount of processing, it only adds to the specificity. The ruleset for the DOM node is still built line by line. Consider that there are still rules other than than those specifically for #header that apply to the node.

cheers,

gary

 

http://stevesouders.com/about.php <- reference, that dude is the creator of YSLOW, and well, a bunch of stuff (Sandford, Google *i think*, etc), I would recommend his books without hesitation.

And just thinking loud here as I don't know how it happens in the browser guts... You're completely right: "many rules might apply to the same element", but that's only true if you process the stylesheet from the DOM. But... it makes more sense to me that the browser would process the stylesheet from the stylesheet (instead of re-walking the DOM that should be already loaded at that moment) then searching for elements the particular rule applies would save many ticks if the rule is as specific as an ID (In a perfect world, you would expect only 1 element that rule applies)

Have fun!

 

While this wouldn't be the first time I've called a "name" in the industry full of shit... Well, not full of shit, but pointing out something so small and meaningless that if it DOES have an impact on your page you have probably done something horrifically and terrifyingly wrong -- like too many DOM elements, too many selectors and rules -- you know, the type of dipshit bull that results in hundreds of K of HTML and CSS doing dozens of K's job.

See HTML/CSS "frameworks" like bootcrap or YUI, for which developers are all the dumber for them even existing.

All the selectors apply so quickly no matter how "deep" you go, that pissing and moaning about it is so ridiculously and ludicrously pointless, it makes a beachball look sharp. Damn, and people call me petty for saying not to use double quotes in PHP strings...

Especially when the alternative is what? Throw classes and ID's on everything? I'm SO sure all that extra markup will be SO much faster... not.

Though again, it's this type of asshattery that leads to people making menu's like this:

<nav id="primary-navigation" class="site-navigation primary-navigation" role="navigation">
				<button class="menu-toggle">Primary Menu</button>
				<a class="screen-reader-text skip-link" href="#content">Skip to content</a>
				<div class="nav-menu"><ul><li class="page_item page-item-2"><a href="/WordPress/?page_id=2">Sample Page</a></li></ul></div>

Code (markup):

... and then wondering like a halfwit fool "what's wrong with that?"

 

Don't worry about it. 46 kb is nothing. Most CMSs have numerous stylesheets. The only way a 46 kb stylesheet will effect your website's performance or load time is if you have bandwidth issues and you're already close to exceeding the limits. If that happens, it won't be the stylesheet you'll want to change, it will be your hosting plan.

 

Actually; I think if you go look at the CSSOM specification you will see that the CSS rules are not directly in the DOM they are in the stylesheet object which has its own set of properties an methods, only a few of which are actually exposed to the developer. The CSSOM specification deals with the building and populating of the stylesheet object so that it can be access by the rendering engine with index references. It has been a while since I dug around in the Firefox code, but I don't recall ever seeing anything that would indicate any support for the idea that specificity would equate to efficiency which is what is implied by the order of that list.