I do not understand the bug description. HTTP sub-resources are not always blocked in an HTTPS webpage. See w3c guidelines on optionally blockable subresources: https://www.w3.org/TR/mixed-content/#category-optionally-blockable

What Chrome does (with sample web pages):
https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content

From the perspective of page loads, it's hard to determine if *some* part of the page will use DRP for some request at some point. What I am trying to capture is if there is an area where DRP slows down the user, it would be good to know. This is pretty low priority, but it is hard to understand what exactly a DRP page load is.

Key things to consider:
* Main resource is fetched through DRP
* Main resource fetched a redirect through DRP
* Sub resources are fetched through DRP
* Data Saver is enabled
* HTTP vs HTTPS
* Main resource was fetched through DRP originally, but was fetched from cache this time

Right now, we only capture the cases where DRP was used for the main request (not cached). We used to capture redirects as well. I wanted to create a histogram to capture those redirects separately to see if those were slower than holdback because it is an area that DRP might hinder certain users (assuming mixed content is somewhat uncommon).