Performance:Velocity2010
From MozillaWiki
Below is a summary of the feedback received from the "What can browsers do to help improve performance" session at the Velocity 2010 summit. Surprisingly to me, most of the proposals were network related, however it's possible that this was a biased group due to being a lot of server-side people.
- Do a better job caching resources I regularly use everyday.
Instead of simply using an LRU cache we should be able to detect that a resource is used very often and be much more conservative about purging that from cache. For example a site that I visit every morning should "never" get purged (within the limits of the http cache headers of course).
- Support concatenated gzip
Apparently if a response gzip encoded response contains several gzipped chunks we drop all but the first chunks. Specs says that we should unzip them all and concatenate the results.
- Support Trailers (for Cookie/ETag/last-changed/maybe more).
Trailers are like http headers, but they are sent after the response body. This is useful when the server needs to do a bunch of processing before it knows the value of a particular header. It's now forced to do all processing to figure out all header values before it can send any data to the browser.
- more metrics accessible via JS.
There is a spec draft from google at [1]. Though still needs some work.
- Limi resource packages.
Alexander Limi has a proposal for packaging several resources in zip [2]. Mostly not network related, but will probably touch networking code. Needs a final proposal.
- In a single DNS lookup be able to return resolutions for other domains.
Something about that a DNS response can contain resolutions for several domains. If we honored these this would allow the site to prepopulate our DNS cache. However this sounds a lot like the Kaminsky attack. Have to get more details.
- UA supported load balancing.
When the browser gets a DNS response with 4 A records, it should be able to pick the "best" one, i.e. the one that responds the fastest. In other words let the browser figure out which server is the "closest" and then send all requests to that server.
- TCP NODELAY flag.
Other browsers set this flag, but firefox only sets it for SSL connections. Links to chrome code with some comments[3][4] bug 542401 filed.
- TCP retransmit timeout.
Apparently chrome has changed this from 3000ms to 250ms.
- Need to improve the situation with ads.
Ads are a huge source of bad pageload performance. Usually ads contain a <script> element which document.writes the contents of the ad. This means that all page rendering blocks until the ad has been loaded, which usually happens very slowly. There's several proposals getting started for how to deal with this, including new elements/events/properties that affect script loading.
- Better layout support in CSS.
Right now pages end up having to create a lot of elements in order to get the page layout they want. A number of things get slower because of the large number of elements. Better CSS features should be able to reduce the number of elements that pages need to create. XUL Box layout helps a lot here apparently, unclear how much.
