Data URL：把图片嵌入代码

Data URL（也叫Data URI）允许将小文件直接嵌入到HTML、CSS或JavaScript中，格式为data:[mediatype][;base64],data。对于图片，最常见的格式是data:image/png;base64,iVBORw0KGgo...。这种方式避免了额外的HTTP请求，在某些场景下可以提升页面加载性能。但Data URL并不是银弹，它有一系列性能权衡需要考虑。

Data URL的历史可以追溯到1998年的RFC 2397，但直到2009年左右才被主流浏览器广泛支持。如今，CSS中的背景图片、HTML中的img标签、SVG中的foreignObject等场景都可以使用Data URL。

Base64编码的体积代价

Base64编码将每3个字节转换为4个字符，因此编码后的数据体积会增加约33%。一张10KB的PNG图片，Base64编码后约为13.3KB。但实际影响更大——因为Base64文本是嵌入在HTML/CSS中的，它会增加主文档的体积，而主文档的解析和渲染会阻塞页面显示。

更关键的是，Base64图片无法被浏览器独立缓存。普通图片文件可以被浏览器缓存，多个页面共享；而Base64图片随HTML一起缓存，每次页面加载都要重新传输和解码。对于频繁更新的页面，这意味着每次更新HTML内容，所有内联图片都需要重新下载。

何时使用Base64内联？

Base64内联适合以下场景：

小图标（10KB以内）：体积增加有限，但省去一个HTTP请求，在HTTP/1.1环境下收益明显
CSS Sprite替代方案：当图标分散在不同位置，不方便合并为Sprite时
邮件模板：邮件客户端不支持外部资源引用，Base64是内联图片的可行方案
单文件组件：需要将所有资源打包在一个HTML文件中的场景（如邮件、离线页面、嵌入式组件）
SVG优化：小型SVG可以转为Data URL直接嵌入CSS，避免额外请求

HTTP/2和HTTP/3的多路复用特性大大减少了请求开销，因此在HTTP/2环境下，Base64内联的收益更低，阈值应该更保守（建议5KB以内）。

何时不应该使用Base64？

以下场景应避免使用Base64内联：大图片（超过10KB）会增加主文档体积，阻塞渲染；频繁变化的图片会导致缓存失效，每次都需要重新传输；需要JavaScript懒加载的图片——Base64无法实现延迟加载；需要浏览器图片优化（如WebP/AVIF格式协商、响应式图片srcset）的场景；CDN优化的图片——CDN可以对独立图片文件做更好的缓存和分发。

Base64图片的CSS技巧

在CSS中使用Base64图片时，有一些实用技巧：使用MIME类型指定最优格式（如image/webp而非image/png，当浏览器支持时）；将重复使用的图标定义为CSS自定义属性（如--icon-close: url(data:image/svg+xml;base64,...)），避免重复编码；使用媒体查询为不同分辨率提供不同图片；SVG优先——对于矢量图标，使用SVG的Data URL比PNG的Data URL体积更小且清晰度更好。

性能对比实测

以一个包含20个小图标（每个2KB）的页面为例：使用独立图片文件，在HTTP/1.1下需要21个请求（1个HTML + 20个图片），总传输约42KB，加载时间约1.2秒；在HTTP/2下需要21个流，总传输约42KB，加载时间约0.5秒。使用Base64内联，只需1个请求，但HTML体积增加约16KB（20×2×1.33），总传输约58KB，加载时间约0.6秒。结论：在HTTP/2环境下，Base64内联的收益非常有限，甚至可能因为体积增加而更慢。

工具推荐

使用我们的在线图片Base64工具，支持图片转Base64和Base64转图片，支持PNG/JPG/SVG/WebP等格式，显示编码前后的体积对比，帮助你做出合理的内联决策。