Shared publicly  - 
Last week, Facebook engineers came over for a mini-summit entitled Timeline Timeline where we talked about how the Chrome DevTools' timeline can help improve the Facebook Timeline and vice versa.

Some notes I took:

● When figuring out how to speed up the CSS of a site, you need to identify % of time goes to selector matching, style recalculation, reflow and repaint. DevTools Timeline and Speed Tracer can help here.
● Worried about paint? Toggle off an element’s painting with visibility:hidden and try then.
● Worried about reflow? Take it out of the render tree with display:none
● Use requestAnimationFrame to measure FPS
● You can try out “Threaded compositing” in about:flags for iOS-like scrolling.
● Fixed background images are very costly to framerate.
● Chrome lazily decodes images from JPG, etc. Client scaling of images is expensive as it keeps both the original decoded image in memory and the new scale. This can force other images to be evicted from memory which means another re-decoding later on. Chrome Task Manager can watch your image cache numbers: if the image memory consumption is mostly the same while you’re seeing new images, then you’re probably evicting old ones.
● performance.webkitNow() landed in Chrome and is a big deal: High resolution timing (nanosecond and beyond)
● A potential way to track memory leaks of DOM nodes is holding element refrences with WeakMaps, run a setTimeout to give some time after “deleting” some DOM and see if the WeakMaps still retain a reference. If so, you probably have a memory leak.
● It’d be fun to have a contest: You have 1 div and 500 bytes. Make the slowest painting page.

In the photo (L to R): +Nate Chapin +Burak Guzel +Nat Duca +Paul Irish +James Ide +Lior Abraham +James R (and +Steven Young behind the camera)
Paul Irish's profile photoTzafrir Rehan's profile photoJames Robinson's profile photoVincenzo Petrucci's profile photo
+Ben Vanik ah interesting. I see Nat is looking into it. Good good.

+Tzafrir Rehan We got some ideas on how the Chrome DevTools could be more helpful; I'm sharing those with the engineering team :)
+Ben Vanik requestAnimationFrame can tell you exactly how fast the browser can call into JS and have the results of that go up on screen. If you are driving an animation (or game or whatever) with requestAnimationFrame, then that's precisely the number you want. If you want to know how fast a video/CSS animation/etc on the page is playing, say, then it won't help you all that much since the actual number might be higher or lower, but that's a different concern.
Add a comment...