Secondly, there are modules for Apache like mod_gzip that will compress all pages on the server before sending - it adds a small overhead to the server but I think it's worth it. In fact I have been running it for some years on this very server. However, most people recommend specifically excluding css and js files from compression because older browsers have trouble with them.
Why aren't the these files getting cached?
A combination of things. Perhaps her webserver isn't well configured (unlikely) but (most probably) they are being cached by good proxies and not being cached by buggy proxies and browsers. Nicole's stats perhaps program isn't smart enough to realize that and reports them as served in full.
Hint to stats package writers: a 206 response code means we saved bandwidth, thankyouverymuch
At any rate, the best correct strategies for this are:
- Easy, BIG savings: Use mod_gzip as MD indicates.
- Harder, medium size savings: For Moodle to learn how to give 206 responses or to "materialize" those files to static files that Apache serves. Makes it a lot harder to switch themes.
Actually this could all be done pretty easily with effective server-side cache managment.
One of the first thing I notice after using Moodle for a while is how huge the pages are, and how they don't seem to cache at all. Pretty much all the objects have 'modified' attributes, so why not let Moodle handle 'HEAD' requests and '206' responses?
Caching is something I've been looking at integrating into a few packages, I'm actually writing a little CMS with big potential at the moment. It uses extensive server-side and client-side caching to get things running smoothly.
One thing I really want to do (and sorry to get on this topic again) is implementing AJAX. Once done this would make query units much smaller; individual blocks would be loaded from the server seperatly so the block data could be cached as well. I'll post something up when I'm finished.
Our XHTML pages also cache, but not when you click on a link to go back to a page you've been to. This is by design. We had endless problems with IE which is overzealous about caching, and people would never see updated pages. The current headers (which took a lot of work!) address this.
Try hitting "back" in your browser, however, and the page should display instantly, in any browser.
What I found was that the library OPAC pages weighed in at approxiimately 3K, whereas the moodle pages, particularly the initial home page was weighing in at about 3 MB on the initial load (which I presume includes the .css initial load into cache). Even with increasing my script processing cache size from the default 16MB in php.ini to 46 MB did not give a great boost.
Here are the results of the load times: OPAC approximately 1 sec. & moodle approximately 9 seconds. I am running Ubuntu 8.10 with its standard LAMP installation which has the auto compression of pages enabled by default to take advantage of newer browsers. I used Mozilla Firefox and Internet Explorer without any noticeable differences in load time.
I have enabled use of the AJAX features of moodle.