Ticket #518 (closed clarification: fixed)

Opened 5 years ago

Last modified 4 years ago

The PLoS web site could be speeded up using common best practices

Reported by: jsuttor Assigned to:
Priority: high Milestone:
Component: ambra Version:
Keywords: performance Cc:
Blocking: Blocked By:

Description

Yahoo did a presentation as OSCON on web site performance:

http://developer.yahoo.com/performance/rules.html

I installed the Firebug addon YSlow:

http://developer.yahoo.com/yslow/

and looked at PLoS. we're an F.

many of these are simple changes that would improve the PLoS experience

Dependency Graph

Change History

08/05/07 13:26:00 changed by ronald

See also: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://www.plosone.org/home.action (also available in the web-developer addon under Tools -> View Speed Report).

08/06/07 17:06:29 changed by jsuttor

  • milestone changed from 0.8 to 0.9.

08/07/07 17:57:57 changed by russ

some of these are me:

3. use an Expires header - i'm against this - i don't think it's worth the added complexity/pain of having to change the filename on each file update.

4. gzip components. yes.

13. configure etags. sounds like we can do without them.

X. use multiple hostnames. in the discussion for point 6 (http://developer.yahoo.com/performance/rules.html#js_bottom) they mention that using multiple hostnames allows for more parallel downloads, and later suggest using 4 hostnames. we could use images.plosone.org, javascript.plosone.org, and css.plosone.org (all resolving to the same IP) to encourage more parallel downloads of various included files.

09/02/07 22:41:40 changed by

  • milestone deleted.

Milestone 0.9 deleted

06/12/08 11:03:29 changed by amit

  • owner changed from jsuttor to pradeep.
  • blocking changed.
  • blockedby changed.
  • milestone set to 0.9.0.

Pradeep, please take a look at this while you are doing your performance improvements?

06/14/08 14:32:46 changed by amit

  • type changed from defect to clarification.

06/14/08 21:44:49 changed by amit

  • owner deleted.
  • milestone deleted.

Unless someone has obvious simple fixes I am moving this out of 0.9 as we need to start focusing on freezing the code base.

06/18/08 14:24:09 changed by pradeep

(In [6000]) Enable gzip compression for text files. (Not quite true: the filter is also applied to *.action which includes fetchObject that loads jpeg files from Fedora)

The filter is from ehcache. So no new jars and also it seems to be doing a pretty good job of handling the edge cases.

Addresses #518.

Note that I can't observe any difference in response times. However this does do a nice job of compressing .js and the article pages. So folks with low bandwidth connections would benefit. Take a look at it with 'yslow' to see. (Clear your browser cache if something doesn't show up as gzipped but it is supposed to be.)

Since I couldn't measure this and I am going by 'best practices' recommendations, if anyone feels that this has any negative effect, we can disable this filter any time.

06/18/08 19:15:08 changed by pradeep

(In [6007]) By popular demand, jetty gzip filter replaces the ehcache one from r6000. (Addresses #518) Thanks all for the comments, and thanks Ronald for the jetty-gzip pointer. Advantages of jetty gzip over ehcache:

  • mime type based filtering (eliminates fetchObject.action)
  • smart-buffering - (handles a min-gzip size properly)

Advantage for ehcache was we are already loading ehcache jar.

Note: I can't report a response time gain with gzip. Hopefully someone else can.

07/17/08 13:52:02 changed by amit

  • status changed from new to closed.
  • resolution set to fixed.