Thanks for reporting this, I'm looking at it now.

Hum, at least we still have the Startup.BrowserMessageLoopStartHardFaultCount histogram, I didn't realized that we used a global variable to store the startup temperature in this function.

The proper way to fix this would probably be to use PostTaskWithTraitsAndReply to execute the rest of the RecordBrowserMainMessageLoopStart function only after the startup temperature has been measured, but this might affect more metrics. We could also refactor the code to make sure that delaying the reporting of the temperature metric doesn't get affected but I'm not sure if it's entirely worth it.

Gathering the page fault count in a background thread saves ~7.4ms at startup, which is nice but maybe nothing to fight for? I'll revert my CL for now.

Also, reading the page fault count in a background thread may affect the value that we get, especially if we apply more strict policies on when background tasks can run.