In attempt to roughly measure impact, I will add links to regressions that we suspect are due to WPR-nondeterminism as I run across them.

https://bugs.chromium.org/p/chromium/issues/detail?id=825820

> A good way to get more insights of when this happens is to track which resources are served & when. We can add --enable-trace flag to wprgo to produce a trace file that tracks the timing of its requests/responses.

Can we do this with a netlog? If we observe replay nondeterminism, we can test whether that is due to network nondeterminism by comparing netlogs from two different replay runs.

#2: did we integrate netlog with Chrome tracing? If yes, how much overhead it's to enable netlog on all Chrome tracing based perf tests?

Yes. NetLog events can be enabled using "netlog" category in chrome tracing.

There is also a Telemetry profiler option for NetLog which will output regular NetLog traces. third_party/catapult/telemetry/telemetry/internal/platform/profiler/netlog_profiler.py.

Great. Then my only question left is whether it's lower overhead enough to enable for all browser test?

I think the advantage with tracking network resources in wprgo is it causes no overhead on the browser.

My guess is that enabling "netlog" category in chrome tracing has a non-trivial amount of perf cost. 

My bigger concern is that the trace events aren't easy to debug. The same goes for the server logs. Although having the logs is better than not having anything.