Base64 图片内联会显著拖慢 CSSOM 构建，因其强制浏览器在解析 CSS 阶段同步解码、校验并分配内存，即使图片未首屏显示；gzip 仅缓解体积不减少解析开销，实测可使 CSS 解析时间从 8ms 增至 42ms。
Base64 字符串会拖慢 CSS 文件解析速度
因为浏览器必须等整个 style.css（含大量 Base64 内容）下载并解析完，才能构建出完整的 CSSOM；而 Base64 图片直接膨胀文件体积约 33%，导致下载和解析耗时明显上升。
CSSOM 构建被阻塞是关键瓶颈
浏览器渲染页面前需同时完成 DOM 和 CSSOM 构建。只要 background-image: url(data:image/...) 这类声明存在，CSS 解析器就必须把整段 Base64 字符串当作有效值读入内存、校验格式、等待解码准备就绪——哪怕这张图根本没在首屏显示。
- Base64 不是“懒加载”，它在 CSS 解析阶段就被强制处理
- 大段 Base64 会显著拉长
CSSOM construction time，Chrome DevTools 的 “Coverage” 或 “Performance” 面板能直观看到解析耗时突增 - 即使图片被注释掉（
/* background-image: url(...) */），只要语法合法，部分浏览器仍会预解析其内容
gzip 压缩效果有限，且不解决解析开销
虽然文本类 Base64 可被 gzip 压缩，但压缩率远低于原始二进制图片（PNG/JPEG 本身已是高压缩格式）。更重要的是：gzip 只缓解传输体积，不减少浏览器解析、base64-decode、内存分配这些运行时开销。
- 一个 2KB 的 PNG 转成 Base64 后约 2.7KB，gzip 后可能剩 2.2KB —— 仍比原图大，且解压 + decode 耗 CPU
- 解析过程中，V8 引擎需将 Base64 字符串逐字符转换为 Uint8Array，这对低端设备尤为敏感
- 若 CSS 中混用多种格式（SVG、PNG、GIF 的 Base64），还可能触发多次不同解码路径，进一步放大开销
真正影响首屏时间的是 CRP 中的 CSS 关键路径
很多人误以为“只是多了一段字符串”，但实际它卡在了关键渲染路径最前端：<link rel="stylesheet"> → 下载 CSS → 解析 CSS（含 Base64）→ 构建 CSSOM → 合并 render tree → layout/paint。Base64 就卡在第二步和第三步。
立即学习“前端免费学习笔记（深入）”；
- 实测：10 个 1KB 图标的 Base64 内联，可使 50KB 的
main.css解析时间从 8ms 增至 42ms（中端安卓机） - 若该 CSS 是
<head>中首个<link>，延迟会直接传导到整个页面首次绘制（FP/FCP） - 用
@import或动态insertRule加载含 Base64 的样式，同样无法绕过 CSSOM 阻塞
真正容易被忽略的是：Base64 图片不是“静态资源”，它是 CSS 解析器必须同步处理的内联数据字面量。哪怕你只用一次，它也全程参与关键路径；而外链图片是异步加载、不影响 CSSOM 构建的。
