[webkit-dev] optimizing browser handling of Facebook Timeline scrolling
ggaren at apple.com
Mon Feb 13 14:41:30 PST 2012
Profiling scrolling through my own timeline, and focusing on points where the CPU hit 100% or greater, I saw this:
> We then have JS which checks the heights of all the
> stories on in the offscreen element so it can swap stories back and
> forth between the two columns, to keep things sorted by time going
> down the page.
One sometimes pernicious effect of accessing style-related properties while changing the DOM is that you force twice (or n times) the work to happen: first, style resolves to supply your property value; then, you change the DOM, and style resolves again to account for your change. Since style resolution is generally O(n), this can easily become O(n^2) behavior.
According to my measurements while scrolling my own timeline, you could make scrolling twice as buttery by removing these accesses to element.offsetHeight, or doing them on a zero-delay timer after all DOM changes.
(2) 50% of time spent painting images.
This is a simple speed vs quality tradeoff. If you down-sampled the images on the server, they'd download and paint much faster.
More information about the webkit-dev