See also related  issue 701435  for reducing the timeout lower than 1 second. I want to keep this bug focused on understanding why it takes longer than the currently intended 1 second timeout.

What's going on here is that when you close a tab, the browser sends the beforeunload IPC to the render process and starts a 1 second timeout. It fires. It then continues to close the page, which has its own independent 1 second timeout. That one too must fire before the page closes.

That's why it's 2 seconds.

This feels like it's gotten even slower.

Making it so that we cap at a total of one second might be something navigation folks would be interested in fixing. CCing them. :)

It seems like we should instead put effort into skipping beforeunload entirely if there aren't any handlers registered for it, in issue 365039.  That's likely to improve performance here in the vast majority of cases.

With shortening the timeout, we risk losing user data in more cases on a slow machine, so we have to be careful with that.

IMO waiting >2 seconds for anything to happen after you try to close a tab is a bad enough user experience that we should be more aggressive.

I'm supportive of adding measurement to see how often we kill the tab before the unload is completed though to make sure it doesn't go through the roof.

BTW same problem happens on unload too, not just beforeunload (update the demo code to unload).
+1 for measurement, I'll look into that aspect.