I've been doing some experiments that have the potential to speed up the delivery of Moodle sites over the Web and reduce bandwidth usage by compressing the js and css files of Moodle, which account for the greatest percentage of file transfer in any Moodle site. If I can get it working properly completely, it has the potential to reduce the size of Moodle files being transmitted over the Web by 2/3. I'm no programmer though and I achieved what I did simply by following instructions, and I've run into a seemingly very minor snag with the css files which I have found a not ideal workaround for and a bigger problem with the js files. If anyone can find a solution for these problems and knows a way to work these hacks into Moodle correctly, I think this has potential to be a very helpful contribution to Moodle, especially for those who have users on dialup and who want to limit their bandwidth usage. I've submitted it as bug 4165 and you can read about it and follow up there.
I've looked into this in the past.
Firstly, the stylesheets and Javascripts have purposely been designed to cache nicely, so you only need to load them once anyway. Compressing them only helps on the first page load.
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.
Firstly, the stylesheets and Javascripts have purposely been designed to cache nicely, so you only need to load them once anyway. Compressing them only helps on the first page load.
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.
Perhaps, but looking at my own stats I see that the javascript and styles.php account for a disproportionately large portion of my bandwidth usage. For instance, in August, Moodle's js files accounted for 16.8% of my bandwidth usage. The styles.php file was the second most accessed file, after cron.php, and based on the number of unique visitors to the site, it isn't always getting cached, because the number of hits on that file is about 8 times the number of unique visitors. And when you are running a commercial site like mine that depends on people stumbling upon your site, the first impression with load times is important. If you are a university, it may not matter as much because you have a forced audience for your site.
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.
There's other factors that I think might account for it-people have the caching in their browsers turned off. Very common in places where the computer is open to public access-even in household situations where one person doesn't want others to see what they are browsing when they shut down the browser. People may refresh a page-this would be a likely action if someone wanted to see if there was new activity on the site since they logged in. People sometimes clear their cache. Caches have limits to how much they can hold. People may also access the site from different computers, so that it must load each time. I didn't think for a minute it had anything to do with my server, but rather what is going on at the user end.
I recently made a Javascript/CSS Cruncher. I'll see if I can hack together something for Moodle.
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.
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.
CSS files cache all the time for me.
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.
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.
A lot of this may be people who aren't logging in, but just visiting your home page. In any case, if it worries you, your solution is fine.
Although caching and compression can help keep page sizes down, one also has to ask what can be done to lighten the weight of the pages moodle sends to the client. I did some test runs using a library Online Public Access Catalog (OPAC) and moodle, both of which I host on the same server on the same web site.
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.
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.
3Mb? That seems very high! I'm seeing about 300k uncompressed on a vanilla Moodle site with all AJAX on, of which about 117k is CSS (measured using Yslow for Firebug).
I would like to point out a similar discussion on improving the performance of a Moodle site by minimizing files sizes. Unfortunately, using compression on a server, especially GZIP, causes problems with IE 6. So if you have to support IE 6, the best option is to minimize javascript and CSS. Please see http://moodle.org/mod/forum/discuss.php?d=115967#p509343