What are the aspects of style sheets (CSS) that can lead to poor performance of web sites?
Anything that can really choke up the CPU?
thanks in advance.
Sesh
IE expressions can be a killer if over used. They're reevaluated each and every time the rule is applied.
CSS? Not so much it's pretty tight, but on older (like gen 4) browsers I've seen problems with:
doing too much on the * selector
using inherit a lot
using the IE expression value abusively
loading a lot of external resources (images, other CSS docs)
applying a lot of what you might call unanchored selectors like div div
Basically anything which would be difficult to cascade through or would cascade a lot.
Browsers are very good at rendering CSS rules quickly.
Probably more important is the size of the CSS file. For most sites, this isn't a problem, but for larger sites it is something to be aware of.
For instance, cnn.com delivers something like 150K of CSS. This will take a few seconds on older modems, so CNN ought to make sure that their CSS is cacheable and gzipped.
I have personally never encountered anything in CSS that would do this. Flash content and exessively large pages are far more likely to slow down a browser. That said I would image over use of expressions or custom IE filters (as are often used for transparency of PNG images) may use a lot of CPU.
Something that chokes not-too-old browsers are huge backgrounds that use "background-position: fixed" a la Complexspiral Redux.
It's hard to affect the CPU (except with IE expressions, like sblundy mentioned), but it's very easy to affect the page-load time.
Try to follow Yahoo client-side performance guidelines, such as:
Put CSS links at the top of the page
Use <link> instead of #import
Combine CSS files
Minify CSS files
I have seen cases where high-resolution tiled background-images (usually jpg or png) cause a major slowdown (choppy effect) when you scroll.
Most likely, the CSS file is not choking the site quite so much as trips to the server, complex calc, etc. might. But if it is:
There's an art to writing a lightweight-but-effective css file system that is ever-evolving, to say the least. Effectively using classes and IDs to take advantage of the cascade, for example, can be tough, especially when the project evolves over time, or if the GUI writing it gets swapped out several times over the course of the lifecycle.
For every legacy browser you have to support, it adds a performance hit, especially if you're using hacks to get it done. Those can be tricky, especially if layered upon one another. Conditional comments are similar - the browser has to decipher which rules it follows, and read through everything before it renders.
Going full-size image when you could tile or set a color on a background is a drag on siteload, as well.
(Gratuitous shot) IE can take a long time to misrender your styles and elements.
Related
So I’m in the middle of fiddling around with a site and I notice it’s full of old code and IE style resets/hacks/polyfills etc. all of which it’s not necessary to support anymore.
Rather than me trawling through thousands of lines of CSS, is there a simple, efficient and safe way to detect and remove old styles from a stylesheet?
I’m talking _background: gray; -ms-filter:; -WebKit-border-radius:; and all the other proprietary things from back in the day.
This site will support modern browsers only, using standard CSS3 selectors and attributes, so if I can find a way to parse and either automatically remove or at least give me line numbers for the antiquated code, that’d save me a huge amount of time (and save me having to start from scratch!!!)
Thanks in advance guys!
I found an incredibly useful tool: https://www.projectwallace.com/
It doesn’t strip CSS, but gives a good overview!!!
I am wondering if unused CSS styles affect load times because I normally break my sections of my code using this format
/*===================
Nav-Styles
===================*/
However, I also use coda to write my code. It has a code navigator, which detects ids followed by {}
what I thought might help with my code organisation is to create this format of break
/*==========================================
#----NAV-STYLES-BEGIN {} /* Nav Styles */
==========================================*/
This will mean my section breaks will them appear in the code navigator and can be jumped to quickly. However, if this is going to cause speed related issues, the means will outweigh the end.
Is this a bad idea or will the difference be so insignificant that it's worth doing if I wanted?
The answers here are not correct.
Unused CSS does two things:
Adds more bytes that need to be downloaded before the engine can start rendering the page
The browser engine has to go through each css selector to evaluate whether it is on the page and how it should render.
The second part is crucial. If 50% of your css file is unused css, you are essentially have the browser engine take twice as long to render your CSS for the page. Of course, the type of CSS selectors you have matter as well, so the twice as long is more of a easy example than full truth. Never the less, unused CSS increases your browsers page load time, even when the file is cached on the local drive.
Any unused CSS or JS that is passed over the wire to the client will hurt the sites performance at the least to a small degree. The unused CSS increases the size of the page, therefore increasing the time it takes to download a page. A few characters here and there will not have a huge impact on your download times, however if there is a large amount of unused styling there may be an impact. This is why many people compress their CSS and JS.
The effect of this is going to be unnoticeable, and could be described as negligible at best. Regardless, you could use a build script to remove all comments and minify your CSS. This will improve load times, if only slightly.
The short answer - go for whatever is easiest to develop with. You can worry about production later.
I hesitate to add
I was wondering whether anyone knows of any tools available that perform the task of analyzing one or more CSS files, determining the similarity between the various rules within the files and presenting the user with options for the merging and reduction of rulesets.
I ask this because a project I am working on has reached the point where it has so much CSS that Internet Explorer (Still the bottom line I'm afraid) chokes on the CSS after page load, causing a 3-5 second lock-up in interactivity until the choke is processed.
In case you're wondering: Yes, I am sure it is the CSS causing this issue.
try any of these links, I much prefer css tidy and have used it successfully in the past.
css optimiser
cleancss
css tidy
There's the YUI CSS Compressor - you could give that a go, but I think it's more for file-size than actually combining rules.
I know this isn't exactly what you're asking for and it goes the opposite and makes your css files larger, but you might get some ideas to manually optimize your CSS organized by this
tool:
http://styleneat.com/index.php?PHPSESSID=j0thilea0b8sjao2vcs8g5ekh1
Again, not tools, but interesting reading:
http://code.google.com/speed/articles/optimizing-css.html
http://meiert.com/en/blog/20080515/css-organization-and-efficiency/
Not quite what you're after, but very useful for trimming down bloated CSS:
http://www.sitepoint.com/dustmeselectors/
Firefox plugin to tell you which CSS declarations are unused.
https://addons.mozilla.org/en-US/firefox/addon/60
Firefox Web Developer Toolbar: CSS > View style information > click on a page element - This'll show you all CSS that applies to an element, and the CSS file/s it's in.
I'm building a new site for my company, and I'm at the stage where I've created the html mockup of the first page. I'm going to use this as a basis for the rest of the site. I'm thinking of organising my stylesheet better now I've got the design looking consistent cross-browser, but I'm wondering how far to go when I'm breaking it up.
One idea is to have the following:
reset.css
typography.css
layout.css
colors.css
but where do I draw the line? theoretically I could go on and break them down into classes, ids etc, but I think thats going overboard.
Does this seem a reasonable method?
Coincidentally, A List Apart had an article covering this today. They recommend separating out into a few main categories, including some you listed (type, layout, color), but going further to include various tricks to keep older browsers happy.
On the other hand, keeping everything in one css file keeps the requests between browser & server down. A compromise might be to keep things separate for development, and merging for production (as a part of your build process, naturally :p).
I don't tend to split typography into a seperate stylesheet, although it seems like a good idea. I'd keep colours with typography though. My typical way is to have the following structure:
base.css
Global style used throughout the site
Aims to be extendable, for example so that it can be reskinned (but using the exisiting layout) for a microsite.
Implements/imports reset.css
page.css
Implements any page-specific changes.
microsite_skin.css
See base.css point 2
Pickledegg,
There's nothing wrong with breaking up style sheets. In fact, I find it very useful to organize css rules into different files based on their type, or what parts of the site they are applied to. If you lump rules into one large file, it can quickly become a mess and become very difficult to manage.
I would recommend coming up with your own scheme for separating your rules into files, and stick with it for all your projects.
I would break layout down into 2+ more parts, Base layout, IE Hacks, Menus (one for each menu area. This could be something like a top menu and a side menu)
If the site where to change color depending on the area I'd add one for each color area as well.
You also could use Yaml or similar as a base framework for your layout.
I'd keep the different stylesheets seperate while designing only merging them into 2-4 depending on the site shortly before uploading/releasing. always keeping the Hacks apart.
Separate them based on what you estimate your needs are going to be later on. If you think the typography, layout, or colours (globally) are going to change, then it's probably wise to at least delineate styles in that way so it's easier to replace one stylesheet with another later on.
But if you go too far in this you'll end up with duplicate rules everywhere (eg. #content having a font-family rule in typography.css, a color rule in colors.css, etc). That's not a logical way to split things up unless you anticipate the key changes to be taking place there.
If, on the other hand, like most sites the graphic design is going to remain fairly static but the architecture is going to have some changes made (eg a new content type) then you want to be grouping your styles based on the context of the site. For instance, article.css, search.css, etc.
Essentially, try to look ahead at what changes are going to be needed later on and then try to anticipate those changes in your css file setup.
The major problem IMO, is the duplicate property definition issue. This makes style-sheets unmanageable. To bypass this issue the divide and conquer approach is used. If we can ensure manageable style sheets with non-conflicting rules, then merging sheets or modularising them would be easy.
During reviews all I do is check for rule conflicts, classitis and divitis. Using Firebug/CSSTidy combination, the problem areas are highlighted. Thinking in these lines, I don't even look into typography and font-separation.
The goal is to have a singel base CSS file and separate browser hacks files. Multiple base CSS files would be needed if an application has different themes.
I put all styles, including IE6-and-7-specific styles, in one sheet. The IE6 and 7 styles are targeted using conditionally-commented divs that only appear if one of those browsers come to the site, e.g.:
<body>
<!--[if IE 7]><div class="IE IE7"><![endif]-->
<!--[if IE 6]><div class="IE IE6"><![endif]-->
... rest of markup ...
<!--[if IE]></div><![endif]-->
</body>
Not sure what people think of this approach, but the extra markup is negligible, and being able to include IE6/7 styles next to main styles without the use of hacks... just prepending the selector with ".IE" or ".IE6" etc, is a big convenience.
As for multiple stylesheets... save your HTTP requests. Use image sprites, one stylesheet, one "application.js" javascript, etc.
I'd still include separate sheets for the print and handheld styles, but that's about it...
Don't go too much further than that. If you do have to, try and find a way to merge them before production. The biggest issue is that you begin stacking up HTTP requests. It's not so much an issue for the browser but the amount of requests that need to be made for each page. I would say you are at a good point, more than 4 would be going somewhat overboard. Remember you can always use good commenting and formatting to break up large CSS files.
Whenever I'm trying to decide how far to break apart some files (I usually do this with code modules, but I apply the same principals to my css/js) I break it down to the smallest reusable files that make sense together. This isn't the best for the flow of data across the wire, but it makes maintainability of my source a lot easier. Especially if you're going to be having a lot of css floating around.
If you feel comfortable taking your colors.css and using the whole thing in another location without modification then you're probably fine.
Take a look at blueprint-css. Blueprint is a CSS framework which supplies a variety of default styles to you (such as browser reset code).
The style sheets in blueprint-css are organized as follows:
screen.css - default styles for screens
print.css - default styles for printing
ie.css - Internet Explorer specific fixes
application.css - contains the styles you write. Actually you shouldn't modify the previous three style sheets at all, because these are generated by blueprint-css. You can overwrite all blueprint-css styles in your application.css file.
For further details refer to the blueprint-css Git repository.
I break mine up almost exactly the same way:
reset.ccs - The standard reset from MeyerWeb
typography.css - Fonts, sizes, line-heights, etc
layout.css - All positioning, floats, alignments, etc.
colors.css (or more appropriately skin.css) - All colors, background images, etc.
These are then followed with IE-specific files included via conditional comments for the appropriate version.
I haven't had the need to separate them further, though I do organize each file in separate sections (base elements, named elements, classes, etc.)
UPDATE: I have changed my system a bit in the last few projects I have done.
base.css - Contains the CSS from the YUI reset and YUI base CSS files (with attribution)
main.css - Contains #import statements for the following:
typography.css - Fonts, sizes, line-heights, etc
layout.css - All positioning, floats, alignments, etc.
theme.css - All colors, background images, etc.
print.css - Overrides for the other CSS files to make the pages print-friendly.
I also then use conditional comments to add any IE-specific CSS files if needed.
My next step in improving this would be to add a build-process step to combine all of the CSS files into one file to reduce the HTTP requests on the server.
Everybody recommends to break. I'll be the devil's advocate.
How about NOT breaking style sheets. At least for production purposes is better to have a single request instead of many. The browser can process 2 simultaneous HTTP requests. This means that other 2 requests can be made after the first 2 are completed.
Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script, and similarly combining all CSS into a single stylesheet. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.
Yahoo and Google recommend this.
Google is recommending creating 2 files. One for everything necessary at the startup and 1 for everything else.
I think that even designers have to think in optimizing terms, not only hardcore developers.
I'm using CSS Filters to modify images on the fly within the browser. These work perfectly in Internet Explorer, but aren't supported in Firefox.
Does anyone know what the CSS Filter equivalent for these is for Firefox? An answer that would work cross browser (Safari, WebKit, Firefox, etc.) would be preferred.
<style type="text/css">
.CSSClassName {filter:Invert;}
.CSSClassName {filter:Xray;}
.CSSClassName {filter:Gray;}
.CSSClassName {filter:FlipV;}
</style>
Update: I know Filter is an IE specific feature. Is there any kind of equivalent for any of these that is supported by Firefox?
Please check the Nihilogic Javascript Image Effect Library:
supports IE and Fx pretty well
has a lot of effects
You can find many other effects in the CVI Projects:
they are also JS based
there's a Lab to experiment
Good Luck
Could you give us a concrete example of what exactly you're trying to do? You'd probably get fewer "Your brower sux" responses and more "How about trying this different approach?" ones.
Normally CSS is used to control the look and feel of HTML content, not add effects or edit images in clever ways. What you're trying to do might be possible using javascript, but a behavior-oriented script still probably isn't very well suited for the kind of tweaking you want to do (although something like this is a fun and very inefficient adventure in CSS / JS tomfoolery).
I can't imagine a scenario when you would need the client to perform image tweaking in real-time. You could modify images server-side and simply reference these modified versions with your CSS or possibly Javascript, depending on what you're doing exactly. ImageMagick is a great little command-line tool for all the image effects you would ever need, and is pretty simple to use by itself or within the server-side language of your choice. Or if you're using PHP, I believe PHP's GD library is pretty popular.
There are no equivalents in other browsers. The closest you could get is using a graphics library like Canvas and manipulating the images in it, but you'd have to write the manipulations yourself and they'd require JavaScript.
filter is an IE-only feature -- it is not available in any other browser.
SVG filters applied to HTML content.
Only works in Firefox 3.1 and above, though I think Safari is heading in the same direction.
None that I know of. Filter was an IE only thing and I don't think any other browser has followed with similar functionality.
What is there a specific use case you need?
I'm afraid that you are pretty much out of luck with most of the cross-browser filter-type functionality. CSS alone will not allow you to do most of these things. For example, there is no way to invert an image cross-browser just using CSS. You will have to have two different copies of the image (one inverted) or you could try using Javascript or maybe go about it a completely different way, but there is no simple solution solely in CSS.
There are filters, such as Gaussian Blur et al in SVG, which is supported natively by most browsers except IE.
Pure thought experiment here, you could wrap your images in an SVG object on the fly with javascript and attempt to apply filters to them.
I doubt this would work for background images, though perhaps with alot of clever positioning it could work.
It's unlikely to be a realistic solution. If you don't want to permanently modify your source images, Rudi has the best answer, using server side tools to apply transformations on the fly (or cached for performance) will be the best cross browser solution.
This is a very very old question but css has updated to now support filters. Read more about it at
https://developer.mozilla.org/en-US/docs/Web/CSS/filter
Syntax
With a function, use the following:
filter: <filter-function> [<filter-function>]* | none
For a reference to an SVG element, use the following:
filter: url(svg-url#element-id)
Not really, and hopefully there never will be. It's not a web standard CSS feature for the reason that you're using CSS to format the webpage, not the browser itself. The day that other web designers and developers think they should style my browser how they wish and are then do so is the day I stop visiting their pages (and I say this as a front end web guy).