合并重复的和标签能直接降低解析开销，因每个标签都会触发资源发现与阻塞；应通过构建工具去重、SSR模板层缓存或手动检查源码来避免重复注入。

合并重复的 <script></script> 和 标签能直接降低解析开销

浏览器解析 HTML 时，每个 <script></script> 或 标签都会触发一次资源发现、加载调度和可能的阻塞行为。哪怕它们指向同一份文件，重复声明也会让解析器多走一遍流程，增加 DOM 构建时间。

常见错误现象包括：构建工具误配导致多次注入相同 polyfill；CMS 模板拼接时未去重；第三方插件各自插入自己的 <script src="lodash.js"></script>。

• 检查最终 HTML 源码，用 Ctrl+F 搜 <script src="&lt;/code"> &#25110; <code><link href=</script>，确认无重复路径
• Webpack/Vite 等构建工具中启用 optimization.splitChunks（Webpack）或 build.rollupOptions.output.manualChunks（Vite），避免公共依赖被多次打包进不同 chunk
• 服务端渲染（SSR）场景下，在模板层做去重逻辑，比如用 Set 缓存已注入的 src 值

嵌套过深时，用 display: contents 替代“合并”更安全

很多人想“合并相似标签”其实是为了解决视觉上冗余的包裹层，比如连续三层

。但直接删掉中间层可能破坏 CSS 选择器或 JS 查询逻辑——真正该做的是让这些容器不参与渲染流，而非物理合并。

display: contents 让元素自身不生成盒模型，子元素直接提升到父级渲染上下文中，DOM 结构不变，但布局层级被压平。

• 适用场景：React/Vue 组件返回多个根节点前的包装
  ；CSS Grid/Flex 子项外多余的语义无关容器
• 注意：display: contents 会从可访问性树中移除该节点，若它承载了 role 或 aria-* 属性，必须迁移或改用
• 不兼容 IE，但现代项目中可放心用于 Chrome/Firefox/Safari/Edge 105+

用语义化标签替代多层

不是“合并”，而是结构性精简

所谓“合并相似标签”，本质常是结构冗余。比如用五个

包裹五张卡片，不如直接让

或

成为卡片容器——这不是合并，是用单个语义标签承载原本需多个

模拟的含义。

DOM 节点数每减少一个，解析耗时、内存占用、CSS 选择器匹配成本都线性下降。实测显示，子节点超 50 个的

在低端 Android 设备上滚动帧率明显下降。



Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转

实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。

下载

• 替代
  ：全页唯一，且浏览器可据此跳过无关区域的样式计算
• 替代
  ：屏幕阅读器可直接识别导航区块，无需靠 class 名猜测
• 纯视觉分隔不用
  ，改用

  ---

  或 CSS border：它不产生新 DOM 节点

  HTML 压缩工具里的 collapseWhitespace 不等于合并标签

  像 html-minifier 的 collapseWhitespace: true 只处理空白字符，不会合并或删除任何标签。它可能把

  中的换行变成

  ，但两个标签依然独立存在。

  真正减少节点数，得靠人工或构建时逻辑判断：比如将多个空

  （仅含注释或空白）提前剔除；或在 SSR 层过滤掉值为空的动态片段。

  • 不要依赖压缩工具“自动合并”——它没这个能力
  • 对 CMS 输出或 Markdown 渲染结果，加一层 DOM 遍历清理：移除 node.children.length === 0 && node.textContent.trim() === '' 的空容器
  • element.normalize() 只合并相邻 Text 节点，对标签无效；别指望它帮你删

    最易被忽略的一点：标签合并的收益远小于结构重构。与其花时间写正则去“合并

    ”，不如把布局逻辑交给 display: grid，让父容器直接定义子项排列，自然消解中间层。