I noticed that the user images are saved at a relatively high quality and wondered if there was any point in lowering it. Going from 90 to say 80 might halve the size of the images without any perceptible quality loss. But how would you go about measuring the impact of this?
Is there any easy way to check logs and see what percentage of total data transferred on a typical site is user images? And how could you quantify how much time is spent dowloading these on forum pages or other areas with long lists of users
Moodle sets the height of these images so the layout of the page shouldn't be held up, but simply the number of image requests might be a bottleneck. Though again Moodle is pretty good about setting appropriate cache headers so these should only need to be downloaded once.
Actually, to get some rough idea about the impact of this I ran Google's pagespeed service on the the main page of the Hardware and Performance forum and got a couple of surprising results,
https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Fmoodle.org_2Fmod_2Fforum_2Fview.php_3Fid_3D596&mobile=false
Firstly, the profile images served by Moodle could be made 24% smaller (losslessly!) by recompressing them.
Secondly, a bunch of the profile images are actually served by Gravatar but strangely, many of them are actually just the same "no profile image" placeholder, but served from different URLs e.g.
https://secure.gravatar.com/avatar/64d2ead6d7adfe7218ca33cf43ffff51?s=35&d=mm
https://secure.gravatar.com/avatar/01231d9860393374101568a3a9f2fed0?s=35&d=mm
And those images are only cached for 5 minutes.
I don't really know much about Gravatar, or Moodle's integration with it, but that seems like some kind of bug to me. Actually, after a bit of Googling, it seems like fallout from fixing this bug:
https://tracker.moodle.org/browse/MDL-35669
(There also seems to be a "moodleofficial" plugin that's doing a couple of weird things -- adding a border to the image rather than achieving the same effect via CSS, and putting a ? in the image url -- but that's of less relevance for ordinary Moodle users)
Hi David,
A bit of info about the caching headers - we used to have pretty poor caching headers caching on user profile images. Which Sam Marshall (I think) described as the worst of all worlds.. we wanted it to expire them relatively quickly in case the user changed their profile image, but wanted to cache it a bit to increase performance. This resulted in profile images which were cached long enough to annoy people changing their images (why has my picture not changed?) and short enough to be relatively useless for performance. We finally fixed that problem in 2.3 in MDL-32628, where we use a new name for new profile pictures and thus can set expires of a year. If you are using 2.2 or below then moving to 2.3 & above should see a lot less requests for profile images in your logs.
Firstly, the profile images served by Moodle could be made 24% smaller (losslessly!) by recompressing them.
We can do that with the Moodle served images if its possible in php. If you know the right imagemagick/gd incantations to do this lossless compression then please file a bug (the code which does this is process_new_icon in lib/gdlib.php).
Secondly, a bunch of the profile images are actually served by Gravatar but strangely, many of them are actually just the same "no profile image" placeholder, but served from different URLs e.g.
The way that gravatar works means that if we don't have a local moodle profile image for a user then we format a gravatar url for that user and set that as their profile image url. We pass gravatar our 'default image' in case they also don't have a gravatar account.
So those default images you are seeing are the same, but the urls are different because they are the urls for each users account. Unfortunately, gravatar suffer from the exact same problem as we used to - there is no way for them to set high expires headers because the user without a profile image might sign up for a gravatar account soon and they want that image to appear (or alternatively they might change their image).
So I don't think we can really do anything about the second problem.
I *think* the performance of the second issue (default fallback gravatars) could be improved by providing a url to a standard image, even if that image happens to be identical to the one currently being used.
So, if that is indeed the case, a better default value might be "moodle.org/pix/user/f1.png"
The difference is that for the "mm" case you are directly being served an image from gravatar which isn't cached for more than 5 minutes. For the second case you are following a url which isn't cached for more than 5 minutes, but if you follow that url you are then redirected to a single URL which has a copy of the original image stored on gravatar's servers.
The extra redirect obviously adds some time, but I'm guessing that overall you're saving because after the redirect your browser is saying, oh I've already got that image in cache and doing so once for every default image so that saving's going to add up.
The one thing that makes me somewhat unsure is wondering why gravatar doesn't use this system for it's own mystery man picture. Most of the other options are unique per user/email address so maybe they couldn't be bothered for the one standard image. Possibly they've optimised for functionality rather than speed, certainly most of the Google hits I turned up where suggesting that comments with gravatars should be loaded after a user click to prevent it slowing down the delivery of your actual content. But that wouldn't work with Moodle's current design as in a forum, the comment are the content.
But, actually, I'm more interested in the first possible saving as our site doesn't use gravatars. I'll try some experiments with losslessly compressing existing profile images and see if I can match Google's claim of 24% space saved. And then see about how much further savings could be made with lower quality jpeg settings.
So, if that is indeed the case, a better default value might be "moodle.org/pix/user/f1.png"
The difference is that for the "mm" case you are directly being served an image from gravatar which isn't cached for more than 5 minutes. For the second case you are following a url which isn't cached for more than 5 minutes, but if you follow that url you are then redirected to a single URL which has a copy of the original image stored on gravatar's servers.
The extra redirect obviously adds some time, but I'm guessing that overall you're saving because after the redirect your browser is saying, oh I've already got that image in cache and doing so once for every default image so that saving's going to add up.
The one thing that makes me somewhat unsure is wondering why gravatar doesn't use this system for it's own mystery man picture. Most of the other options are unique per user/email address so maybe they couldn't be bothered for the one standard image. Possibly they've optimised for functionality rather than speed, certainly most of the Google hits I turned up where suggesting that comments with gravatars should be loaded after a user click to prevent it slowing down the delivery of your actual content. But that wouldn't work with Moodle's current design as in a forum, the comment are the content.
But, actually, I'm more interested in the first possible saving as our site doesn't use gravatars. I'll try some experiments with losslessly compressing existing profile images and see if I can match Google's claim of 24% space saved. And then see about how much further savings could be made with lower quality jpeg settings.
I've not located the actual change in bug MDL-32628 yet (the github links seem dead) but is that the reason I have ?rev=8 on the ends of profile picture links?
Shouldn't that respect the slasharguments and not use a "?", Google recommends against them for things you want cached as some proxies assume it's not going to be a static resource.
Shouldn't that respect the slasharguments and not use a "?", Google recommends against them for things you want cached as some proxies assume it's not going to be a static resource.
While looking into this I also noticed that the default user image PNG could be further optimised, though lossily, by using a PNG quantiser so I filed a bug:
https://tracker.moodle.org/browse/MDL-37418
https://tracker.moodle.org/browse/MDL-37418