Launchpad should make external files cacheable

Bug #223482 reported by Scott Severance
4
Affects Status Importance Assigned to Milestone
Launchpad itself
New
Undecided
Unassigned

Bug Description

Launchpad is the slowest website I visit on a regular basis (with the possible exception of Sourceforge). I recently examined a random bug report using the Firebug and YSlow Firefox plugins and discovered the primary reason. That page (which I viewed after another bug so it should have had mostly cached content) took 24-26 seconds to load, depending on which number you believe (screenshot attached). The vast majority of the time was spent downloading one CSS file and four Javascript files, which the browser don't cache. Firefox won't render any part of a page until all CSS and Javascript have loaded and been parsed. In my opinion, this is a bug in Firefox, but nevertheless, it's the way it is.

Compounding the problem is the fact that HTTP requests are expensive, and HTTPS is hugely more expensive. In addition, I have satellite Internet, which has a lot of latency. I rarely see ping times of under one second. So any problems caused by improper caching are magnified on my end.

My recommendation is to set a far future expires header on all CSS and Javascript files (along with all those images that don't set Expires headers, which is most of them). I don't know the internal workings of Launchpad, but it appears that the Javascript files already use effectively-versioned URLs, so setting a 10-year expiration date shouldn't break anything.

The reason that it's important to set an expires header is that the browser can cache the data until the expiration date without even querying Launchpad to see if it's been modified or if the ETag matches. (Such a request would itself be expensive.)

Revision history for this message
Scott Severance (scott.severance) wrote :
Revision history for this message
Scott Severance (scott.severance) wrote :
Revision history for this message
Scott Severance (scott.severance) wrote :
Revision history for this message
Scott Severance (scott.severance) wrote :

As I was verifying that my attachements worked properly, I noticed that the back button is even broken. Firefox's status bar told me that it was "transferring data" after I hit the back button! This makes the back button really slow (20 seconds). Again it's imporper caching that's to blame, as the attached Firebug shot shows. I can't imagine why Firefox would hit Launchpad in the first place, since I hit back, not refresh. I don't know if this is a bug in Firefox that needs to be worked around, or if Launchpad is doing something improper.

Revision history for this message
James Henstridge (jamesh) wrote :

The main cause of this is that Firefox won't cache SSL content to disk by default (even if it is served with "Cache-Control: public").

You should see a performance improvement by changing the browser.cache.disk_cache_ssl setting to true in "about:config". Note that in Firefox <= 2, you'll see a broken padlock with this option because the security info is not saved in the cache (see https://bugzilla.mozilla.org/show_bug.cgi?id=262116).

Of course, the eventual solution is to allow use of Launchpad over plain HTTP. That'll require some changes to our auth infrastructure though.

Revision history for this message
James Henstridge (jamesh) wrote :

Actually, according to https://bugzilla.mozilla.org/show_bug.cgi?id=345181 Firefox 3 will cache "Cache-Control: public" SSL content by default.

It looks like we aren't including that header for stuff in /+icing/, which is where the CSS and JavaScript you mention are stored. That should be fixed.

Revision history for this message
Scott Severance (scott.severance) wrote :

Unmarking this as a duplicate, since using SSL is a separate issue (which would be great to see fixed).

The proper headers should still be sent. Cache-control: is good, but it still requires a round trip. Expires: is better (probably in conjunction with cache-control:) since it avoids a request altogether.

Does Firefox 3 ignore the Expires: header on SSL?

Revision history for this message
James Henstridge (jamesh) wrote :

We're using "Cache-Control: public,max-age=86400" for testing on staging.launchpad.net, which results in 1 day between cache revalidation (we'll look at adjusting the revalidation times later).

Note that omitting the Expires header or max-age cache control directive does not mean "don't cache" though: it means that the browser's heuristics take over (usually picking an expiry based on the age of the content).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.