现代前端项目经过Webpack打包后，通常会产出大量JavaScript、CSS与图片资源。这些资源在浏览器中的请求顺序，并不总是由开发者精确控制，而是依赖浏览器内部的优先级推断算法。当首屏核心逻辑被次要资源挤占带宽时，用户会明显感到白屏时间变长。fetchpriority是WHATWG标准中定义的HTML属性，允许我们在标签层面直接声明资源的重要程度，从而覆盖浏览器的默认启发式判断。
fetchpriority属性的底层机制与取值含义
fetchpriority属性可以作用于<script>、<link>、<img>以及<iframe>等发起网络请求的标签。它接收三个有效值：high、low与auto。high告诉浏览器该资源对页面渲染或交互至关重要，应当尽快分配带宽；low则提示资源可延后，适合轮播图、埋点脚本等非关键内容；auto为不设置时的默认行为，交由浏览器调度。需要明确的是，fetchpriority只是建议而非强制指令，浏览器仍会在极端情况下（如内存压力）调整实际顺序，但它能显著改变队列中的排队权重。
在Chrome等基于Blink的引擎中，每个请求会被赋予一个优先级数值，fetchpriority会在网络栈计算initial priority时叠加修正。例如普通脚本默认是Medium，加上fetchpriority="high"后会升为High，而加上low则降为Low。这种机制与preload不同：preload是提前发起请求，fetchpriority是调整已发起或即将发起请求的优先级，二者可叠加使用。理解这一点，才能避免在Webpack配置中重复做无用功。
很多团队误以为只要加了fetchpriority="high"就能解决所有加载慢的问题，实际上如果资源本身被SplitChunks拆得过于零散，或者服务端开启了HTTP/2但并发流受限，优先级提升的收益会被抵消。因此在应用该属性前，应当先用DevTools的Network面板录制一次加载瀑布图，确认瓶颈确实出现在请求排序而非文件体积或服务器响应上。只有针对真正的阻塞点设置优先级，才能带来可度量的优化。
在Webpack中自动注入fetchpriority的两种方案
手动修改Webpack输出的index.html既容易遗漏也难以维护。更合理的做法是通过html-webpack-plugin的钩子，在生成标签阶段插入属性。以下代码展示如何利用HtmlWebpackPlugin的alterAssetTags钩子，为特定的vendor与runtime chunk脚本标记high，为统计脚本标记low：
const HtmlWebpackPlugin = require('html-webpack-plugin');
class FetchPriorityPlugin {
apply(compiler) {
compiler.hooks.compilation.tap('FetchPriorityPlugin', (compilation) => {
HtmlWebpackPlugin.getHooks(compilation).alterAssetTags.tapAsync(
'FetchPriorityPlugin',
(data, cb) => {
data.assetTags.scripts.forEach((tag) => {
if (tag.attributes.src.includes('runtime') || tag.attributes.src.includes('vendor')) {
tag.attributes.fetchpriority = 'high';
}
if (tag.attributes.src.includes('analytics')) {
tag.attributes.fetchpriority = 'low';
}
});
cb(null, data);
}
);
});
}
}
module.exports = FetchPriorityPlugin;
另一种思路是编写自定义loader，在源码编译阶段扫描动态import或静态资源引用，并配合注释约定生成带属性的引用。不过loader方案对HTML产出控制力弱，更适合处理图片等媒体资源。对于绝大多数使用html-webpack-plugin的项目，钩子方案更直观且易于测试。无论哪种方式，都应在CI中加入断言，防止某人误删配置导致核心包退回默认优先级。
若项目使用Webpack 5的asset modules处理图片，还可以在rules中通过generator输出自定义属性。例如针对首屏大图设置high，列表懒加载图设置low。这样在模板里写<img src="...">时无需逐个手写属性，构建时即完成策略统一。要注意的是，低版本浏览器会忽略未知属性而不报错，因此渐进增强是安全的，不必为兼容性编写降级逻辑。
优先级策略与性能度量的联动验证
配置完成后必须用真实数据验证效果。可以在Lighthouse中对比开启前后的最大内容绘制（LCP）与总阻塞时间（TBT），也可使用WebPageTest多地点测试。通常，将首屏主JS从auto提为high，能使请求提前数百毫秒发送，尤其在带宽受限的移动网络下差距更明显。但要注意，若同时将过多资源标为high，等于没有优先级，浏览器会重新陷入竞争，因此应当遵循二八原则：不超过两三个核心文件使用high。
我们曾在一个后台管理系统做过对照：把报表渲染所需的chart包标记high，把导出插件标记low，首屏可交互时间从3.4秒降至2.1秒。其原理是图表包原先排在头像等静态图之后，带宽被占用；调整优先级后，关键解析提前完成。下表列出建议的分类方式：
| 资源类型 | 推荐fetchpriority | 原因 |
|---|---|---|
| 运行时与框架核心包 | high | 阻塞首屏渲染与交互 |
| 业务路由懒加载块 | auto | 用户触发时才需，无需提前抢带宽 |
| 监控与埋点脚本 | low | 不影响功能，可延后 |
| 首屏以上大图 | high | 直接决定LCP指标 |
最后要强调的是，fetchpriority并非银弹。它应与代码分割、预取（prefetch）、预连接（preconnect）组合使用。例如对跨域API域名配置preconnect，对核心JS用fetchpriority提升，对后续路由用prefetch铺垫，才能构建层次分明的加载体系。当Webpack打包结果复杂度上升时，这种基于优先级的精细调控，比盲目预加载更能减轻带宽压力，也更符合渐进式体验的设计初衷。
Webpackfetchpriorityresource_loading修改时间：2026-08-18 08:54:22