标签本身性能开销极小，真正影响首屏速度的是不当CSS样式、大规模无节制渲染及客户端动态插入等误用行为。
标签本身几乎不影响页面加载速度，它只是语义化容器，不触发重排、不加载资源、不执行脚本。真正拖慢首屏的，往往是开发者误用它配合不当样式、或在大量文本中无节制渲染。
为什么
HTML5 的 是内联语义标签，浏览器解析时仅建立一个轻量 DOM 节点，不附带默认样式（除个别 UA 样式如黄色背景），也不触发 layout 或 paint 阶段的额外计算。
- 对比
：DOM 节点数量、渲染路径完全一致，差异仅在语义和默认样式 - 不会引起回流（reflow）——它不改变盒模型尺寸、不影响父容器布局
- 首次绘制（FP）和首次内容绘制（FCP）不受其存在与否影响，除非你给它加了
box-shadow、filter或动画
哪些写法会让
问题不出在标签，而出在配套 CSS 和使用规模：
- 给
加background: linear-gradient(...)或backdrop-filter: blur(2px)：强制开启层合成（layer promotion），增加 GPU 内存占用，尤其在滚动区域密集出现时掉帧 - 在 10,000+ 行搜索结果中为每个匹配词包裹
（例如全文高亮插件未做虚拟滚动）：DOM 节点爆炸式增长，导致内存飙升、V8 垃圾回收卡顿 - 用 JavaScript 动态批量插入
且未使用DocumentFragment：频繁触发重排，实测在低端 Android 设备上 500 次插入可造成 >100ms 阻塞 - 配合
transition: background-color .3s并监听 hover：每次悬停都触发复合层重建，尤其在列表项密集时明显
实测数据参考（Chrome 125，MacBook Pro M2）
对含 2000 个 的 50KB HTML 文档进行 Lighthouse 测试：
立即学习“前端免费学习笔记（深入）”；
- 仅用默认样式（
background-color: yellow）：FCP = 320ms，内存占用 +1.2MB - 加
box-shadow: 0 0 4px rgba(0,0,0,0.3)：FCP 不变，但长列表滚动 FPS 从 60→42 - 加
filter: drop-shadow(0 0 2px #ff0)：FCP 延迟至 380ms（GPU 层初始化耗时），内存 +3.7MB - 若改用
class="mark"+ 相同 CSS：性能曲线与原生完全重合 —— 证实瓶颈在样式，不在标签名
真正要盯住的不是该不该用 ，而是它是否被塞进了不该有的视觉效果、是否在不该渲染的地方批量生成、以及是否在 SSR/SSG 中把高亮逻辑错误地推迟到客户端执行。
