最近面了几个号称精通前端工程化的候选人，看着他们简历里大段大段的 Webpack 性能优化实战，我心情挺复杂的。🤷♂️
现在已经是 2026 年了，HTTP/3 早就成了基建标配。可是很多人脑子里的优化八股文，还停留在 2018 年 HTTP/1.1 和早期 HTTP/2 的时代。
他们在面试时背的流水：怎么配 SplitChunks，怎么做域名分片，怎么把小图片转 Base64，怎么拼雪碧图。说实话，听得我直皱眉头😖。
脱离了网络协议谈打包优化，全是在耍流氓。 在 HTTP/3（QUIC协议）普及，以及被 Vite 等打包工具加速淘汰的今天，你引以为傲的那些 Webpack 神级配置，有一半不仅没用，反而正在拖慢你的首屏速度。
今天我就直白点，扒一扒在 HTTP/3 时代，哪些老掉牙的优化经验该直接扔进垃圾桶。
打包成大 Chunk，你还在合并 Vendor 吗？
以前我们用 Webpack，最核心的诉求是什么？减少 HTTP 请求数。
因为 HTTP/1.1 有队头阻塞（Head-of-Line Blocking），浏览器对同一个域名还有 6 个并发连接的限制。所以我们要把 react、lodash 这些第三方库死死地打成一个 vendor.js，把业务代码打成 app.js。
但在 HTTP/3 面前，这种做法极其愚蠢😒。
HTTP/3 底层是基于 UDP 的 QUIC 协议。它不仅解决了 TCP 层面的队头阻塞，还把多路复用（Multiplexing）做到了极致。几百个并发请求在 QUIC 看来成本极低，通道之间互不干扰。
现在的反直觉真相是：细粒度的模块加载（Fine-grained Loading, 推荐好文章😁），远比打包成大块更高效。
如果你把 20 个依赖打成一个 2MB 的 vendor.js，只要其中一个依赖升级了小版本，整个 2MB 的缓存全部失效，用户得重新下载。
所以咱们得顺应 ESM 和当前主流的构建工具（比如 Vite/Rspack/Turbopack）的趋势，把依赖拆碎。按包名输出单文件，利用 HTTP/3 的高并发特性，让浏览器自己去精准命中强缓存。
域名分片?
我看到还有人的简历里写着：通过配置多个 CDN 域名（static1.domain.com, static2.domain.com, static3.domain.com）突破浏览器并发限制，提升加载速度。
这在 HTTP/1.1 时代是标答，但在 HTTP/3 时代，这是纯纯的愚蠢😖。
- 握手成本： HTTP/3 虽然支持 0-RTT，但建立一个新的 QUIC 连接，依然需要 DNS 解析和初始的握手计算。
- 拥塞窗口重置： QUIC 连接刚建立时，为了探测网络情况，发送窗口是比较小的（Slow Start）。如果你把资源散布在 4 个域名上，浏览器就要建立 4 个 QUIC 连接，每个连接都要经历一次缓慢的热身过程。
所以结合以上👆特点，把所有静态资源集中在一个域名下。这样不仅只发生一次 DNS 解析和握手，还能让这个唯一的 QUIC 连接迅速撑大拥塞窗口，后续的并发请求速度会快得飞起。连接复用率越高，HTTP/3 的优势才越大。
Base64 内联与雪碧图（CSS Sprites）：拿 CPU 算力换网络，亏本买卖
Webpack 时代，url-loader 的标配是：小于 8KB 的图片直接转 Base64 塞进 JS 或 CSS 里。前端甚至为了几个 icon 专门搞一套 webpack-spritesmith 自动化拼图。
为什么？还是为了省那几个可怜的 HTTP 请求。
但在 2026 年，这样做弊大于利：
解析成本太高： Base64 字符串的体积比原图大 30% 左右。更致命的是，浏览器解析巨型 JS/CSS 文件中的 Base64 非常消耗主线程 CPU。在低端移动设备上，直接导致长时间的 Long Task，页面会卡死。
而且雪碧图里只要改了一个 10x10 的小图标，整张大图的缓存直接作废😒。
别再折腾了，直接用 HTTP/3 并发请求原生的 WebP 或 AVIF 格式图片和算法优势。既省下了转码带来的体积膨胀，又释放了主线程的解析压力，还能做到完美的单文件缓存。
Tree-shaking 依然很重要，但重心变了
有人可能会杠：既然 HTTP/3 并发这么牛，那我是不是不需要构建工具了，全裸奔上 ESM？
当然不是。网络协议再快，也救不了你几兆的无用代码。浏览器下载完 JS 是要 Parsing 和 Compiling 的，这段 CPU 执行时间 HTTP/3 帮不了你。
但在 HTTP/3 时代，工程化的重心已经从如何把文件拼得更好看（Bundling） ，彻底转移到了如何精准剔除废代码（Dead Code Elimination）和极致的按需加载。
这也就是为什么基于 Rust 的无打包/轻打包工具（No-bundle / Bundleless）在近几年彻底取代 Webpack 成为了主流。因为它们顺应了底层网络协议的演进方向👍。
技术的演进是自下而上的。从 TCP 到 UDP，从 HTTP/1.1 到 HTTP/3，基础设施变了，上层建筑就得跟着翻修。
作为 9 年经验的老兵，我给还在死磕 Webpack 复杂配置的同行一句忠告😊：
停下来，打开 Chrome 的 Network 面板，看看 Protocol 那一栏是不是已经全是 h3 了。如果是，请把你脑子里那些为了减少请求数而做的扭曲 Hack 手段，干脆利落地删掉。
你的前端架构应该顺应浏览器的天性，而不是去填补十年前的网络缺陷。
祝大家面试好运🙌🙌🙌
