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
