[webkit-dev] optimizing browser handling of Facebook Timeline scrolling

Geoffrey Garen 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:

(1) 50% of time spent in style calculation forced by accessing element.offsetHeight in JavaScript.

> 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 mailing list