launchpad developmentThis page is a collection of ideas for improving the Time To Interact of pages on Launchpad.net.
Contents
Which Users Should We Target?
Numbers for Firefox, OEM/IE in China (what versions of IE?), Europe vs. USA, new vs. repeat visitors, authenticated vs. unauthenticated, length of typical usage session, public vs private project usage
How do these factors affect TTI?
- - OEM TTI adds extra weight - Frequent, authenticated users are especially important
Therefore
- OEM/China: TTI of IE is more important than it might be if OEM were not a factor
- Around the globe: Latency is a very important factor
- Frequent users: Cacheing can be very effective
- Authenticated users: Cacheing of pages in Squid doesn't help our clients all that much
- Private users: SSL is still needed; need to determine how often, and whom it affects
What Can We Improve?
For each idea below, we do the following.
- We identify the types of users and situations it will help.
- We estimate the improvement for those users, based on the data collected for Launchpad. We focus on the 10 pages described XXX.
- When appropriate, we highlight important users and situations that will not be helped.
- When available, we sometimes link to documents describing the idea, as used or researched internally or externally to Canonical.
Network Time
XXX discuss typical percentage of request done in network
Make Librarian downloads reuse connections. Not doing so now. Reason unclear.
- Remove SSL. Private projects and teams would remain under HTTPS; everything else would be under HTTP. This would also probably suggest drastically reducing the amount of time that authentication cookies are kept, from a year to more like half an hour. This would reduce the risk of stealing session cookies in HTTP, and the openid server (HTTPS) could remain with long timeouts, perhaps, so that the user experience can still not require frequent logins. Switching back and forth from HTTP to HTTPS may be tricky, but we can probably find low-hanging fruit for initial implementations (e.g., force redirect to HTTPS if something private wants to be rendered over HTTP; offer redirect to HTTP if nothing private is rendered over HTTPS).
- Cut payloads
- Uglification: Remove newlines, spaces, and comments from returned HTML. Questionable value when text is already gzipped. No experiments showing cost.
- Remove Mochikit: Determine benefit for IE7. Probably of minimal benefit for other browsers because of parallel download.
- Are we serving static data from cookieless domains? (Probably so. Why is this bad?)
- Domain sharding for librarian lookups (need numbers to back this up)
- CDN or poor man's CDN to help US, Southwest Pacific, and South American users (What are options for poor man's CDN? Identify items we could and could not put on CDN; skeptical it would be a lot)
Generation Time
XXX discuss typical percentage of request spent in generation time.
- Chameleon (numbers?) (about 10-15% faster during generation, according to tests done by Gary Poster Q4 2009; specific results not available.)
- Memcached, MongoDB, or other similar technology
- cache page elements, such as bug comments and tag clouds
- cache ETags (can be used for launchpadlib)
- session data
- Detailed profiling numbers
- Time spent in session authentication?
- Time spent in the database?
- Time spent rendering the response?
Render Time
XXX discuss typical percentage of request spent in render time.
- Workaround IE cacheing problem
Load JavaScript using the deferred attribute
Lazy-loading JavaScript for key pages
- Change inline script node ordering to maximize parallel downloads
- Load less-important page elements later (already started in 3.0 UI)
