search

roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.87k stars 1.64k forks source link

performance improvement using etags, expires and deflate where available #2128

Closed rcubetrac closed 15 years ago

rcubetrac commented 15 years ago

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.

The following were also recommendations from the YSlow plugin that I have not implemented. JavaScript isn't my strong point so take these however you want.

    1. Make fewer HTTP requests
This page has 5 external JavaScript files.
This page has 16 CSS background images.
http://developer.yahoo.com/performance/rules.html#js_bottom
5 external scripts were found in the document HEAD. Could they be moved lower in the page?

    * [headers](HTTP)  /roundcubemail-svn/skins/default/splitter.js
    * [headers](HTTP)  /roundcubemail-svn/skins/default/functions.js
    * [headers](HTTP)  /roundcubemail-svn/program/js/common.js
    * [headers](HTTP)  /roundcubemail-svn/program/js/app.js
    * [headers](HTTP)  /roundcubemail-svn/program/js/list.js
28 rules containing "expression" were found across all the CSS text.

    * [headers](HTTP)  https://community.cacert.org/roundcubemail-svn/skins/default/common.css (4)
    * [headers](HTTP)  https://community.cacert.org/roundcubemail-svn/skins/default/mail.css (23)
    * inline style block (1)

Keywords: etag decompress deflate expires Migrated-From: http://trac.roundcube.net/ticket/1485800

rcubetrac commented 15 years ago

Owner changed by dan on 31 Mar 2009 02:46 UTC

=> none

rcubetrac commented 15 years ago

Owner changed by @alecpl on 31 Mar 2009 06:04 UTC

=> none

rcubetrac commented 15 years ago

Milestone changed by @alecpl on 31 Mar 2009 06:04 UTC

0.2.2 => 0.3-beta

rcubetrac commented 15 years ago

Comment by @thomascube on 1 Apr 2009 15:05 UTC

This actually has nothing to do with !RoundCube but is a general webserver optimization which every skilled webmaster should be able to do. Is it really our job to tweak all your servers out there?

rcubetrac commented 15 years ago

Severity changed by @thomascube on 1 Apr 2009 15:05 UTC

normal => minor

rcubetrac commented 15 years ago

Milestone changed by @thomascube on 1 Apr 2009 15:05 UTC

0.3-beta => later

rcubetrac commented 15 years ago

Comment by dan on 1 Apr 2009 20:45 UTC

Replying to thomasb:

This actually has nothing to do with !RoundCube but is a general webserver optimization which every skilled webmaster should be able to do. Is it really our job to tweak all your servers out there?

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.

rcubetrac commented 15 years ago

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? Are there any discrepancies between browsers in this area?

I think it is safe to apply proposed changes only to static files such as CSS, JavaScript and images.

rcubetrac commented 15 years ago

Comment by dan on 15 Apr 2009 10:16 UTC

Replying to tensor:

What if the user changes some settings which affect display of the messages (generated HTML)?

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.

Will the new representation be automagically picked by the browser?

yes, because dynamic content has directives to specify no caching.

Are there any discrepancies between browsers in this area?

As many hints are given to the browser that it is dynamic content there should be no detriment.

I think it is safe to apply proposed changes only to static files such as CSS, JavaScript and images.

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:

URL: /roundcubemail/?_task=mail
Response Headers
    Date:Wed, 15 Apr 2009 09:57:59 GMT
    Server:Apache
    Expires:Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma:no-cache
    Content-Encoding:gzip
    Vary:Accept-Encoding
    Content-Length:5931
    Keep-Alive:timeout=15, max=96
    Connection:Keep-Alive
    Content-Type:text/html; charset=UTF-8
URL /roundcubemail/skins/default/splitter.js
Response Headers
    Date:Wed, 15 Apr 2009 09:58:03 GMT
    Server:Apache
    Last-Modified:Wed, 17 Dec 2008 11:19:24 GMT
    Etag:"3f8b8700"
    Accept-Ranges:bytes
    Cache-Control:max-age=2592000
    Expires:Fri, 15 May 2009 09:58:03 GMT
    Vary:Accept-Encoding
    Content-Encoding:gzip
    Content-Length:1874
    Keep-Alive:timeout=15, max=95
    Connection:Keep-Alive
    Content-Type:application/x-javascript
rcubetrac commented 15 years ago

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).

rcubetrac commented 15 years ago

Comment by dan on 20 Apr 2009 05:51 UTC

using cc97ea05, Firefox 3.0.8

Without Patch:

Initial login:

    6.2K    1   HTML/Text
    192.8K  6   JavaScript Files
    24.7K   2   Stylesheet Files
    10.4K   17  CSS Images
    21.3K   18  Images
255.6K  Total size
44  HTTP requests

Logout and Log back in:

    6.2K    1   HTML/Text
    173.7K  6   JavaScript Files
    24.7K   2   Stylesheet Files
    0.0K    17  CSS Images
    0.0K    18  Images
204.7K  Total size
44  HTTP requests

With Patch:

Initial login: 60% bandwidth due to compression

    6.2K    1   HTML/Text
    60.1K   6   JavaScript Files
    5.4K    2   Stylesheet Files
    10.7K   17  CSS Images
    21.6K   18  Images
104.2K  Total size
44  HTTP requests

Logout and Log back in: 96% less requests, 99.7% bandwidth reduction.

    6.2K    1   HTML/Text
    0.0K    1   JavaScript File
6.2K    Total size
2   HTTP requests
rcubetrac commented 15 years ago

Milestone changed by dan on 20 Apr 2009 05:51 UTC

later => 0.3-beta

rcubetrac commented 15 years ago

Comment by Lazlo on 11 May 2009 16:23 UTC

Tested the patch (FF3, IE8), no issues found. Also tested it with Firebug/Yslow, it really reduces loading times.

Maybe you can also take #1485816 in your patch?

rcubetrac commented 15 years ago

Comment by @thomascube on 28 May 2009 20:19 UTC

Patch applied in d7f49d64

rcubetrac commented 15 years ago

Status changed by @thomascube on 28 May 2009 20:19 UTC

new => closed