3 ms·
This is a great article, walks through a bunch of complications with measuring web performance. Summary: 1. Use performance.now(), which has 0.1ms resolution
by laughinghan 7y ago
This is a great article, walks through a bunch of complications with measuring web performance.
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?
- cirwin 7y agoI like the idea of logging both for a bit! We’ve definitely seen CSS regressions too.
- jacobolus 7y ago> performance.now(), which has 0.1ms resolution and is monotonic Not so much anymore. MDN says: “The timestamp is not actually high-resolution. To mitigate security threats such as Spectre, browsers currently round the results to varying degrees. (Firefox started rounding to 1 millisecond in Firefox 60.) Some browsers may also slightly randomize the timestamp. The precision may improve again in future releases; browser developers are still investigating these timing attacks and how best to mitigate them.”