FYI more drupal.css stuff
NOTE: this is talk, not code! I ran drupal.css trough http://cdburnerxp.se/cssparse/css_optimiser.php a great tool. And it compressed drupal.css up to ~30% (unreadable CSS). But the standard, readable version compresses it still 23%! That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server. But it could also ship the compressed one by default with drupal, not? It would mean that we have an unreadable drupal.css (but who reads it anyway :P) but that we can save some bandwith. Ber
Ber Kessels wrote:
NOTE: this is talk, not code!
I ran drupal.css trough http://cdburnerxp.se/cssparse/css_optimiser.php a great tool. And it compressed drupal.css up to ~30% (unreadable CSS). But the standard, readable version compresses it still 23%! That is 2632 Bytes less for every uncached pageview. I certainly will use this tool on my server.
Not really. I think stylesheets are usually cached by the browser, and they're not reloaded unless you click on 'reload page'
But it could also ship the compressed one by default with drupal, not? It would mean that we have an unreadable drupal.css (but who reads it anyway :P) but that we can save some bandwith.
I really prefer working with the actual file that is being used. If we want to compress something, better strip out all that php comments that are parsed for every page :-) About css's, as they can be always overridden by the theme, you can try to merge all of them together in an optimized one for your production sites -all that css element's overriding is what actually takes time when rendering the pages...
On Sun, 13 Nov 2005 13:59:18 +0100 "Jose A. Reyero" <jareyero@wanadoo.es> wrote:
That is 2632 Bytes less for every ***uncached pageview***. I certainly will use this tool on my server. Not really. I think stylesheets are usually cached by the browser, and they're not reloaded unless you click on 'reload page'
On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%*80% = 24%. Or, less mathematical: on my server drupal.css is the #5 of biggest bw eating urls. It will save BW in my case. -- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
On Sun, Nov 13, 2005 at 03:42:17PM +0100, Ber Kessels wrote:
On Sun, 13 Nov 2005 13:59:18 +0100 "Jose A. Reyero" <jareyero@wanadoo.es> wrote:
That is 2632 Bytes less for every ***uncached pageview***. I certainly will use this tool on my server. Not really. I think stylesheets are usually cached by the browser, and they're not reloaded unless you click on 'reload page'
On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%*80% = 24%.
Or, less mathematical: on my server drupal.css is the #5 of biggest bw eating urls. It will save BW in my case.
Can we have some concrete numbers? How many KB is drupal.css and how many is everything else? -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
On Sun, 13 Nov 2005 15:48:03 +0100 piotr@mallorn.ii.uj.edu.pl (Piotr Krukowiecki) wrote:
Can we have some concrete numbers? How many KB is drupal.css and how
I dont have any, unfortunately. I only use webalizer in various different configurations. Just some common sense brought me the conclusion that it is my 5th biggest BW eater. Reason is: * it is available on most sites. (logo.png is different on every site, though the combined logos eat much more bw. pngcrush already helped reducing BW a lot!) * it is called on every page. While the BW for serving content of every page differs per page. * some my themes are so lightweight, that drupal.css is larger then the HTML+style.css *together*. I not proposing to do this for core, merely asking how interested people are in this. I am only giving this info, for others that might be interested. And for those who might want to work on drupal.css in future to consider. Too much has been said about that drupal.css already :p. -- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
On Nov 13, 2005, at 9:20 AM, Ber Kessels wrote:
I dont have any, unfortunately. I only use webalizer in various different configurations. Just some common sense brought me the conclusion that it is my 5th biggest BW eater. Reason is: * it is available on most sites. (logo.png is different on every site, though the combined logos eat much more bw. pngcrush already helped reducing BW a lot!) * it is called on every page. While the BW for serving content of every page differs per page. * some my themes are so lightweight, that drupal.css is larger then the HTML+style.css *together*.
That's anecdotal information, not the hard numbers required to make an informed decision. As someone attempted to point out, browsers cache css files and will only request them once per visit. You will see in your web logs that some drupal.css requests return a 200 status and the entire file, and some return a 304 "not modified" status and 0 bytes (plus HTTP headers) The common sense way to determine a file's usage is to grep it out of your web logs. To get a list of the number of times it has requested accessed: grep drupal.css your_log_file | wc -l In my case that was 298 hits out of 3565 ( cat your_log_file | wc -l) To get a list of the number of times it's actually been *downloaded*: grep drupal.css your_log_file | grep 'HTTP/1.1" 200' | wc -l In my case that was 119. So, in 3565 hits (~150MB according to my stats), drupal.css has been requested 298 times and downloaded 119 times, using roughly 1MB of traffic (9315b * 119) I agree that a 9k css file borders on unreasonable, and I'm sure your mileage varies (more than 1% but less than 24%). Here are two non- drupal solutions you can effect: 1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your content. You will save 30-70% on any text file it is configured to handle. 2) If you can't access your server's configuration and care more about bandwidth than cpu, have php handle .css files and use its gzip output handler. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
At 9:51 AM -0600 13/11/05, Allie Micka wrote:
1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your content. You will save 30-70% on any text file it is configured to handle.
If you're going to do that you will have to configure it to only compress .css files. If you compress all files being served you will double-compress pages generated by Drupal because they are already gzipped. That's probably why people are seeing so many bytes of .css being served compared with pages... pages are gzipped and only the amount of bytes sent is logged. But .css isn't compressed so the full file size is logged.
2) If you can't access your server's configuration and care more about bandwidth than cpu, have php handle .css files and use its gzip output handler.
There are recipes on the web for storing gzipped files in the filesystem and serving them rather than compressing the file for every hit. Save CPU as well as bandwidth :) ...R.
Richard Archer wrote:
At 9:51 AM -0600 13/11/05, Allie Micka wrote:
1) Install mod_gzip (apache 1.3) or mod_deflate (2.0) to gzip your content. You will save 30-70% on any text file it is configured to handle.
If you're going to do that you will have to configure it to only compress .css files. If you compress all files being served you will double-compress pages generated by Drupal because they are already gzipped.
Only cached pages are gzipped and I think that mod_gzip is bright enough to repsect the gzip header that is sent by Drupal.
That's probably why people are seeing so many bytes of .css being served compared with pages... pages are gzipped and only the amount of bytes sent is logged. But .css isn't compressed so the full file size is logged.
Possibly. There is a "gzip the css" task on drupal.org with some links on the topic.
2) If you can't access your server's configuration and care more about bandwidth than cpu, have php handle .css files and use its gzip output handler.
There are recipes on the web for storing gzipped files in the filesystem and serving them rather than compressing the file for every hit. Save CPU as well as bandwidth :)
That is the reason why we store cached pages in compressed form. Finally somebody who appreciates and understands that. ;p Cheers, Gerhard
I dont have any, unfortunately. I only use webalizer in various different configurations. Just some common sense brought me the conclusion that it is my 5th biggest BW eater.
Actually, my statistics were from Awstats. Webalizer is more granular: For October, site 1: Hits KB 4.82% 7.53% /misc/drupal.css 2.66% 5.21% /sites/default/themes/blah/style.css Site 2: Hits KB 3.67% 3.84% /misc/drupal.css 1.99% 2.77% /sites/default/themes/blah/style.css So, you can see that drupal.css is more of a contributer.
I not proposing to do this for core, merely asking how interested people are in this. I am only giving this info, for others that might be interested. And for those who might want to work on drupal.css in future to consider. Too much has been said about that drupal.css already :p.
I think that drupal.css can easily be overridden now in themes with no code changes? Am I correct?
On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%*80% = 24%.
This is something that I observed a long time ago. CSS is often a large part of my web sites' bandwidth usage. I wrote about that One site has .css files taking 10.5 % of the hits, yet 19.6 % of the bandwidth. Another site with a different theme has .css as 11 % of hits, and 13.6 % of bandwidth. That site has more css that the first one, since it uses event module which emits its own css. Both sites have the css compressed, although I remember the latter one having an issue with the compressed version, so I reverted back to the normal version. I forgot about drupal.css. I will compress that next, and copy it. Thanks Piotr for the reminder.
Can we have some concrete numbers? How many KB is drupal.css and how many is everything else?
Here is my case: drupal.css is 9315 in all cases (4.6.3). First site Before compression: 13254 After compression: 11547 Second site: No compression: 12180 (This confirms that I had to undo the compression for some CSS issue). On 11/13/05, Khalid B <kb@2bits.com> wrote:
On my servers i have ~20% recurring visits and ~80% one-time visits. So for me it would save 30%*80% = 24%.
This is something that I observed a long time ago. CSS is often a large part of my web sites' bandwidth usage. I wrote about that
One site has .css files taking 10.5 % of the hits, yet 19.6 % of the bandwidth.
Another site with a different theme has .css as 11 % of hits, and 13.6 % of bandwidth. That site has more css that the first one, since it uses event module which emits its own css.
Both sites have the css compressed, although I remember the latter one having an issue with the compressed version, so I reverted back to the normal version.
I forgot about drupal.css. I will compress that next, and copy it. Thanks Piotr for the reminder.
participants (7)
-
Allie Micka -
Ber Kessels -
Gerhard Killesreiter -
Jose A. Reyero -
Khalid B -
piotr＠mallorn.ii.uj.edu.pl -
Richard Archer