Last modified: 2009-05-07 18:53:30 UTC
According to YSlow, a number of JS and CSS files on commons aren't served gzip'd. The list includes: (27.4K) http://commons.wikimedia.org/skins-1.5/common/wikibits.js?165 (5.3K) http://commons.wikimedia.org/w/extensions/CategoryTree/CategoryTree.js?3 (4.7K) http://commons.wikimedia.org/skins-1.5/common/ajax.js?165 (4.5K) http://commons.wikimedia.org/skins-1.5/common/ajaxwatch.js?165 (23.0K) http://commons.wikimedia.org/skins-1.5/common/mwsuggest.js?165 (23.6K) http://commons.wikimedia.org/w/extensions/OggHandler/OggPlayer.js?8 (1.2K) http://commons.wikimedia.org/w/extensions/CategoryTree/CategoryTree.css?3 (4.7K) http://commons.wikimedia.org/skins-1.5/common/shared.css?165 (4.8K) http://commons.wikimedia.org/skins-1.5/common/commonPrint.css?165 (27.3K) http://commons.wikimedia.org/skins-1.5/monobook/main.css?165 (8.4K) http://commons.wikimedia.org/skins-1.5/chick/main.css?165
It's just a rule for the apaches. But i think some old browsers didn't cope well with gzipped javascript. It's an important point to check.
We've sent gzipped JS from the wiki for years, so if these browsers exist they're already broken. :)
(In reply to comment #2) > We've sent gzipped JS from the wiki for years, so if these browsers exist > they're already broken. :) > So it would be ok to compress these?
Changing component back to Wikimedia. This is not an issue that's reliably fixable in MediaWiki; it's a web server configuration change. (We could package .htaccess files with MediaWiki, I guess, but that's not reliable anyway. We could also serve the CSS/JS from a script, like one that combines all the files into one or two requests, but that's a much bigger kettle of fish than this bug.)
Setting this up in Apache for extension files should be pretty easy; we serve a lot of the core .css/.js out of the upload cluster however. River, how straightforward would it be configured SWS for this?
it's already done, although it's disabled at the moment. search for "http-compression" in /opt/webserver7/https-ms1/config/ms1-obj.conf.
(In reply to comment #6) > it's already done, although it's disabled at the moment. search for > "http-compression" in /opt/webserver7/https-ms1/config/ms1-obj.conf. > Disabled for some important reason, or could it be re-enabled OK?
(In reply to comment #7) > Disabled for some important reason, or could it be re-enabled OK? no particular reason, but some testing should be done on dynamic compression vs cached, and how much cpu it actually uses. http://docs.sun.com/app/docs/doc/820-6599/gedgd?a=view
pew.
Yay!
