>Hmm, Firebug (on Firefox 3.6) tells me something around 2.0 seconds
>(main page, full reload) and 1.1 seconds for a text-only content page
>with filled cache. Still, that can and should be optimized.
The Google stats average out all the visitors (at least those with Chrome), and probably some of them have slower internet connections.  That would be my guess.

>Caching issues I noticed when loading a page with filled cache (aka
>"click a link in the wiki"): The following files
>
>- http://en.opensuse.org/skins/common/shared.css?207
>- http://en.opensuse.org/skins/common/commonPrint.css?207
>- http://en.opensuse.org/skins/common/wikibits.js?207
>- http://en.opensuse.org/skins/common/ajax.js?207
>- http://en.opensuse.org/extensions/FlaggedRevs/flaggedrevs.css?56
>- http://en.opensuse.org/extensions/FlaggedRevs/flaggedrevs.js?56
>
>are requested at every page load, even if they don't change.
>The server always answers with "304 Not Modified".
>
>The problem seems to be the ?207 which probably has the intend to allow
>a long client-side cache lifetime, while being able to deliver a changed
>file quickly.
>
>The HTTP headers look similar with and without the ?207 - maybe Firefox
>does a revalidation on every file with ?foo...
>At least Firefox does _not_ do the revalidation if I remove the ?207 ;-)
>
>Proposed solution: remove the ?207 and modify the filename if needed
>(shared.207.css instead of shared.css?207). This could probably even be
>done with mod_rewrite if you don't want to keep shared.css on the
>webserver.
>
>Saving: 4 requests, 0.25 seconds

I think you are on the right track with that.  I was wondering the same thing, but I was looking on the server side and couldn't see anything that was out of the ordinary.  Cache directives are based on content type rather than file names/extensions, so there should be no reason Apache would be affected.

>Another problem is the Google Analytics pixel - it adds at least 0.1
>seconds till the onLoad event triggers.
>
>Just for fun, I added 
>    127.0.0.1 www.google-analytics.com
>to /etc/hosts. Besides a better privacy, this resulted in savings
>between 0.1 and 0.5 (!) seconds.
>
>Yes, statistics are nice - but are they worth a longer page load time?
>
>Maybe the google JS can be modified to run at onLoad or so - this would
>mean it doesn't hurt load time.
>
>Googling for "js defer google analytics" brought up this:
>http://phasetwo.org/post/defer-google-analytics-until-after-page-
>load.html
>Looks promising ;-)  but I didn't test it.

Awesome!  Funny how Google doesn't complain about itself in its page suggestions.  I have noticed requests to Google at the bottom of the browser when visiting the wiki, so there must be at least some appreciable amount of time for those requests.

>> File Caching - This would provide a major boost in speed.  [...]
>
>That's worth a try for sure ;-)
>
>Possible disadvantage besides what you mentioned: maybe (I did not test
>it) the "This page was viewed n times" counter might not get updated.
That is very likely the case.  I actually learned somewhere that disabling the counter entirely can shave off a decent amount of time, but who would want to get rid of something cool like that? ; )

>Regarding the aggressively caching: I'd say let's just try it and check
>what breaks ;-)
>The cron job to cleanup the file cache could move the files instead of
>deleting them, and make a diff at the next run. This should help to
>identify issues with over-cached pages.
>
>In the beginning, I'd let the cronjob delete files older than an hour.
>That should reduce the impact if something is accidently cached.
That is a possibility.  I'll have to think about this.

>> Caching Proxy (Squid) - An alternative to file caching and a viable
>>  long term option.  Would require some big changes and probably not
>>  justifiable right now...
>
>This would basically come with the same problems as the mediawiki file
>cache - and I doubt squid is much faster than the file cache.

It probably isn't any faster, and I forgot that iChain also does at least some web acceleration.  I think the reason that MediaWiki recommends it is that they provide some level of integration with Squid.  I don't know the details of it though.  We can probably bury the idea for now.