语义化HTML是性能优化的前提，缺失清晰结构会使preload、content-visibility等策略失效；main必须唯一且为顶层容器，嵌套section需配标题，DOM深度超4层会拖慢首屏渲染。

语义化 HTML 本身不直接提速，但它是所有关键性能优化落地的前提——没有清晰结构，preload、content-visibility、关键 CSS 提取、SSR 注水跳过等策略都会失效或误判。

为什么 <main></main> 必须且只能出现一次

浏览器和 SSR 工具依赖 <main></main> 唯一性做关键路径决策：解析时提前识别主内容区块，配合 fetchpriority="high" 或 preload 才能精准调度资源。若页面中出现两个 <main></main>，Lighthouse 会报错，服务端渲染时 hydration 也可能跳过部分节点。

• 常见错误：CMS 模板重复插入 <main></main>，或 JS 动态渲染时未校验已存在
• 实操建议：用 document.querySelector('main') 测试是否返回唯一元素；构建流程中加 ESLint 规则 no-duplicate-main
• 嵌套陷阱：<main></main> 不能包在 <div class="layout"></div> 或 <section></section> 里——它必须是顶层语义容器，否则破坏辅助技术对“主内容边界”的识别

<section></section> 和 <div> 的性能分界点在哪 <p><code><section></section> 不是“更高级的 <div>”，它触发浏览器隐式行为：当它带 <code><h2></h2>–<h6></h6> 标题时，会被视为独立可索引单元，影响首屏渲染优先级、content-visibility: auto 的裁剪粒度，以及爬虫快照生成逻辑。

• 该用 <section></section> 的场景：博客列表项、产品卡片组、FAQ 条目（每项含标题且主题独立）
• 该用 <div> 的场景：纯布局包裹层、无标题的按钮容器、表单字段分组（无语义主题） <li>性能影响：实测显示，把 50 个卡片强行套 <code><section></section> 而不配标题，DOM 节点数增加 15%，V8 编译耗时上升 8ms，且 Lighthouse 报“语义冗余”

嵌套层级超 4 层如何拖慢首屏

DOM 深度直接影响 layout shift 分数和 V8 编译耗时。语义标签本身不增深度，但开发者常在 <header></header> 外再套 <div class="container"></div>，导致实际 DOM 树达 6–7 层。


Wechat Article Html
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
下载
• 控制方案：优先用 display: contents 替代无意义包裹层——父元素不参与渲染树，子元素语义保留，Grid/Flex 布局仍生效
• 检查方法：DevTools → Elements → 右键节点 → “Reveal in Elements panel”，数路径长度；超过 4 层时手动折叠非关键区域
• 典型雷区：<footer></footer> 和 <aside></aside> 被塞进 <div id="layout"></div>，既干扰屏幕阅读器判断页面边界，又扩大重绘范围

真正卡住性能的，往往不是标签名写错，而是语义结构模糊导致后续所有优化策略“认不准人”——比如 preload 加载了非首屏图片，content-visibility 错切了导航栏，或者 SSR 注水时把整个 <aside></aside> 当成关键内容 hydrate。结构不清，优化就变成盲打。