我那个工具站的上传框只收 JPG、PNG 和 WebP，iPhone 用户直接传 HEIC 会被提示格式不支持。要不要补上 HEIC 我拖了很久。拖的原因很具体：Chrome 读不了 HEIC，想在浏览器里读就得多带一个解码器。它有多大？每个访客要替它付多少流量？这笔账我一直没算过。量体积时我用的是图映 ImgIng（https://imging.cn/）的 HEIC 读取，机器是 Apple M4 / 16 GB，内核是 Playwright 1.61.1 自带的 Chromium 149（headless）；样本是我用 sips 从合成图编出来的 HEIC，不是手机拍的照片。它先让浏览器原生读一次，读不了才弹出「加载解码器」按钮。这正好是我想抄的做法。
Chrome 能直接读 HEIC 吗
先确认到底要不要带解码器。我在三个内核上把原生的路子挨个试了：<img>、img.decode()、createImageBitmap 和 WebCodecs 的 ImageDecoder。Chromium 149 和 Firefox 151 构建全部失败。<img> 触发 error 事件；createImageBitmap 报 InvalidStateError；把 Blob 的 type 改成 image/heic 也没用。拿 image/heic 去问 ImageDecoder 支不支持时两家都答 false。同一个方法问 avif 却是 true。只有 Playwright 的 WebKit 26.5 构建（macOS）读得出来，它调的是系统自带的解码器。结论很直接。想在 Chrome 里读 HEIC 只能自己带解码器。
HEIC 解码器 WASM 有多大
点下「加载解码器」只多出两个 GET：一个是 2,107 字节的 heic.js，另一个是 libheif-bundle.mjs。bundle 解压后 1,461,926 字节，就是那个 1.46 MB。里面用 base64 内联了一段 1,034,305 字节的 WASM，二进制里能看到 libheif 1.19.8 和 libde265 的字样。它不再单独请求 .wasm 文件。gzip 之后两个文件的实际传输是 522,557 字节。约 510 KB。
1.46 MB 第一眼有点吓人。我那个站首页整页也没这么重。但我数了一遍才发现这笔钱不是每个访客都付：按需加载意味着只有真传了 HEIC 而且浏览器读不了的人才下载。WebKit 构建那一路原生读成功，全程没有下载任何解码文件。回访更省。响应头是 max-age=0 加 must-revalidate，刷新后两个文件各回一次 304，一共 1,095 字节。页面在 localStorage 里记下用过哪个解码器，下次传 HEIC 自动加载而不再弹按钮。它没用 Service Worker 也没写 Cache Storage。
这 510 KB 该放在页面哪一步加载
我按自己的站定了三条：首页不带这 510 KB；上传页也不预加载；只有上传框收到 .heic 并且原生解码失败时才去拉。没传 HEIC 的访客一个字节都不多付。吃亏的只有第一次在 Chrome 里传 HEIC 的人。他要多等一次下载。下载耗时我给不了数：同一个文件在这台机器上快慢差了好几倍，完全看当时的网络。
算完解码器我才发现真正吃带宽的是另一头。同一张 12MP 竖拍样本 HEIC 显示为 1.25 MB；前端转 PNG 后是 13.52 MB，约为 10.8 倍。转 JPG 80 在 Chromium 149 上是 662.2 KB。同一个质量 80 在 WebKit 26.5 构建上是 Chromium 的 2.66 倍。转成什么格式再上传，影响比解码器那 510 KB 大得多。我定了转 JPG。PNG 不考虑。HEIC 转 JPG 会不会变小要看图：这组合成样本是变小了，之前另一批用公开授权照片编出来的 HEIC 转 JPG（当时默认质量 88）反而大了 37% 到 61%。这不是规律。还有一块我没测：手机上下载加解码到底要多久。我手里只有这台 M4 的数。
你的站如果也在犹豫，先别把解码器塞进首屏。先在上传框里判断扩展名和原生解码结果，再决定拉不拉解码器。转出格式先选 JPG。然后拿你站上真实用户会传的那类照片比一次体积。