I was profiling https://www.huffingtonpost.com/ page load. It seems to use setTimeout quite heavily during page load, and the timers fire before load event - if one loads the page in foreground. When loaded in background, we throttle timers and they fire way later. This causes for example some slow js function to be execute way after load event.

Looks like this happens with https://www.nationalgeographic.com/ too

Just something for testing. Breaks probably all the tests :) remote: Follow the progress of your build on Treeherder: remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=536a8a06eb5f7a1cce4c7a3e12a9cfe741f882a4 remote: remote: It looks like this try push has talos jobs. Compare performance against a baseline revision: remote: https://treeherder.mozilla.org/perf.html#/comparechooser?newProject=try&newRevision=536a8a06eb5f7a1cce4c7a3e12a9cfe741f882a4 remote: recorded changegroup in replication log in 0.015s

This is likely related to Bug 1373723 -- in particular if Chrome is clamping setTimeout(0) to 1ms then they are, I believe, effectively deferring the event handling to the next frame. Perhaps the clamping solution could be considered as well as the above slow load timers. (I did a test of it here: https://phabricator.services.mozilla.com/D10946)