请求优先级v2
简介
在2022年6.27，优先级发生了一些变化。修改后的优先级变得更加简单直观。
本文主要是对这篇文档的翻译。
Resource Fetch Prioritization and Scheduling in Chromium
优先级表
Chrome 分两个阶段加载资源。Tight mode 是初始阶段，限制加载优先级较低的资源，直到body添加到document（基本上是在执行head中的所有阻塞script之后）。在Tight mode下，只有当发现in-flight中的请求少于2个时，才会加载低优先级资源。
每种资源类型都有默认优先级，priority hints spec为开发人员提供了一种“ fetchPriority”属性，可以设置“hight”，“low”，"auto"（默认）影响的优先级的方法
同一优先级的资源提取按发现顺序设置优先级。
◉ : fetchpriority=”auto”
⬆ : fetchpriority=”high”
⬇ : fetchpriority=”low”
* 使用as的preload资源或设置type属性的fetch请求
** early 第一张非预加载(non-preloaded)图片请求之前 late 第一张非预加载图片请求之后
*** 媒体类型不匹配的CSS不会被预加载扫描器(preload scanner)加载，
只有在主解析器到达时才进行处理，这通常意味着它将很晚获取，并且具有“late”优先级。
译注：
- 不是很明白这里用
*意思，猜测是指引读者看下面的备注，*的数量并没有意义- 媒体类型不匹配, 即你加载的是css文件但是link标签设置的type是错误的
- 预加载扫描器，参考：Speculative parsing - MDN Web Docs Glossary: Definitions of Web-related terms | MDN
Priority Changes
图像始终以低优先级开始。如果在布局时发现图像位于视口内，则优先级将提升为“high”，尽管这在加载过程中可能很晚，并且如果请求已发送，动态更改优先级可能不会产生任何影响。
Late-body Script以中等优先级开始，但如果 HTML 解析器解析到它们并被阻止，则优先级将提升为“High”。
Devtools显示给定资源在完成加载时用于该资源的最终优先级。如果图像从低优先级开始并提升到高优先级，则即使它最终被延迟，它也会显示为高优先级。
Net Stack Priority Names
Chrome网络堆栈使用与其他Chrome相同的5个优先级，但名称略有不同，相互偏移。一般情况只有你在在处理Chrome代码本身或查看NetLog时会看到网络堆栈版的名称。Net 优先级名称通常完全大写，这使其更容易区分。完整映射为：
