Just thought I'd share this with you:
I have installed the "YSlow" Firefox extension to find performance hogs on some of my pages for another project. For fun, I ran it on [[:en:Bezel]]. Something to think about:
These components are not gzipped: (0.6K) http://en.wikipedia.org/skins-1.5/common/shared.css?90 (27.5K) http://en.wikipedia.org/skins-1.5/monobook/main.css?90 (5.2K) http://en.wikipedia.org/skins-1.5/common/commonPrint.css?90 (39.8K) http://en.wikipedia.org/skins-1.5/common/wikibits.js?90 (4.5K) http://en.wikipedia.org/skins-1.5/common/ajax.js?90 (4.4K) http://en.wikipedia.org/skins-1.5/common/ajaxwatch.js?90
These components do not have a far future Expires header: (no expires) http://upload.wikimedia.org/wikipedia/commons/thumb/d/dc/Linguistics_stub.sv...] (no expires) http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png
This page has 9 external JavaScript files.
This page has 7 external StyleSheets.
So, I'll try to sum up: * css/js should be gzipped * images should have expiry date
Would that speed up anything? Probably on the first page load only...
Magnus
On 8/7/07, Magnus Manske magnusmanske@googlemail.com wrote:
These components are not gzipped: (0.6K) http://en.wikipedia.org/skins-1.5/common/shared.css?90 (27.5K) http://en.wikipedia.org/skins-1.5/monobook/main.css?90 (5.2K) http://en.wikipedia.org/skins-1.5/common/commonPrint.css?90 (39.8K) http://en.wikipedia.org/skins-1.5/common/wikibits.js?90 (4.5K) http://en.wikipedia.org/skins-1.5/common/ajax.js?90 (4.4K) http://en.wikipedia.org/skins-1.5/common/ajaxwatch.js?90
My recollection is that IE has issues with gzipped CSS/JS. And Googling shows that some people say other browsers also don't cache it on the client side for some reason.
These components do not have a far future Expires header: (no expires) http://upload.wikimedia.org/wikipedia/commons/thumb/d/dc/Linguistics_stub.sv...] (no expires) http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png
Why don't we use permanent URLs for images? I would have thought it would be something like /wikipedia/en/1/18/{versionnum}/Monobook-bullet.png. That would allow Expires to be set to "never" (or whatever the keyword is for that). As it stands, it looks like lighttpd-served images have no Cache-Control or Expires headers, so a new request has to be sent for every one on every page load, requiring an explicit 304.
This page has 9 external JavaScript files.
This page has 7 external StyleSheets.
We could definitely squash some of these into the same files for the purposes of serving them. Not all, though, because otherwise we damage client-side caching.
Of course, the figures are considerably lower than 16 pages for anonymous users.
Simetrical wrote:
On 8/7/07, Magnus Manske wrote:
These components are not gzipped: (0.6K) http://en.wikipedia.org/skins-1.5/common/shared.css?90 (27.5K) http://en.wikipedia.org/skins-1.5/monobook/main.css?90 (5.2K) http://en.wikipedia.org/skins-1.5/common/commonPrint.css?90 (39.8K) http://en.wikipedia.org/skins-1.5/common/wikibits.js?90 (4.5K) http://en.wikipedia.org/skins-1.5/common/ajax.js?90 (4.4K) http://en.wikipedia.org/skins-1.5/common/ajaxwatch.js?90
My recollection is that IE has issues with gzipped CSS/JS. And Googling shows that some people say other browsers also don't cache it on the client side for some reason.
These components do not have a far future Expires header: (no expires) http://upload.wikimedia.org/wikipedia/commons/thumb/d/dc/Linguistics_stub.sv...] (no expires) http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png
Why don't we use permanent URLs for images? I would have thought it would be something like /wikipedia/en/1/18/{versionnum}/Monobook-bullet.png. That would allow Expires to be set to "never" (or whatever the keyword is for that).
Note that this image is added at http://en.wikipedia.org/wiki/MediaWiki:Monobook.css so it's like any other normal upload (just that it is used on every page load).
When we use the FileStore, the url can have the file hash and thus never change. However, it's hurts usability.
This page has 9 external JavaScript files.
This page has 7 external StyleSheets.
We could definitely squash some of these into the same files for the purposes of serving them. Not all, though, because otherwise we damage client-side caching.
People will want to split functionalities on several custom pages. We should allow JavaScript transcluding (instead of action=raw, some kind of action=trancluded) so instead of insertPage(popups.js) you would have {{popups.js}}. The multiple http requests are probably as expensive as transcluding.
(no expires) http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png
Should interface images be given smaxage on url? Ie. http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png?smaxage=26...
On 8/7/07, Platonides Platonides@gmail.com wrote:
When we use the FileStore, the url can have the file hash and thus never change. However, it's hurts usability.
It could have a dummy query suffix instead, perhaps, like the ones we use for software CSS/JS inclusions.
People will want to split functionalities on several custom pages. We should allow JavaScript transcluding (instead of action=raw, some kind of action=trancluded) so instead of insertPage(popups.js) you would have {{popups.js}}.
We could start with eliminating the multiple loads for software pages. :)
The multiple http requests are probably as expensive as transcluding.
Transcluding should be no more expensive than an ordinary page view for low-change-rate things like this.
On 8/7/07, Platonides Platonides@gmail.com wrote:
Should interface images be given smaxage on url? Ie. http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png?smaxage=26...
Definitely. I had forgotten that that existed. How about an enwiki sysop add that now?
Simetrical wrote:
On 8/7/07, Platonides Platonides@gmail.com wrote:
When we use the FileStore, the url can have the file hash and thus never change. However, it's hurts usability.
It could have a dummy query suffix instead, perhaps, like the ones we use for software CSS/JS inclusions.
Hmm, hypothetically ought to work. Might have issues with cross-wiki usage.
On 8/7/07, Platonides Platonides@gmail.com wrote:
Should interface images be given smaxage on url? Ie. http://upload.wikimedia.org/wikipedia/en/1/18/Monobook-bullet.png?smaxage=26...
Definitely. I had forgotten that that existed. How about an enwiki sysop add that now?
Maybe because that wouldn't do anything? :)
-- brion vibber (brion @ wikimedia.org)
On 8/8/07, Brion Vibber brion@wikimedia.org wrote:
Simetrical wrote:
On 8/7/07, Platonides Platonides@gmail.com wrote:
When we use the FileStore, the url can have the file hash and thus never change. However, it's hurts usability.
It could have a dummy query suffix instead, perhaps, like the ones we use for software CSS/JS inclusions.
Hmm, hypothetically ought to work. Might have issues with cross-wiki usage.
Yeah, I guess everything would have to be purged every time the image was changed if that were done. Which would kind of defeat the point, I guess.
Maybe because that wouldn't do anything? :)
That's a good reason. :D
Simetrical wrote:
My recollection is that IE has issues with gzipped CSS/JS. And Googling shows that some people say other browsers also don't cache it on the client side for some reason.
Testing this to see if it's actually true would be wise. ;)
We already gzip the JS/CSS output that comes from MediaWiki itself; just the on-disk files are by default served uncompressed.
In theory we can stick in mod_gzip or equivalent per previous discussions, it just hasn't been gotten to yet.
-- brion vibber (brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org