In chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/loader/ProgressTracker.cpp, when trying to determine how many bytes we're going to load, we start by doing:

int numPendingOrLoadingRequests = m_frame->document()->fetcher()->requestCount();
estimatedBytesForPendingRequests = progressItemDefaultEstimatedLength * numPendingOrLoadingRequests;

...and then adding to it the estimated sizes we store on ProgressItems. This leads to both undercount and overcounting. The overcounting is because requestCount() will include resources that have received responses headers, which are therefore already in the set of ProgressItems. The undercounting is because requestCount() excludes requests that do not block the onload event, which will be included in ProgressItems when response headers are eventually received.

This may be rendered obsolete by some of the experiments in  Issue 513459 , but if not, we should probably fix those cases.