Request priority is partially determined by individual web browser’s priority configuration so it may differ between Chrome, Firefox, Opera, Safari, Edge browsers. You can manipulate request priority in a few ways
Browser priority hints for preload, preconnect, prefetch, and HTTP/2 server push will all impact request priority - though the extent of impact is browser dependent. Examples of such resource prioritization can be see at https://developers.google.com/web/fundamentals/performance/resource-prioritization and https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf
Other way to manipulate request priority is if you are using Cloudflare Pro or higher paid plans and have Enhanced HTTP/2 Priority enabled - you won’t have control over that in a sense Cloudflare changes those request priorities to be optimal for most cases. But it may not be optimal for all cases - which leads onto the 3rd method below.
Third way is to use Cloudflare Workers and alter the priority of the requests via
cf-priority header as outlined at https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
Customizing Prioritization with Workers
Faster-by-default is great but where things get really interesting is that the ability to configure the prioritization is also exposed to Cloudflare Workers so sites can override the default prioritization for resources or implement their own complete prioritization schemes.
If a Worker adds a “cf-priority” header to the response, Cloudflare edge servers will use the specified priority and concurrency for that response. The format of the header is
<priority>/<concurrency> so something like
response.headers.set('cf-priority', “30/0”); would set the priority to 30 with a concurrency of 0 for the given response. Similarly, “30/1” would set concurrency to 1 and “30/n” would set concurrency to n.
With this level of flexibility a site can tweak resource prioritization to meet their needs. Boosting the priority of some critical async scripts for example or increasing the priority of hero images before the browser has identified that they are in the viewport.
To help inform any prioritization decisions, the Workers runtime also exposes the browser-requested prioritization information in the request object passed in to the Worker’s fetch event listener (request.cf.requestPriority). The incoming requested priority is a semicolon-delimited list of attributes that looks something like this: “weight=192;exclusive=0;group=3;group-weight=127”.
weight : The browser-requested weight for the HTTP/2 prioritization.
exclusive : The browser-requested HTTP/2 exclusive flag (1 for Chromium-based browsers, 0 for others).
group : HTTP/2 stream ID for the request group (only non-zero for Firefox).
group-weight : HTTP/2 weight for the request group (only non-zero for Firefox).
If you know what you’re doing for HTTP/2 priority headers you can tailor your request priority for your specific web applications needs. I’ve done this to tweak my forum’s Google Core Vital Web metrics to lower the priority of requests which aren’t important to the critical render path of a page (forum thread) being loaded and to increase priority of requests which are more important to the critical render path for above fold elements.