The website I work for has a lot of overly complex pages. If I was able to use box-sizing on them my job would be made significantly easier in a number of respects. However, before I can just roll up and use box-sizing I need to convince the powers that be that using it does not create a noticeable degradation in page performance.
Now, the page they care about the most is a whopping 2.5 MB of resources (images, HTML, CSS, JS, etc) and the .htc file I'd need to upload is around 4 kb. So 0.0016% of the total file size. No problem there.
However, while this won't add any real rendering overhead to all the modern browsers, it will to IE6 and IE7 due to their needing to reference this behavior file.
The issue is, how do I test the page performance difference caused by using this behavior file?
I tried the CSS Stress Test but after it tested the 500+ other rules already applied to the page it only displayed a scant few results and not one related to the one I actually wanted.
Ideas?
The stress test I used was:
andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
I could not find a single IE+CSS performance tool to cover ie7/ie6.
What I can tell you from my experience using .htc files, namely csspie...is that you want to look at it from a js perspective, not css.
Having said that, to test js performance on ie6/ie7, try these:
DYNATRACE: http://ajax.dynatrace.com/pages/
COMPANION JS: http://www.my-debugbar.com/wiki/CompanionJS/HomePage
FIREBUG LITE: http://getfirebug.com/firebuglite
DEBUG BAR: http://www.debugbar.com/
I'm afraid I can't be more specific given there's no 'sample' live file to work with provided in your original post. Hope this helps.
Regards
G
Related
Once upon a time I was thought by more advanced web developers (gee, when was it again? ;)) that we should avoid managing multiple CSS files and stick to one per project. It helped to improve page load speed and avoid silly mistakes when dealing with a lot overlapping CSS rules.
My question is - is this approach still valid?
Argument about page load performance doesn't seem to hold that much nowadays with awesome broadband Internet and clever web browsers with even more awesome caching capabilities.
CSS cascading can indeed be error prone, but just for inexperienced developer and having one CSS style sheet doesn't really make us bullet-proof.
I think that I would prefer to have a set of default style sheets neatly separated by components, then wire them up into one single rule by CSS #import. This would also allow me to include reset style sheet by default.
Anyone is with me?
It's not about bandwidth speed but number of http requests, this makes a lot of sense for a mobile connection.
However the approach of having different css files to keep the project modular is solid, as it helps you keeping your css organized the way you want it without having all the code in one file only. Then you can benefit of css preprocessors / minifiers to concatenate and compress all your css files in a single one for production.
this article http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/
has a paragraph about mobile that explains well why this is a good practice:
you are much better off downloading all of the CSS content in one shot over the initial, warmed up connection. By doing so, you will also help the user extend their battery life. If there is one optimization to be made here then it is simply: concatenate and compress.
Yes, that approach is still valid. There are dozens of articles about load optimization out there, but the general idea is as follows
Less files = less http requests made to server = better load performance
Main thing that changed over time is that now there are many tools that support merging multiple files into single at runtime. So you have separate stylesheets for better organization, debugging at development time, and those tools merge, minify and set correct caching headers at production.
I agree with you, I find no reason to keep only a single css sheet anymore, nowadays, I do exactly what you just stated, separation by component, along with lazy loading :) (php if statements etc).
I separate stuff with comments. For example divs goes to /* Divs start*/ div#somediv /* Divs end*/ /* Animations start*/ /* Animations end*/. For me this is easier than merging different css files once i've completed the project
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)
I've recently begun working on a very large, high traffic website. We would very much like to reduce the size and number of our style sheets, minification is one route we will pursue but is anyone aware of any tools for checking ID and class use? Literally scanning the website to see what's active and what isn't?
Alternatively any software for redacting the css to reduce repition and size?
Thanks in advance
Literally scanning the website to see
what's active and what isn't?
Dust-Me Selectors is a Firefox plugin that you can use to show what css rules aren't being used.
http://www.sitepoint.com/dustmeselectors/
I can certainly recommend Page Speed (http://code.google.com/speed/page-speed/) by Google to check the performance (and possible improvements) of your webpages.
Page Speed also checks CSS and usage of classes on your webpages.
It is used in combination with Firebug.
Gzip compression in the webserver.
Expiry dates that lie far in the future to avoid redownloading the CSS files.
Alternatively any software for
redacting the css to reduce repition
and size?
Yet another level of indirection ... You (and your team) should write long CSS files with as many comments as needed and then write a tool that will publish merged files as needed (different templates need different files), stripped comments and minified as http://www.cleancss.com could do (CSSTidy). Readability comes first if you wan't to be able to modify a file in 1 month or keep track of modifications (or worse if sb else must do that!).
Other options are to reduce the number of templates used throughout the site. No need of two templates with 2px differences (grid layouts are a good way to stick to this) or inconsistent ways of displaying error messages. Define a common look and feel to your site and give instructions to webdesigners, if it isn't already done.
Some users are reporting that my site is too slow
And i think background images in css might be a possible
culprit
I have a site that uses a custom build system
to concatenate all css, compress them ( yui compressor ) , make css sprites
automatically ( smartsprites ) and I end up with a 9kb CSS for the
whole page, this includes all css for background-images at last is d they
were around 60 ( several go to the same sprite not sure how many )
I was wondering if the default behavior of browsers
is to download the images as needed ( when they match a selector )
or download them all.
Right now firebug in firefox seems to suggest that they are all been downloaded.
What techniques would you suggest i'd use to avoid the problem, and or
mitigate it.
edit:
I misread firebug, the images that are being downloaded belong to a lightview
that is hidden but the background-images are matched to the dom.
No, in fact it's better to put them in the CSS than in the markup.
The image calls will not block the page and as the images are loaded they will be rendered on the page so overall it is a good idea to load them via CSS. Not to mention that this design is also more flexible.
(It goes without saying that each of those images will take up bandwidth and extra HTTP requests)
the default browser behavior is to download two items at a time(i.e. 2 http requests), if you think you have lots of images create a sub domain for your images like images.yoursite.com and you will start seeing the browsers making parallel request, and you can see some improvement in performance
(Side topic. Not really answering your question. But might be interesting or even relevant.)
I think another possible culprit is that "some users" will always feel that your site is "too slow". (Maybe it's more of a Mental Breakdown than Stack Overflow thing? What do these users consider being a fast site? Can they give examples? How fast is their connection and computer? Where are they, and where is your server located? What exactly is slow? The signup process? Watching videos in HD? Scrolling the window? Loading Firefox? After all, it's humans.. n'est pas?)
Maybe take a closer look at the image(s) you're sending, particularly if there are a lot of them being compiled into a single "sprite" image.
What could be happening is that the image you're pointing to is very large. Sure, it should only be loaded once (the benefit of the sprite method), but if it's several hundred KB it could certainly cause some performance problems.
There's a nice firefox plugin called Yslow that gives you some useful information about performance optimization. It shows you performance issues it detected, and gives you links to articles suggesting an improvement.
http://developer.yahoo.com/yslow/
Some info on best practices
http://developer.yahoo.com/performance/rules.html