Summary:
1. Use performance.now(), which has 0.1ms resolution and is monotonic, instead of new Date() which has 1ms resolution and can decrease if machine time changes
2. Check for document.hidden and the 'visibilitychange' event
3. Use event.timeStamp for start time (when measuring responsiveness to an event)
4. Use the parameter that requestAnimationFrame() passes to callbacks to include time running framework code
5. You can nest requestAnimationFrame() to include Layout and Paint time, but that limits precision to 16ms so they didn't
6. Instead of percentiles, count % of events under a target like 100ms, it's more user-centric: instead of "how fast/slow is my app" it tells you "how often do users experience slowness"
7. Chart the counts at multiple targets in an percent stacked area chart
One weird thing to me about items 5 and 6—why not both? Why not have a chart including and a chart excluding Layout and Paint time, so you know if you're doing bad CSS or something that's introducing an expensive repaint? Why not have a stacked line chart with percentiles alongside the percent stacked area chart?