Just chatted offline, given the request is mostly same as the navigation request itself (but only with one request header), so this should likely be just fine as throttling for the navigation request itself is already applied. One minor gotcha is that the loader for nav-preload might start loading things before the navigation request's response is to be checked by the throttles. I believe this wouldn't be a huge problem as such response will be eventually caught by the throttle for the navigation itself anyways.

I'm not sure about this. It looks like the throttles want to do processing before the request goes to network. I think this is at least causing  issue 873061 , and possibly others. E.g., GoogleUrlLoaderThrottle is adding headers to YouTube requests for "restrictions", or SafeSearch query parameters to Google Search. It seems nav preload would bypass these since the only request that goes to network is nav preload.

Talked offline with Kinuko: we think we need to add throttling to navigation preload in the s13nsw/networkservice path similar to SignedExchangeCertFetcher. 

As another issue, it looks like MIME sniffing also doesn't get applied to the nav preload response which might be needed. Filed issue 873558.

After looking a bit more, we probably don't want to apply throttles to the nav preload request, because they can mutate the request and it's important for nav preload to be the same request as the fetch event. Instead, throttling should apply before SW interception, so nav preload can use the post-throttled request. I'm working on that at  issue 873575 .

I'll open a new issue for MIME sniffing.