Does *extreme* CSS tidy improve website performance?

My CSS is now tidied to a single line of code. Does this help in page rank?

[albo]

My editor (or even I, manually) can reduce CSS to a single line of code. This is an additional step in editing at the end of each session.

Maintenance would, of course, be quicker, and the file more human-legible, were the file to contain a few strategic line-ends, say, at the ends of certain selectors and their property groups. Would this deal a significant blow to site performance (and thus to page rank)?

[buckworks]

It's good to strip out redundant white space but one can go too far.

Removing line-ends at the ends of selectors in your CSS file will make a vanishingly small difference to how your site performs, so you might as well keep them to make life easier for yourself.

Page Rank is based on who links to you, so the amount of white space will not affect Page Rank unless your site is so ghastly slow that no one wants to link to it.

[wheel]

I doubt it makes any difference directly to SEO. Nor does it affect 'page-rank'.

It should however speed up the page. Depending on the size of the css file, perhaps even noticeably. CSS files can have a ton of bloat removed in most cases.

And speeding up the page this way helps your load time - and that's a very good thing to do.

If you tidy the css file AND make sure your pages are being served gzipped, then you have made some great strides towards having a fast website. And that's a very good thing.

So, yes. Do this. But not directly for the reason you're asking about.

[londrum]

the best CSS tool i've used was a firefox extension that goes through your entire site page-by-page, and highlights all the selectors that haven't been used, so you can strip them out.
if you're a lazy coder like me, and don't bother deleting all the redundant rules everytime you do a little redesign, then you can save loads of space.

[albo]

@londrum - I've done well at removing all unused selectors, so that shouldn't be a problem. (I tried to learn that well from Cederholm.) @wheel - html is *also* one-lined, as is js.

Mine is *strictly* a question about CSS line-ends: I had seen a remark elsewhere that, inasmuch as CSS (vs js) isn't "executable", heavy compression isn't necessarily a heavy benefit. @buckworks, you seem to have answered that question. Thanks.

[alt131]

Welcome to css albo - and also to the other posters who don't visit so often ;)

I noticed a lot more questions about the value of making css more efficient around the time google announced it would penalise "slow" sites. Is avoiding that penalty part of the thinking behind your question? If so, I think the real answer is we really don't know, but unlikely.

A few months back SuzyUK raised the issue in relation to efficient selectors. The thread got long and technical so I won't reference it, but one conclusion was there seemed to be real issues with the performance (and therefore results and suggestions) of pagespeed which was the tool provided for developers to measure and improve site performance to avoid the threatened penalty. Between us we did some informal tests across sites ranging from very well-coded to unbelievably dreadful, plus Suzy did a lot of work on a single site to test specific adjustments. Those tests suggested that even ghastly code can earn a respectable score of around 88 which will not earn a penalty, while it was quite difficult to move above that bench-mark, and in one bizarre situation required introducing an unnecessary and bad code practise to get a well-coded site to move from 99 to a so-called "perfect" 100.

That was in the context of the efficiency of selectors, but I think that the overall theory is relevant - on the scale of things a few line-ends won't make that much difference given the speed with which css is processed - unless the files are so bloated and contain so many line-ends the speed of processing is delayed to the point it becomes noticeable by a human. (Or you are still predominately serving to dial-up - although I don't believe google considers that in it's performance evaluation.)

Given the lack of reliable information about the penalty algo, and therefore how much a few bytes/micro-seconds processing will be penalised I think the primary issue remains delivery to users. In my tests of standard and very popular cms themes it was common to have so many server calls for so many different bloated files it was taking over 2 minutes to deliver content. Beyond ridiculous. As others have already identified, clean code, minimal server calls, compression and caching have a far greater impact on site performance - whether from the perspective of the user, the scoring system of google's provided tool, or site maintenance.

[albo]

Thanks *very* much, @alt131. Yes, my concern was about page rank, but primarily page rank inasmuch as it is influenced by site performance. Therefore, my question was *primarily* about the affect of line ends on performance.

As mentioned, I think my code will pass muster, but for the possibility that I might add some line ends instead of jumping through untidy/tidy hoops at each editing session. My clients use high-speed connections (I've not heard of any dial-ups for a long time!) But some - many - use iPads and other mobile devices, if that matters for speed's sake.

So I'm glad to hear "a few line-ends won't make that much difference given the speed with which css is processed." FWIW, I *think* I keep my CSS tight. One is 4K, one is 12K.

[lucy24]

I read the first post and immediately thought: A few years down the line, the document will end up in the "Worst Mess I Have Ever Cleaned Up" thread... and one of the things the poster will comment on is the formless horror that is the CSS ;)

Anyone on a Mac or *nix-based platform is ahead of the game, because each of our line breaks is only one byte (\n) instead of two (\r\n). Neener-neener.

Now and then you meet a page whose html starts with several dozen empty lines, so when you View Source you think they've exercised some kind of jiggery-pokery and there is no viewable source. Have yet to figure that one out.