Base64图片不阻塞DOM树构建，但严重拖慢主线程解码与渲染；100张20KB Base64 PNG可致单帧解码超30ms，叠加深层DOM触发强制同步布局，突破16ms帧率底线。
Base64图片不拖慢DOM树构建，但会让Tree Construction阶段变卡
DOM树构建（Tree Construction）本身不执行解码，只把src="data:image/png;base64,..."当字符串存进<img>节点属性。所以解析完HTML Token后，DOM树能快速建完——document.readyState变成"interactive"的时间几乎不受影响。真正卡住的是后续：浏览器在构建渲染树前，必须对每个Data-URI做base64解码、像素解压、创建Image对象，这些全在主线程串行跑。
实测100张2KB base64 PNG，Tree Construction阶段额外耗时约1秒；若图片体积升至20KB，单图解码就占主线程15–30ms，100张叠加直接触发长任务（>50ms），导致Layout卡顿、滚动掉帧。
- Chrome DevTools → Performance 面板录制，过滤
DecodeImage和DecodeImageSync事件，能直观看到主线程被占满 - 用
performance.mark("start-img-load")+performance.measure()监控单张Data-URI从插入到img.complete === true的耗时，常达80–200ms - 注意：这个阶段卡顿不会报错，但
requestIdleCallback几乎拿不到空闲时间，setTimeout(fn, 0)延迟明显
为什么DOM深度深 + Data-URI多 = 双重惩罚
DOM树深度超6层时，样式计算和布局已开始线性变慢；此时再塞大量Data-URI图片，会放大主线程压力：每个<img>节点在Layout前都要完成解码，而深层DOM中，getComputedStyle或offsetWidth调用更容易触发强制同步Layout——解码+布局两个重活挤在同一帧里，极易突破16ms帧率底线。
比如一个div > div > div > article > section > .gallery > img结构，100个Data-URI图片加载时，Chrome会反复在递归匹配CSS选择器的同时，穿插执行100次解码，CPU使用率瞬间拉满。
立即学习“前端免费学习笔记（深入）”；
- 用
document.querySelectorAll("img[src^='data:']")查出所有Data-URI图片，再对每个调用node.closest("*").depth（需先用控制台脚本补全depth属性），确认是否集中在深度≥7的子树中 - 避免写
div div div img这类无意义嵌套选择器——它会让浏览器对每个img向上查3层，而Data-URI解码又占着主线程，响应更迟钝 - 深层DOM里用
fetchpriority="high"没用：Data-URI不走网络，优先级机制不生效
替代方案不是“换格式”，而是“绕过主线程”
把base64换成WebP或AVIF base64只能减体积，不能解决主线程解码瓶颈。真正有效的做法是让解码行为脱离渲染主流程：
- 用
createImageBitmap()配合OffscreenCanvas在Worker里解码，再传回主线程绘制（需Feature Policy支持cross-origin-isolated） - 服务端预转为
srcset多尺寸WebP，前端用loading="lazy"+decoding="async"，让浏览器自主调度解码时机 - 对图标类小图（≤1KB），保留Data-URI但改用
<svg>内联——无解码开销，CSS可直接控制颜色/尺寸 - 绝对不要在
<script type="application/json">里塞base64图片数据——Tokenizer要扫描整个JSON块找</script>闭合点，易回溯重试，拖慢Tokenization
容易被忽略的缓存与调试陷阱
Data-URI图片天生无法被HTTP缓存，但开发者常误以为“反正不走网络，快”。实际上每次刷新都要重新base64解码、创建Image对象、上传GPU纹理——这些操作比从内存缓存读一张JPEG还重。
更隐蔽的问题是调试：DevTools里右键Data-URI图片→“Open in new tab”会失败；用console.log(img.src)输出的base64字符串太长，可能触发控制台截断或卡死；想查某张图是否解码完成，img.naturalWidth在解码前是0，但img.width可能已被CSS设为固定值，造成误判。
- 用
img.addEventListener("load", handler)而非轮询naturalWidth，避免主线程空转 - 禁用浏览器扩展（尤其广告拦截、截图工具），某些插件会劫持
data:协议并同步处理，额外增加100ms+延迟 - CI环境跑Lighthouse时，Data-URI图片会让“Largest Contentful Paint”指标失真——它把解码后的像素区域当LCP候选，但解码延迟使LCP时间虚高
