XP is just a number | |
PerlMonks |
Re: PM CSS and markup optimizations (compression++)by tye (Sage) |
on Jul 14, 2012 at 07:57 UTC ( [id://981777]=note: print w/replies, xml ) | Need Help?? |
Thanks for the link direct to a list of "unused" CSS selectors. Just glancing at the list I can tell you that the majority of them are indeed used and so the list has much more to do with what features of the site you have tested / are aware of / can even access. So that work was mostly wasted. Talk about some major bandwidth savings. I will, but that will have to wait a paragraph or few. 5% seems unlikely to be "major savings" much less savings worthy of an exclamation like "talk about". 5% of $0 is also only $0. Even if we didn't get bandwidth via donation, my expectation would be that a 5% drop would be pretty unlikely to drop a site down to the next lower tier and actually result in any savings at all. Similarly, a 5% savings in data download duration is unlikely to be even noticed in terms of page load time at this site. Even a fanciful worst-case scenario would still only lead to "loads 5% faster" which is unlikely to be noticed by a human. Now, compression could actually make a difference (on bandwidth used, not what we pay, and on worst-case page loads, not on typical page loads). Compression likely leads to something closer to a 90% reduction, if my memories serve me well and are reasonably applicable. I don't currently recall being aware of an actual decision having been made regarding compression. But it seems plausible that compression was not enabled (or even was disabled) quite a long time ago when one of our bottlenecks was sometimes web server CPU. I haven't reviewed data on web server CPU covering long spans of time recently, but my spot checks due to other tasks have usually shown rather low usage rates lately. So I suspect enabling compression would not be a problem these days. So I plan to look into that (review more data, see how to enable it). - tye
In Section
Perl Monks Discussion
|
|