ResourceFetcher::ComputeLoadPriority does the following:
 - Computes a reasonable priority for a request, called `priority`, given some information
 - Returns the max of:
   - ResourceRequest's original priority (lowest, unless manually set elsewhere)
   - ...and whatever any currently-running experiments say the generated `priority` should be, after applying the experiment's parameters (if necessary)

A (the only?) Blink loading experiment that currently gets triggered via ResourceFetcher::ComputeLoadPriority, is the Low Priority Iframes experiment (+tbansal@). From what I can tell, this experiment smooshes all request priorities to either kLow or kLowest if the request was made from a child frame (and the experiment is enabled of course).

As a result of the current architecture, ResourceRequests that have their priority set to things like ~kHigh before reaching ResourceFetcher::ComputeLoadPriority, like module scripts [1], never actually get affected by experiments that down-prioritize eligible requests.

I think it is unlikely that we want all module scripts, and potentially future requests that have their priority manually set for any reason, to be exempt from low-priority experiments, but I'm not sure? (If this was intended, feel free to close this!). This "issue" can be seen in practice by visiting [2] and looking at the network pane in the DevTools. Imagine if an advertiser wanted to get around the low-priority iframes experiment. They could just fetch their scripts as "type=module", and it seems that the script will be the only high-priority resource from the frame, thus beating the low-priority-iframes experiment.

Another issue with this current architecture is very related to 872776. Imagine we make a low-priority request that goes through a Service Worker's FetchEvent (that uses fetch() to request the resource). Blink will preserve the priority from the original request, but in ComputeLoadPriority, since we're fetching from the fetch request context, we'll "upgrade" the priority to kHigh. Instead, it would be nice if we could skip "ComputeLoadPriority" altogether here since we have a preserved priority we'd like to use, and the apply the experiment separately for the last say.

I propose we change the current arch such that the ComputeLoadPriority-logic and the applying-experiment-to-priority logic are decoupled. We could skip calling ComputeLoadPriority for ResourceRequest's that have already had their priority manually set elsewhere (some flag?), and still _always_ run the experiment logic, to give any active experiments the final say in priority. Thoughts?


[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/modulescript/module_script_loader.cc?sq=package:chromium&g=0&l=186

[2]: https://swift-basil.glitch.me/