I'm considering micro-optimization of a huge CSS stylesheet and have a couple questions related to that:
Is lowercase better than uppercase for reducing file size?
Is background-position:right (5 chars); smaller than background-position:0 100%; (6 chars incl whitespace)?
Is there anything else that might help reduce file size? (Besides merging CSS selectors, properties etc ofcourse, that I'll have to do manually)
Thanks
You'd be much better serving the css gzipped, rather than worrying about things like that.
The character case doesn't matter, there's no difference in the number of bytes.
It depends on the browser:
The first statement is one byte shorter, but it also has a different meaning.
In general file size is not the only factor in the speed calculation. It also depends on how difficult it is for the browser to interpret it. So any overly clever CSS construct might squeeze some bytes out of the total size, but it's possible that the parsing process itself takes longer.
Back to your example: It is possible that second statement is a little bit slower, not just because of the extra space, but also the value consists of two tokens and depending on the internal representation of the background, the browser might have to do some unit conversions. On the other hand that keyword lookup can take a little more time, too, so it is really specific to a certain browser implementation. Most likely any gain would be in the range of nano-seconds and you shouldn't bother with this kind of optimization, as it most likely will not pay off. But if you really want to do this, you have to profile, i.e. measure the loading time.
In general it's enough to remove all comments and all unnecessary whitespace, but never do any development work on that "minified" source. Keep the original and recreate the compressed version when needed.
More information about this topic: www.minifycss.com and this.
Sounds like this is a lot of trouble, you're time might be best spent elsewhere if you're trying to get better performance. Are you aware of Steve Souders work on High Performance Websites? http://stevesouders.com/hpws/
Related
In a css file, how much difference is there between a file where the properties are in the same order for all selectors and one where they are randomly ordered, when considering the compressed output provided a process such as GZip.
Has anyone investigated this with some real examples and numbers they could share?
As order of bits always make a difference with compression, it will make a difference. But not as you could say one is better than the other. It's more like random (for us developers) which one will result in some bits more or less. But I think you will spent more time on finding the optimal solution than it would change something.
But remember, that some old IE had a functional difference considering the order of elements. As I remember, there was something that position had to be set before you want to set top, left, right, bottom and z-index (so attributes that only work when you have position).
I would just mind readability. This saves the most time (and by that money) during development :)
I'm looking for a consensus on CSS class/ID naming conventions. I generally have quite long, descriptive CSS class names, but I'm starting to realise that as my stylesheets get very large, all those extra bytes for class names must add up.
For example, I could use:
.episode-information-container
Or I could use:
.ep-info-box
Does the length here really make that much of a difference in terms of file size? Should I always opt for the shortest possible class name - without destroying its readability?
When it comes to trying to reduce your CSS file sizes for performance, every space counts. When you’re developing, it’s OK to format your code in the way that you’re comfortable with. However, there is absolutely no reason not to take out excess characters (a process known as minification) when you actually push your project onto the web where the size of your files really counts.
Too many developers simply don’t minify their files before launching their websites, and I think that’s a huge mistake. Although it may not feel like it makes much of a difference, when you have huge CSS files, it can improve your page response times.
Of course it matters. CSS is a text format; a CSS file is as large as the number of characters it contains.
But the length of your selectors doesn't make a very appreciable difference, unless you have lots and lots of selectors with long class names. If you're concerned about file size, you can minify your stylesheet to strip whitespace and comments, as well as serve it in a compressed format. That will usually yield a much more significant reduction than simply shortening your class names and IDs. Just focus on making your class names brief yet readable.
When I started working on my project I didn't really care so much about organizing my CSS file, but then I kept on adding ad-hoc selectors. Now I have 3048 lines of CSS code. I know I need to spend some time organizing this stuff and I know it will be much shorter once I do that since there's really a lot of redundancy.
But currently it's working fine (as it seems at least), and I just want to get the product out the door as soon as possible, so I was wondering, is this OK to have a long CSS like this and what are some of the critical drawbacks if any?
3048 lines isn't that bad, but it could be reduced; I'll give you benefit of the doubt and assume that you have a fairly complex site.
Super long CSS files start encountering problems in IE, which can only take a certain number of rules before it starts ignoring the rest.
Also, the longer the file, the more time it takes to parse - thus the longer it takes for your webpage to load.
Of course, with more rules comes more memory usage too.
That's about it, really.
It's okay if you don't mind gaining a reputation for being sloppy. That alone ought to be considered a "critical drawback". It takes no time at all to run it through a minimizer if you're sure that what you have currently is working.
As above, anybody looking at your website thinking about offering you a design opportunity might decide that you're sloppy and not make the offer.
It might take a few milliseconds longer for the client to parse.
It'll take half a second longer to load for people stuck on 768k DSL lines (there are still lots of those around).
Readability and the subsequent negatives.
Size. I mean since it is sent to the user, the longer it is the more time it will need (ofc with modern connection this is not a huge issue).
Consider Css language supersets like LessCss. It will dramatically decrease the complexity and increase productivity.
Also minifiers will help decreasing the size, with the trade off on readability, so minify only what is sent and not the code you are working on.
First things first, yes I know the render the same color, my question is is a simple query about speed.
This is just a topic of interest regarding optimising page load speeds, but which of the options in the title will render faster (even if it is the tiniest difference)?
My thought process is that with the shorthand version (#fff) the browser will be tasked with assuming the rest of the hex-dec is fff. On the other side the longhand version might take longer or less time because of the extra explicit characters.
I figured someone might be able to shed some light on the topic.
#fff is fewer characters, which is generally better. Network latency and bandwidth matter more than processing time in most cases. For this reason, most CSS compressors will intelligently optimize to the #fff version. The network matters more than parsing speed in this case.
If you're concerned about parsing time, I doubt the difference between the 2 declarations accounts for even 0.005% of total parsing time. There are much bigger bottlenecks that dwarf any speed difference compared to parsing color declarations.
It depends on the implementation. One browser could take 100 times longer for the long version, and another browser would be the other way around.
Write your code so that it's readable, meaning easy to change going forward. If you want fast CSS consider using yui-compressor.
I noticed some people don't bother having the usual incremented number as ID but instead simply generate a GUID. The advantages include:
Quick and easy
No need to keep track of previous IDs
Guaranteed to be unique even across machines without knowledge of each other
Some disadvantages are:
Possibly performance bottleneck
Uses a large number of bytes
My understanding is that using a GUID is beneficial in most cases, except if optimization for time or space is an issue. Did I miss something? Or do you agree with this idea?
A couple of cons:
Pain in the neck if you have to delve into anything manually (debuggin etc). They are completely unreadable.
Horrible if you ever need to pass them in a URL