Please improve performance of launchpad.net

While the CSS and JS tip is good, I don't think that's what you're really looking for. Launchpad seems to serve those files very fast, to me.
It feels slow only in the preprocessing stage. Query caching would help, but that's not easy on complex applications like launchpad.

I've read that an Ajaxy UI is planned which should improve perceived snappiness

Took a quick look in Firebug, seems it must be in the preprocessing stage:

Initial GET request:

This page:
23KB @ 4.8s

Planet Ubuntu:
199KB @ 373ms

*both pages refreshed with a Ctrl-F5

At the bottom of each page source is a comment about the data base query part of loading the page. For this page I got:

<!-- at least 461 queries issued in 4.10 seconds -->
<!-- Launchpad 2.1.11 (r7322) -->

That seems like both a lot of queries and a lot of time.

The performance issues could also be disguised a bit better by reducing number of roundtrips required for particular use cases.

For instance, when I'm doing bug triage, my flow goes something like this:
1. Click link to load page (wait...)
2. Review bug
3. Click on an attached log to get some bit of data like which driver was used (loads quick)
4. Click back button to return to bug (wait... why doesn't this just pull instantly from the browser cache??)
5. Click on "edit description/title" (wait...)
6. Add the driver name to the title. Or paste in backtrace info. Click save (wait...)
7. Update the status/importance and leave a comment. Click save (wait...)
8. Move to next bug

If launchpad performance was improved by 20%, let's say, then my wait time would be reduced from 5 wait units to 4 wait units

But imagine instead that the workflow was adjusted so I could update the title from the main bug page rather than go to a separate page. That eliminates 2 waits (steps #5 and #6), so without changing launchpad at all, I've gone from 5 wait units to 3 wait units.

Just as a workaround, i've found that having a dns cache can make (and does make, here) launchpad faster. Without that, the usual load time for pages is 8+ seconds. Be greatful it isn't 40+ seconds again!

My workaround for minimizing the wait time is to work in parallel. My version of Bryce's work flow is
0. Right click on bug and select "Open in new tab" for 10-15 bugs (the first pages load while the next ones are selected)
1. Click on the first tab (no wait)
...
3. Open attached log in separate tab
4. Close the tab when done (avoids waiting for "Back")
...
7. Click save after doing the final action on a bug (don't wait)
8. Move to next bug on next tab
...
End of round or after next bug: Go back and check that no error occured and close the tab.

This eliminates 3 of the waits above. I don't always do 3-4 and 7-8 like that, but always 0-1.

Ryan wrote:
> Initial GET request:
>
> This page:
> 23KB @ 4.8s
>
> Planet Ubuntu:
> 199KB @ 373ms

Note that https requires more network round trips to set up the SSL connection
(at least 2, IIRC). So network latency has a larger effect on https connections
than on http connections, and launchpad.net serves most things via https.

Do we really need the https for every page?

I was going to file a bug on the number of tags getting displayed (in relation to Ubuntu specifically). Simply displaying all tags > 1 would reduce the list by orders of magnitude.
Should I file that bug separately, or simply leave this comment here?
On my laptop (which isn't exactly fast) Launchpad burns up the ram/cpu time like no other bts i've used (i think the only thing it struggles with more is Google maps, which has/should have considerably more data loading).

Please report individual bugs on individual performance techniques, and mark them with the "performance" tag. See my comment in bug 106452 for further explanation. Thanks!

For example, using HTTP instead of HTTPS is bug 46591, and reducing the number of tags displayed on Ubuntu's bugs page is bug 310693.