What is Digg?79 Comments
- inactive, on 10/12/2007, -1/+33If you are a high traffic site, 10kb saved per pageview will save you a lot of money in the long run.
- eric0213, on 10/12/2007, -3/+27A lot of work?
1. Run CSS through compressor
2. Save new file
3. Link to new file
Ugh... you're right, I'm exhausted! - i440, on 10/12/2007, -3/+20I suppose Google has "saved a lot of money in the long run." I mean, look at the home page!
- merreborn, on 10/12/2007, -4/+20"I think it might be very powerful since it is implemented in Haskell."
...
The efficiency of an algorithm is in no way related to the language in which it's implemented. You run the optimizer over your code once. Either it produces well-compressed CSS, or it doesn't.
If you're not already a PHB, you're well on your way to becoming one. - phoenixd, on 10/12/2007, -1/+17I agree with bpinard. It adds up fast, especially with larger sites.
- phoenixd, on 10/12/2007, -2/+15What do you mean?
- volve, on 10/12/2007, -0/+9To clarify for some people, you don't use these tools and then realistically expect to keep updating the same CSS file. Our production builds run through CSSTidy on it's highest compression settings (all non-destructive, safe optimizations of course) and the result is a single line of CSS which is absoloutely illegible to humans but your favourite browser of choice can quite happily render it.
Eg. our current templates reference "project_global.css" which is the unreadable version. We have a separate development version named "_dev_project_global.css". Upon generating a build of the site for testing or deployment, a CSSTidy script is run that says "take _dev_project_global.css, use settings XYZ spit out project_global.css" - voila.
Also, CleanCSS.com is based on CSSTidy which, at this point, is the most robust solution. Icey's very first line of text says "Remove hacks, they may cause problems." which is rather unhelpful if you're dealing with a large, enterprise site for thousands of users as it's akin to saying "Sure you can save a few bytes, but you have to change your files by hand first."
One last thing: yes, by default (unless you monkey with server cache settings) CSS files are definitely cached in the user's browser cache for a while, but if you have high-volumne, enterprise site you want two things; 1) as low a bandwidth bill as possible, and 2) as fast/smooth a user-experience as possible. Waiting 3 extra seconds can be a clincher for a new user to decide to leave the site or not.
Just my thoughts as I've been waist-deep in all this today. :) - merreborn, on 10/12/2007, -1/+9If your site receives 1 request per second, for every 1k this saves you per request, you'll be saving 84 meg a day in bandwidth.
- BrokenBeta, on 10/12/2007, -2/+10Don't mind him, he's just cranky that he had to type in a comment when he already did that last week.
- CaptainEO, on 10/12/2007, -2/+9One thing they did not state is that once you use their optimization tools, the css is no longer valid and doesn't pass W3C tests. The CSS on my site was valid before, and then after optimization, it didn't pass. It did, however, shave 55% off the size and the layout of my site did not change. I used Icey's.
- Beanlover, on 10/12/2007, -2/+9Everytime this comes up someone says that the CSS file is cached after the first visit and it doesn't save the site all that much.
So which is it? How much does this really matter? - phantom42, on 10/12/2007, -0/+7any amount of file size you can shave off can be really helpful in terms of bandwidth.
heres an article about the ESPN css redesign
http://www.mikeindustries.com/blog/archive/2003/06/espn-interview
based on their file size reduction and the sheer amount of traffic, they estimated that they'd be saving 2 terabytes of bandwidth per day. all by shaving off 50k off of their total file size. - gorkish, on 10/12/2007, -2/+9There are a couple little secrets here I'm gonna clue you in on as to why any large site doesn't even bother with this snake-oil BS.
1) The "compressors" do nasty hacks like removing whitespace and combining element properties, etc. Some rely on browser bugs to achieve further compression. All of this results in the inability to manage the CSS after it is "compressed" and it makes it incredibly difficult to track or find problems -- ie is this bug because of the CSS or because of the optimizer. It also adds the need to do more extensive testing whenever things are changed or added since the whole file needs to be run through agian possibliy introducing more problems.
2) The savings "adds up" but not as much as you think. If you want to shave 10Kb off of a user (not even a "visit" or a "hit") look at your images. There is no cost incentive to do it when you compare it to the amount of effort it takes to maintain the code after you have done this.
3) None of them actually work -- None of those tools work 100%. The time spent dealing with the problems you will face using one of these is ridiculous when you consider the gain you get.
4) There are alternatives that are better and cause far fewer problems. Look at mod_gzip or the equivalnet of whatever webserver you use. Slashdot's css goes from 10,886 bytes to 2,500 with mod_gzip (which they are using). Running it through one of these tools is even likely to create a less-compressible file! - Guspaz, on 10/12/2007, -0/+6@merreborn:
Since sites serious about saving bandwidth compress text content (mod_gzip or mod_deflate to compress html/xml/css/js/etc), I'd be interested to see how that affects results. These CSS shrinkers seem to work be removing redundancy, which would hurt compression ratios. I'm sure it'd still be an overall reduction, but I'd be interested to see the same results but with all the size figures AFTER compression.
See, how good a css shrinker performs might be different after compression. If one of the shrinkers outputted CSS that was particularly compressible, it could take an edge. - rogueman, on 10/12/2007, -0/+6Nobody mentioned this yet? Css is in a separate static file, and so it is always cached by the browser. So it's not 3 seconds per page view, it's 3 seconds per month, or at most per session.
Same with javascript code, it's in separate .js files and never loads twice. Very useful trick is to take a bunch of static html from your page (header, menus etc) and put it in a document.write() in a js file. Looks ugly as hell, but can speed up the page considerably. - ketsugi, on 10/12/2007, -0/+6I tried CleanCSS, and got valid CSS, although the savings are less (22.4% for my CSS file).
- phantom42, on 10/12/2007, -0/+5it may not matter much in terms of repeated viewings by the same user, but sites where you get a lot of unique users will benefit greatly.
our companies website really only has maybe three or four pages something like 30 total that really get hit hard - but they get hit by a lot of unique users.
so if we shave down 10k, sure we only save 10k per user, but getting thousands of hits a day, that adds up really quick. - merreborn, on 10/12/2007, -1/+5Guspaz: You have a point, but at the same time, if your logic were correct, Google wouldn't apply the same kind of optimization to their javascript -- take a look at any of their .js files: not a bit of whitespace to be found, and short variable names abound.
I'm pretty sure that the best way to reduce transmission size is *always* to reduce the size of the data to be transmitted, before compression, wether you intend to compress it or not.
Consider this, as well: this type of 'compression' is specially targeted at CSS, whereas gzip isn't, and as such, should be able to acheive greater space savings than any general compression algo. Even more, consider that the 'non-compressible' segments of a file are still 'non-compressible', before or after removing whitespace -- so either you can have gzip compress the 'non-compressible' bits *and* a bunch of whitespace, or only the 'non-compressible' bits. The later will be smaller than the former, every time. - webmarc, on 10/12/2007, -1/+5It usually is cached; this helps sites with broken CSS architecture (different CSS file for each page, non-cachable CSS files, etc).
As someone above also observed, it's also useful for saving bandwidth (though, so is making sure that the site isn't broken by design :-). - BrokenBeta, on 10/12/2007, -1/+5They do get cached, yes. But for a site like Digg or Slashdot, with so many viewers independently downloading the same information, it would still help quite a lot. Snowball effect.
- Abatrour, on 10/12/2007, -2/+6Digg is kinda bloated, have you tried viewing digg.com on a pda or psp? It takes forever to load.
I know there are other sites like pocketdigg.com which help with it but your only able to view the story titles in a mobile format, as soon as you click on the link to read it, it sends you to Digg.
Kevin really should focus on a lightweight/mobile version of digg for the PDA, PSP, and soon to be DS surfers. - merreborn, on 10/12/2007, -0/+4You can do the same, much more efficiently and intelligently, simply by installing mod_gzip.
- inactive, on 10/12/2007, -0/+3and don't forget http://www.crockford.com/javascript/jsmin.html for the js side. I use it combined with rsync with a very simple script it reduces very very well the size of the javascript files.
wonderful tool - Lagged2Death, on 10/12/2007, -2/+5HTTP compression is WAY better.
http://www.websiteoptimization.com/speed/tweak/compress/
Quote from the site: "HTTP compression uses public domain compression algorithms, like gzip and compress, to compress XHTML, JavaScript, CSS, and other text files at the server. This standards-based method of delivering compressed content is built into HTTP 1.1, and most modern browsers that support HTTP 1.1 support ZLIB inflation of deflated documents. In other words, they can decompress compressed files automatically, which saves time and bandwidth."
Quote from the site: "In tests that we ran on twenty popular sites we found that on average, content encoding saved 75% off of text files (HTML, CSS, and JavaScript) and 37% overall."
Scroll down to table 1 for an illustration of what a properly configured web server can do with GZIP. Big savings on HTML, CSS, and JavaScript files, with no special prep steps required by the site designers/maintainers.
And of course, all of these savings can be completely outweighed by even a couple of small images. - Lagged2Death, on 10/12/2007, -4/+7I'm not a web pro, so I may be off base here, but:
Don't CSS files get cached by the browser? Wouldn't that mean that the first page view by an individual web surfer would be ever-so-slightly faster, and the following ones would be unaffected?
Wouldn't using a compressed HTTP link have a much bigger impact, with fewer negative consequences and less hassle for the webmaster? - patmfitz, on 10/12/2007, -0/+3True, but by using PHP to generate CSS you can do all sorts of other tricks, like the following: http://www.barelyfitz.com/projects/csscolor/
- phantom42, on 10/12/2007, -0/+3yes, sonofagunn, you are correct. but the point and results are the same - smaller file sizes and less bandwidth being taken up.
im not commenting on whether or not these particular tools are really as good as one might hope - im commenting on the fact that smaller file sizes are always better.
it doesnt matter if they chose to go from tables to css, or if they decided to just replace selected graphics with simple colored backgrounds - when webdesigners reduce file size, we all win. - merreborn, on 10/12/2007, -1/+4No, it's not obfuscation. The level of obfuscation provided by the tool they use is completely insufficient to keep a determined programmer from deobfuscating it, even one of limited skill. Even more, they have nothing to lose by someone 'stealing' their javascript.
They serve 20 billion page view a day. Even a 1 byte savings per page view translates into 27 gigabytes a day.
(source of 20 bill figure: http://tinyurl.com/rhepg )
They'd be idiots *not* to strip every non-essential character from their pages. - Blah_Blah_Blah, on 10/12/2007, -0/+2oh right thats why some major sites got more than a 50% reduction in filesize with these optimization utilities.
- AhmedF, on 10/12/2007, -2/+4I have to say both of you are on crack.
1. Duh, anyone with half a clue knows the CSS becomes unreadable. Of course keeping a site.css (compressed) and site_readable.css (uncompressed) must be too much of an effort.
2. Every little saving counts. Or I guess your users aren't important enough.
3. Another weak argument. No one claimed they work 100%. It takes roughly 10 minutes to try all four, upload the CSS file, and see which one worked (or did not work).
4. People keep talking about this, and its beyond frustrating. GZip is something else. Its a compression scheme. A CSS optimizer is not a compression scheme - it takes overlapping elements and condenses them. If you like GZip on a normal file, imagine GZip on the condensed file. Not to mention that optimizing the CSS file takes up roughly 0 resources.
@cmburns69 - you must have trouble reading. The part where they say 'failed' must be where they forgot to see if the site still rendered properly [/sarcasm] - Isyso, on 10/12/2007, -3/+5Depends on browser and settings.
IE caches CSS. Firefox defaults to cache CSS. So, in reality, this does not matter. - mlmcgoo, on 10/12/2007, -1/+3This article is ridiculously fallacious, the numbers presented do not match up in the slightest. For the "clear winner", Icey's CSS Compressor the author states that the results were failed, 51.21, 47.08, 59.95, 45.49, and 69.84 EXCEPT earlier for the values of each individual site he states 45.39 (failed), 49.38, 47.08, 55.95, 0, and 69.84, and along with these inconsistent values he ignores the 0% compression. On top of this most of the numbers for every program do not match up with the results or average. His results are completely inconsistent with presented data. Marked as innaccurate.
- itswoody, on 10/12/2007, -1/+3If you can't optimise your own CSS when you write it then perhaps you should consider letting someone who knows what they're doing write it for you. CSS optimisation tools suck ass and all dev pros know it.
- Jaymoon, on 10/12/2007, -1/+2@merreborn:
However if your website is shaving off 27GB a day just with 1byte savings... You can afford the bandwidth, with or without the compression.... - andrethegiant, on 10/12/2007, -0/+1what about CSSTweak?
http://www.cssdev.com/csstweak/
they even have a widget for Dashboard - xs650, on 10/12/2007, -0/+1My CSS stylesheet is only a few kb but Icey’s CSS Compressor helped...not in the way you might expect.
I took the Icey modified CSS, manually reformatted it to easily human readable and did a line by line comparison with my original CSS. I learned a couple of ways to do things more efficently and found an error in Icey's version that would have messed up my site formatting.
It was worth the effort for me, even though I didn't directly use Icey's output. - jasper976, on 10/12/2007, -1/+2ICEY's worked really well for my ecommerce site. Sped up quite a bit and reduced size by half, and the layout is exactly the same. However like others have stated the CSS is no longer valid.
- gorkish, on 10/12/2007, -0/+1merreborn:
But look at google's HTML and logo images! If they were that overly concerned with bandwidth they'd optimize the hell out of those too, but they don't -- at least not as much as they could!
The real reason is that obfuscating .js code is an entirely different beast. In javascript whitespace and carriage returns are completely ignored by the interpreter, variable names can be shortened as long as they remain unique, etc. It's not as big of a problem as fighting CSS interpreter irregularities between browsers. But google isn't really doing it for the bandwidth savings either -- There is not a significant size difference between an obfuscated and compressed .js and a non-obfuscated and compressed .js, plus it's very simple to write a tool that works 100% of the time! However, even when you consider these points, you also have to remember that there are a few browsers out there like IE5 that have trouble with compressed .js files, so in this circumstance the slightly shortened version will take care of those as well as preventing people from digging too far into google's own inner workings.
You also have to remember how many people google has on this problem -- they have the resources to test a hundred browsers on every code revision; I don't, and neither do 99% of the people who are sitting here worrying about this sort of thing.
AhmedF:
Do you perchance WRITE one of these tools because you are certainly awfully sensitive about them!
Keeping two versions of the file around is only good for doing edits. When you edits expose bugs in the "compressor" it costs you time. When you have a user that reports a problem that occurs on the "compressed" css and not on the "uncompressed" version it costs you time -- you have to figure out how to work around it or avoid it because it's not really your bug. Worse, you have to end up doing tedious manual tweaking to the ugly processed file to fix it. Both the processed and unprocessed css should gzip to a very nearly identical size, so unless you can demonstrate that there is a significant speed gain achieved after running your code through a mangling engine, then fine, but you haven't done that and I have made many points as to why it's a bad thing. Sure it only takes 10 minutes to check and verify that it doesn't break your layout, but if you are trying to support an application with maybe 30 or 40 distinct layout styles in a website and ensure that it works on 15 different browsers and browser versions -- well doing that every time you edit the CSS certainly takes a lot longer than 10 minutes! - merreborn, on 10/12/2007, -1/+2"There are a couple little secrets here I'm gonna clue you in on as to why any large site doesn't even bother with this snake-oil BS."
Erm, have you ever looked at google's .js files?
Do a view source on maps.google.com
http://maps.google.com/
Nearly 10k. 25 carriage returns in the whole damn file. No whitespace anywhere, nor comments. - 15charmaxwtf, on 10/12/2007, -2/+3I think the argument against that is that bandwidth is cheaper than cpu cycles.
- sonofagunn, on 10/12/2007, -2/+3Yeah, because it would be so hard to save the uncompressed version and just make changes to that and recompress...
- plasmatic, on 10/12/2007, -0/+1it returns pretty good compressed css.
- Sueblimely, on 10/10/2007, -0/+1With the maze of on-line web page optimizer tools available, it is great to see someone who has taken the time to try them and analyze their effectiveness.
- Otto, on 10/12/2007, -0/+1>>>"I think the argument against that is that bandwidth is cheaper than cpu cycles."
Smart users of mod_gzip or mod_deflate configure it such that the compressed versions are cached for serving up later, saving on the CPU cycles. This gives you the bandiwdth benefit of compressed content without the CPU tradeoff of compressing it every time. - monkeywaffles, on 12/31/2007, -0/+1Well, if you want to compress your CSS files better than the online ones, check out http://www.artofscaling.com/14/css-minification/ It groups commonly used sets of elements and reduces file size by quite a bit
- bball2, on 10/12/2007, -0/+1I'm using css compress (wordpress plugin) : http://dev.wp-plugins.org/wiki/css-compress
and it has done the job amazingly well. It doesn't change the css at all. When activated the css file is called through the css-compress.php file and is outputtted without any comments and a lot of the spaces on a single line.
On my site // http://www.bballcity.com
It changed the css file from around 14kb to 5.881kb*
*according to http://www.websiteoptimization.com/services/analyze/ - sirsteveh, on 10/12/2007, -0/+1The date code could be better written as
header('Expires: ' + date('D, d M Y H:i:s T',time(0)+60*60));
Which will set the expiration date in the server's timezone (I use this for a list of RSS feeds on a sidebar for a site I'm working on. Except it expires every 5 minutes, not every hour). - rogueman, on 10/12/2007, -0/+1Long live the cache. Any method that can put a big part of the html in a page in a separate static file is way better then any compression. What html sorely lacked from the begining is an include feature. Luckily it can be simulated with javascript or other stuff, even though it's usually ugly as hell.
This said, text compression is usually worthwhile, especially for long text pages with repetitive content (tables). - zzttrooper, on 10/12/2007, -0/+1"Optimizing" your CSS may seem like a good idea when you look at one single file sitting on your hard drive. Files aren't transferred this way over the net. The information is all packetized and can be COMPRESSED. You may very well be transferring less bytes with the original CSS than one of the ones output by these optimizers.
I tested all four on a few CSS files... CSS Tidy-based optimization yielded larger files in every case regardless of setting. And none managed to keep ANY of the tested pages looking the same as they did with the original CSS. - gorkish, on 10/12/2007, -0/+1Finally someone who figured out a decent way to use this kind of tool!
Too bad the tool could have been composed as a How To on writing better CSS, things to look for when manually optimizing CSS, etc. But since they want you to use the tool, they won't do this... -
Show 51 - 79 of 79 discussions
Check out the new & improved 
© Digg Inc. 2009
— Content created and posted by Digg users is