HTML图标本身不拖慢页面，但加载方式、资源体积和渲染时机不当会卡首屏；favicon用<link rel="icon">几乎无性能代价，因其异步加载且不阻塞解析；内联SVG在小体积少数量时更快，否则应外链；字体图标存在FOIT等陷阱；Manifest图标不影响首屏。
HTML图标本身不直接拖慢页面，但加载方式、资源体积和渲染时机选错，会实实在在卡住首屏。
用 <link rel="icon"> 加载 favicon 为什么几乎没性能代价
浏览器对 favicon 有特殊处理：它不阻塞 HTML 解析，也不参与关键渲染路径（CRP）。即使服务器响应慢或返回 404，<link rel="icon"> 也只在 DOM 构建完成后异步发起请求。
- 务必用
rel="icon"，别写成rel="shortcut icon"—— 后者是 IE 时代遗留写法，现代浏览器虽兼容，但部分 CDN 或代理可能误判缓存策略 - href 值建议指向绝对路径（如
/favicon.ico），避免相对路径触发多次 base URL 推导，尤其在 SPA 路由下易出错 - 不要指望靠多个
<link rel="icon">实现“自动适配”——浏览器只取第一个有效项，后续的被忽略
<svg> 内联图标比 <img src="icon.svg"> 更快，但有个前提
内联 <svg> 确实省去一次 HTTP 请求，且可被 CSS 直接控制颜色/尺寸；但它会增大 HTML 文件体积，并延长 HTML 解析时间。是否更快，取决于 SVG 大小和使用密度。
- 单个图标小于 1 KB、且全页不超过 5 个时，内联更优；否则优先外链 SVG 文件，利用 HTTP 缓存
- 避免把整个 SVG Sprite（含几十个图标）一次性内联进 HTML —— 这会让首字节时间（TTFB）和解析耗时双双升高
- 如果用
<use xlink:href>引用外链 SVG，注意 Firefox 和 Safari 对跨域 SVG 的xlink:href支持不稳定，推荐改用<svg><use href="..."/></svg>（现代语法）
字体图标（如 Font Awesome）的隐藏性能陷阱
字体图标看似轻量，但实际加载链路长：字体文件下载 → 字体解析 → 字符映射 → 渲染触发。其中任意一环卡住，图标就空白或闪烁。
立即学习“前端免费学习笔记（深入）”；
- 未设置
font-display: swap时，Chrome 会等待字体加载完成才渲染文字+图标，造成 FOIT（Flash of Invisible Text） - 用 Unicode 字符（如
\f007）调用图标，需确保字体文件完整包含该 glyph；缺失时回退到系统字体，显示为方块或问号 - 相比 SVG，字体图标无法单独控制每个图标的 fill 颜色（除非用 CSS 变量 hack），也不支持描边、渐变等矢量特性
Web App Manifest 中的 icons 属性只影响 PWA 安装，不影响网页首屏
manifest.json 里的 icons 数组（如 [{"src": "/icon-192.png", "sizes": "192x192"}]）仅在用户点击「添加到主屏幕」后被读取，浏览器不会提前下载这些图片。
- 别把它当成预加载图标资源的手段——它和首屏渲染完全无关
- 若想让关键图标（如 logo）早加载，仍需用
<link rel="preload" as="image" href="/logo.svg">显式声明 - manifest 中的 icon 尺寸必须真实存在且可访问，否则 PWA 安装失败静默发生，开发者很难排查
真正容易被忽略的是：图标资源的 MIME 类型和服务器配置。比如返回 text/plain 的 SVG 文件，某些浏览器会拒绝渲染；又比如 Nginx 没配 application/font-woff2，字体图标就加载失败。这些底层细节，比选哪种图标方案更决定成败。
