内联SVG会显著增大HTML体积并拖慢DOM解析，因其是嵌入的XML文本需逐字解析，超30KB时FCP平均延迟180ms以上；应使用svgo压缩、避免复杂嵌套、关键图标才内联，非首屏图标用img或svg sprite。
内联SVG会显著增大HTML体积，且直接拖慢DOM解析
内联SVG不是“加个标签就完事”，它是真实嵌入的XML文本，浏览器必须逐字解析。一段含15个<path>的图标，压缩后仍可能超1KB；10个同类图标塞进首屏HTML，光SVG代码就增加10–20KB——这不只是带宽问题，更是解析阻塞。
HTML解析是同步单线程过程，遇到大段SVG文本时，DOMContentLoaded触发时间会明显延后。实测在低端安卓机上，单页内联SVG总码量超30KB，FCP（首次内容绘制）平均延迟180ms以上。
- 用
curl -I查响应头Content-Length，HTML体超15KB时，优先检查SVG是否被无节制内联 -
svgo可自动移除冗余id、空格、注释，压损率40%–60%，但别手动删viewBox——它一丢，缩放就全乱 - 避免在
<header>或<nav>里塞复杂图表级SVG；导航图标够用就行，地图、统计图走<img src="map.svg">或懒加载
img引入SVG不增加HTML体积，但带来额外HTTP请求与MIME风险
<img src="icon.svg">把SVG当二进制资源加载，HTML本身几乎不增重，但每个<img>都是一次独立HTTP请求。HTTP/1.1下10个图标=10次TCP握手+请求头开销，白屏感比内联更隐蔽。
更麻烦的是本地双击打开HTML文件时，<img src="x.svg">常为空白——因为没HTTP服务，服务器没返回image/svg+xml MIME类型，浏览器直接拒解析。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段务必用
live-server或http-server起本地服务，别双击打开HTML文件测SVG图标 - CDN或静态托管平台（如Vercel、Netlify）默认配好SVG MIME，但自建Nginx需显式加
types { image/svg+xml svg; } - 简单装饰图标优先用
<img loading="lazy">，比内联更可控；关键交互图标（如开关、状态指示器）才考虑内联
SVG Sprite和<use>引用能平衡体积与复用性
把多个图标合并成一个SVG文件，用<symbol>定义，再用<use href="#icon-home">引用，既避免重复代码膨胀HTML，又保留DOM可操作性——<use>生成的实例仍是真实DOM节点，支持CSS变色、JS事件绑定。
但注意旧版Safari（≤15.6）对跨文件<use href="sprite.svg#id">支持极不稳定，必须内联Sprite文件或降级为<img>。
- Sprite SVG文件本身要精简：
svgo --plugins=removeTitle,removeDesc去掉无用元信息 - 引用时
href值必须带#前缀，写成href="sprite.svg#home"无效，得是href="#home"（前提是Sprite已内联） - 动态插入
<use>时，确保目标<symbol>已存在于DOM中，否则渲染为空——别在document.write()里拼SVG字符串
内联SVG嵌套过深会加剧DOM构建压力
SVG本身已是嵌套结构，<g>套<g>再套<path>很常见。若整个页面平均DOM嵌套深度已超6层，再往里塞多层SVG，移动端WebKit解析速度会断崖式下降。
Chrome DevTools里右键任意SVG子元素 → Show DOM properties → 看depth值，超过8就要警惕。这不是理论值，实测深度9的SVG组在低端机上Layout耗时翻倍。
- 用
<g transform="translate(10,20)">替代多层<g>嵌套定位 - 删掉纯装饰性
<g>容器，把fill、stroke直接写到<path>上，减少节点数 - SSR/静态生成场景下，预渲染出的HTML若含大量
<svg><g><g><g><path>，优先用transform扁平化结构
<img>时硬内联，该复用时每个都手写一遍<path>。体积和解析速度从来不是非此即彼的选择，而是根据是否需要操作内部结构、是否处于首屏、是否运行在低端设备上来做取舍。 
