search

ohmage / gwt-front-end

The javascript/GWT code behind the front end.
6 stars 2 forks source link

enable gzip and browser caching in tomcat #279

Closed jeroen closed 11 years ago

jeroen commented 11 years ago

Performance of the front-end can be significantly increased by enabling gzip in the web server layer (tomcat in our case). Also setting cache-control headers on the static resources will prevent the browser from re-downloading every js/css file over and over again.

See https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Ftest.ohmage.org_2Fweb_2F&mobile=false

stevenolen commented 11 years ago

Why don't we just roll this in with the goal of using a lightweight web server as a reverse proxy?

It seems fruitless to continue tweaking tomcat settings when we know our plan to avoid this in the future? On Feb 20, 2013 7:51 PM, "Jeroen" notifications@github.com wrote:

Performance of the front-end can be significantly increased by enabling gzip in the web server layer (tomcat in our case). Also setting cache-control headers on the static resources will prevent the browser from re-downloading every js/css file over and over again.

See https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Ftest.ohmage.org_2Fweb_2F&mobile=false

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageFrontEnd/issues/279.

jeroen commented 11 years ago

Cause that goal keeps getting filibustered:-)

On Wed, Feb 20, 2013 at 7:54 PM, stevenolen notifications@github.comwrote:

Why don't we just roll this in with the goal of using a lightweight web server as a reverse proxy?

It seems fruitless to continue tweaking tomcat settings when we know our plan to avoid this in the future? On Feb 20, 2013 7:51 PM, "Jeroen" notifications@github.com wrote:

Performance of the front-end can be significantly increased by enabling gzip in the web server layer (tomcat in our case). Also setting cache-control headers on the static resources will prevent the browser from re-downloading every js/css file over and over again.

See

https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Ftest.ohmage.org_2Fweb_2F&mobile=false

— Reply to this email directly or view it on GitHub< https://github.com/cens/ohmageFrontEnd/issues/279>.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageFrontEnd/issues/279#issuecomment-13871742.

jojenki commented 11 years ago

It's odd that it complains about the compression, because that it turned on. However, in my own cURL attempts, I cannot get it to compress it either. That is definitely worth looking into.

Maybe I don't understand your proposal, but I think we should rely on the container to control its own cache headers. I am not sure how comfortable I am with an intermediary modifying certain headers, but the cache one seems especially dangerous. It should be easy enough for Tomcat to set these, and, for content that it knows is static, these should already be setting them. When I tested this on my own, Chrome's Developer Tools did say they were pulling cached versions, so I am a little confused. It was still doing a round-trip, but the web server was returning a 304 (Not Modified).

stevenolen commented 11 years ago

I may be incorrect, but I think @jeroenooms's cache control request was slightly different. The frontend is not requesting the static files, which causes out of date files with the frontend frequently. Having the frontend request these files for each load, but the server responding with a 'not modified 304' when the file hasn't changed would both be "leveraging browser caching" and preventing stale files from being displayed. This type of thing should probably be handled with a static web server...