使用webpack loaders有哪些优势？处理图片等资源的实际价值是什么？

我正在学习webpack，因为同时在学习Angular，了解到该框架使用了webpack。另外我也了解到webpack对非Angular应用也能起到性能优化的作用。

我做了一个仅展示单张图片的简单测试
index.html

<img id="imagen">
<script type="module" src="./script.js"></script>

为了学习loaders的工作原理，我分别做了使用loader和不使用loader的两组测试。
未使用loader的script.js

let myImagen=document.getElementById("imagen");

myImagen.src='./img/ball.jpg';

以下是将代码打包为main.js后的性能表现：

此时有1个main.js的请求和1个图片请求。

之后我使用file-loader进行测试
使用file-loader的script.js

import imagen from './img/ball.jpg';

let myImagen=document.getElementById("imagen");

myImagen.src=imagen;

得到的性能表现如下，请求数量和之前完全一致（仅图片名称被loader修改）：

我的疑问是：除了使用loader时会自动将文件输出到dist文件夹之外，它还有什么其他优势？测试中图片没有被压缩，请求数量没有减少，也没有获得更好的性能表现（我原本以为loader会把图片打包进main.js里）。
所以我不清楚费劲配置这个的实际意义是什么。
我之前查过相关问题，但采纳的答案完全没有解决我的疑惑。或许CSS场景下情况不同（我后续会测试），可以把CSS打包进JS中减少请求数，但对于图片这类资源，我完全看不到使用loader的优势。

你在简单测试中看不到优势，是因为测试场景和真实生产项目的复杂度差距很大，file-loader（webpack5已经内置了资源模块替代三方loader的功能）的核心价值主要体现在以下几个方面：

• 自动路径适配：手写的相对路径是基于源码目录的，当你调整打包后dist的目录结构、或者把静态资源部署到CDN上时，手写路径会直接出现404问题。loader会根据你配置的公共路径（publicPath）自动生成正确的资源访问路径，不需要手动修改所有资源引用代码。
• 内容哈希缓存优化：你测试中看到的文件名变化，其实是loader默认给文件加了内容哈希后缀，只要图片内容不变，哈希值就不会变，线上用户的浏览器会长期缓存该图片，不需要重复请求；只有当图片内容更新时，哈希值才会变化，强制用户拉取最新资源，完美解决缓存更新和资源复用的平衡问题。如果手写固定路径，要么缓存无法更新，要么需要手动给所有资源加版本号，维护成本极高。
• 支持自动化资源处理：你可以搭配其他loader实现全自动化的图片处理，比如自动压缩图片体积、自动转成webp/avif等压缩率更高的格式、自动适配不同分辨率的设备，不需要手动一张张处理图片资源。你测试中没有看到压缩效果，是因为没有配置对应的处理loader，不是loader本身不支持该能力。
• 灵活的内联策略：你预期的「把图片打包进main.js减少请求」的能力是完全支持的，可以自行配置大小阈值，小于阈值的小图片会自动转成base64字符串嵌入到JS/CSS中，减少请求数；大于阈值的大图片还是单独输出文件走缓存，兼顾加载速度和缓存效率。你测试的图片体积超过了默认阈值，所以没有自动内联。
• 统一依赖管理：不管是JS中引用图片、CSS中引用背景图、还是前端框架组件中引用静态资源，都可以用统一的import语法，webpack会自动梳理所有资源的依赖关系，打包时只会把用到的资源输出到dist目录，不会出现漏发、错发资源的问题，手写路径很容易出现开发环境正常、部署后资源缺失的低级错误。

内容的提问来源于stack exchange，提问作者user6791921