Coppermine, being a photo gallery or infact a media gallery, as it can serve much more than just images, faces a daunting task of transfering a lot of data to browser with every single request. This is not just bandwidth eater but sometimes also frustrating to users when they have to keep waiting for the complete page to be loaded.
To speedup the page loading without putting much pressure on the server, we can use some proven techniques. This post will discuss the htaccess way to better the page loading by caching and compressing the page contents wherever possible.
htaacess is a special file available only with Apache web-server. If you are running any other web server like Microsoft IIS or your webhost has disabled htaccess for Apache, then the techniques discussed here won’t work. Please confirm with your web host whether htaccess is available to you.
As a first step, create (or open an existing) .htaccess file using your favorite editor, in the root of your coppermine installtion.
Windows users, please note the dot (.) in the begining of filename. This is how the Apache expects the filename to be. Otherwise your file will be ignored.
Let’s start with content compression. It is generally a good idea to compress everything except the binary data. The following code will handle all the compression related stuff. It will also check for old browsers not supporting compression and will act accordingly.
# Below uses mod_deflate to compress text files. Never compress binary files. <IfModule mod_deflate.c> SetOutputFilter DEFLATE # compress content with type html, text, js, and css AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/javascript application/x-javascript <IfModule mod_headers.c> # properly handle requests coming from behind proxies Header append Vary User-Agent </IfModule> </IfModule> # Properly handle old browsers that do not support compression <IfModule mod_deflate.c> BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Explicitly exclude binary files from compression just in case SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|pdf|swf|ico|zip)$ no-gzip </IfModule>
Next, we will instruct the browser to cache the files which won’t be changing regularly. This way, browsers will utilize the copy they already have. A lot of bandwidth and time can be saved with this setting.
# Set long expire headers for better browser caching <IfModule mod_expires.c> ExpiresActive On ExpiresByType text/css "access plus 30 days" ExpiresByType text/javascript "access plus 7 days" ExpiresByType application/x-javascript "access plus 7 days" ExpiresByType application/javascript "access plus 7 days" ExpiresByType image/x-icon "access plus 7 days" ExpiresByType image/vnd.microsoft.icon "access plus 7 days" ExpiresByType image/png "access plus 30 days" ExpiresByType image/gif "access plus 30 days" ExpiresByType image/jpeg "access plus 30 days" ExpiresByType image/jpg "access plus 30 days" ExpiresByType application/x-shockwave-flash "access plus 30 days" </IfModule>
We will also turn off ETags and force the browser to rely on our cache control settings above.
Header unset ETag FileETag None
You can use Firefox extensions YSlow, Webdeveloper-toolbar and Live HTTP Headers to check whether the compression and caching are really working.
References:
NathanBowers.com
askapache.com
wrap-lines
It seems that compression didn’t work for my coppermine. I checked with http://www.gidnetwork.com/tools/gzip-test.php tool for testing and there is no compression. (gzip is enabled on my server).
As I searched on Coppermine Forum , Coppermine Galley is not suitable for GZIP compression. Every topic on gzip topic ends with the fact that for coppermine gzip is not working. Is that true ?
@twist3r: Few threads on coppermine forum mention that gzip does not help much in case of image galleries. However now a days galleries tend to be bigger with lots of photos. In such cases the html code increases and using compression will help.
Coppermine does not control gzip compression nor does it affect the compression behavior. So if it is not working on your server then the root issue might be something else.
You are good enough if other things like Expire headers are working on your site.
I understand that on a images gallery gzip is not so important, but let’s take the fact that my index page is almost 156KB size and with first level of compression it will be 10,522 KB (not sure if it’s true, I just made a test).
So for me it’s pretty important. I just don’t understand why on others pages for my website it works, but for coppermine index page doesen’t.
Still, thanks for reply.
@twist3r: I will recommend checking your site with YSlow for compression. It will tell you exactly which files are not gzipped.
Also, here we are mainly dealing with gzipping CSS and JS files and caching images to make them load faster next time.
Finally, a link to your site would have been helpful.
afaik output compression doesn’t work well with output buffering being used by PHP scripts. But that’s what Coppermine does frequently (even nested output buffering) and that’s imo the culprit. However, the blog’s comment section is not the right place to discuss individual issues, as there is no support provided here. And this IS an individual issue imo. As Aditya suggested, output compression works best for completely static stuff like CSS and JS files. There is comparatively small benefit for dynamically created files, and there’s absolutely no caching effects if you have any random content enabled.
I strongly suggest to continue this discussion on the support board, as your questions are not generally discussing output compression nor the htaccess technology that this blog posting is about. What you request is help with the reduction of your gallery’s index page output if I understand this right. If you already have output compression working elsewhere, this article was not meant for you, as you then are already aware about the underlying technology.
Joachim Müller (aka GauGau)