Clarification... I actually read the "content delivery network<http://developer.yahoo.com/performance/rules.html#cdn>" explanation, that wouldn't make sense for the typical university, but the explanation found at http://developer.yahoo.com/performance/rules.html does make sense for a portal installation which is what I was describing.
Parker On Tue, May 13, 2008 at 10:03 AM, Parker Grimes <[EMAIL PROTECTED]> wrote: > I think the "Use content delivery network" is a valid approach even for > universities. At the very lease you can host your static content on a > separate web server and take advantage of parallel downloads. We use this > approach at SUU, all of our static content, CSS, images, JavaScript, are > hosted on a different web server than our portal server. > > Yahoo's documentation says this: > > Splitting components allows you to maximize parallel downloads. Make sure > you're using not more than 2-4 domains because of the DNS lookup penalty. > For example, you can host your HTML and dynamic content on www.example.organd > split static components between > static1.example.org and static2.example.org > > For more information check "Maximizing Parallel Downloads in the Carpool > Lane <http://yuiblog.com/blog/2007/04/11/performance-research-part-4/>" by > Tenni Theurer and Patty Chi. > Parker > > > On Tue, May 13, 2008 at 9:07 AM, Jen Bourey <[EMAIL PROTECTED]> wrote: > > > Comments inline . . . > > > > On Tue, May 13, 2008 at 10:53 AM, Eric Dalquist < > > [EMAIL PROTECTED]> wrote: > > > > > So from this report and Jen's email I think we could possibly look at > > > the following features within the container. > > > > > > 1. Add a GZIP filter. This is generally done by folks in their HTTP > > > server if they are interested though so I'm not sure it would be worth the > > > effort on our part > > > > > > > From the jQuery documentation, I'm not sure this is actually a good > > idea. Do we have a clear idea of the network download speed improvement vs. > > client-side performance tradeoff? > > > > > > > > > 2. Add a filter that sets the expires header for static content. This > > > would be great but we would need to address issues around file naming. > > > Using > > > the expires header only really works if we're willing to never modify a > > > file > > > without also changing its name. I'm not sure we are at a place where we > > > can > > > try and dictate that from the framework without causing problems. > > > > > > > Maybe we could address this by setting long-term headers for the > > non-portal javascript, and leaving the portal's js as is? It actually makes > > quite a bit of sense to change the names of the jQuery main javascript and > > plugins when we upgrade those to new versions. The main jQuery file already > > has the version number in its name, and the jQuery UI files probably would > > benefit from having "-1.5beta" or something similar in their file names. > > > > I agree that setting long-term headers for the portal's javascript > > probably isn't a great idea right now. Since most of the javascript is > > jQuery and other plugins though, we could probably set headers on 80% or so > > of the javascript without making our lives painful. > > > > > > > > > 3. Add compile-time javascript minification. This probably won't be a > > > huge gain but we can look into it as it should have minimal affect on > > > uPortal implementers. > > > > > > > Good plan. > > > > > > What may be more valuable is for someone to look into doing local > > > tuning (setting up gzip and expires headers via apache) and documenting it > > > as a tuning-recipe on the wiki. > > > > > > > Sounds useful! > > > > - Jen > > > > -- > > > > You are currently subscribed to [email protected] as: [EMAIL > > PROTECTED] > > > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > > > > -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
