in reply to PM CSS and markup optimizations

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        

  • Comment on Re: PM CSS and markup optimizations (compression++)

Replies are listed 'Best First'.
Re^2: PM CSS and markup optimizations (compression++)
by cavac (Prior) on Jul 15, 2012 at 19:17 UTC

    Now, compression could actually make a difference

    I did some fairly large tests a year or two ago when i implemented it in my Maplat framework. Depending on the page size (i sometimes have fairly large data tables that i use with jQuery), compression even speeds up working within a 100MBit LAN.

    If the user works through a slow link (in this test me accessing the company network from home via an encrypted VPN tunnel), even small pages load quite a lot faster. Server performance degrades only slightly (e.g. the time the server requires to send out the page to the client), on DSL links the pages are still faster to load.

    CPU load isn't greatly increased on my server. Ok, i only get about 50.000-80.000 requests per hour, and only about 10.000 of those from clients that support compression, and it's all very database heavy.

    Sorry for any bad spelling, broken formatting and missing code examples. During a slight disagreement with my bicycle (which i lost), i broke my left forearm near the elbow. I'm doing the best i can here...
[reply]

      Just to offer some minor clarifications. The reason I don't think compression will make a big difference on typical page load times is that I expect at PerlMonks that most slow page loads are due to slow server response, not due to large amounts to be downloaded. But, yes, for people on slow links, compression could make a big difference even when PerlMonks is being slow to respond.

      I also don't expect compression to be a source of large amounts of CPU consumption. It was just that, at a time when the web servers were often just running out of CPU, taking CPU to compress the pages was as likely to make the server response enough slower that the net result was not an improvement. Even more important, when a web server got overloaded (ran out of CPU), adding to the CPU load for every page delivered would likely mean the overload condition would linger for longer (being slow leads to a build-up of requests which makes things slow...).

      Adding compression should be just a "win" at this point.

      - tye        

[reply]

In Section Perl Monks Discussion