performance improvement using etags, expires and deflate where available #2128
Reported by dan on 31 Mar 2009 02:28 UTC as Trac ticket #1485800
Using Firefox' firebug and YSlow plugin the following recommendations on Etags, Expires and deflate were implemented to produce the attached patch. This should enable a better performing site for users.
Keywords: etag decompress deflate expires
The text was updated successfully, but these errors were encountered:
Comment by dan on 1 Apr 2009 20:45 UTC
Replying to thomasb:
Could say that security on logs,temp, and config is a webmaster's job too and yet !RoundCube provides it out of the box.
It really can't hurt to provide a little config in the right places and the skilled webmasters can tweak it if they want and the rest of the get a better performing product without extra effort.
Comment by tensor on 7 Apr 2009 18:33 UTC
I am not an HTTP expiration expert, so I have some questions.
What if the user changes some settings which affect display of the messages (generated HTML)? Will the new representation be automagically picked by the browser?
Comment by dan on 15 Apr 2009 10:16 UTC
Replying to tensor:
generated HTML from PHP scripts doesn't gain the specified HTTP expiry or cache control directives. They gain ones like below that tell the browser that it is expired and should not be cached.
yes, because dynamic content has directives to specify no caching.
As many hints are given to the browser that it is dynamic content there should be no detriment.
Though this patch adds .htaccess to the program directory it only has an effect on static content like css, js, images and static html. It was an easy place to add one directive that effect multiple subdirectories.
If a user changed the default skin files they may not be fetched by the user as they have a one month maximum age. A refresh/reload in the user browser will get the newer version. Going off this http://blogs.gnome.org/jamesh/2008/05/01/firefox-ssl/ it seems as though the lack of a cache control 'public' there will be no long term caching of ssl delivered skin information, though it will noticeably help browsing within the same session.
With YSlow and Firebug plugins - click on the Yslow in the bottom part of firefox and the YSlow, Components, (magnifing glass) to see the http headers for each component.
A few examples:
Comment by dan on 17 Apr 2009 12:00 UTC
Thanks to reading http:_blogs.gnome.org/jamesh/2008/05/01/firefox-ssl/ the value of 'Cache-Control: public' is pretty good. Firefox and IE will cache this locally even if in a SSL session. Other proxy caches will cache this for non-ssl sessions and share the code between users (http:_www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1).
Comment by dan on 20 Apr 2009 05:51 UTC
using cc97ea0, Firefox 3.0.8
Logout and Log back in:
Initial login: 60% bandwidth due to compression
Logout and Log back in: 96% less requests, 99.7% bandwidth reduction.