语义化html是前端性能优化的前提，缺失则关键css内联、preload调度、content-visibility等均失效；标签支持原生快速定位与首屏资源早干预，嵌套超4层会增加v8编译耗时并恶化cls。
语义化 HTML 本身不提速，但它是所有前端性能优化能生效的前提——没它，关键 CSS 内联、preload 调度、content-visibility 控制、服务端 hydration 跳过，全都会失效或打折扣。
为什么 <main></main> 比 <div class="main"> 更利于资源调度
<p>浏览器在解析 HTML 阶段就能识别 <code><main></main>，并据此提前标记“首屏关键内容区”。配合 fetchpriority="high" 或 preload，资源加载顺序可被更早干预；而 <div class="main"> 必须等 CSSOM 构建完成、甚至 JS 执行后才能定位，延迟关键路径。
<ul>
<li>
<code><main></main> 是唯一支持 document.querySelector('main') 原生快速定位的语义标签，SSR 注水时可跳过非关键区块的 hydration
<nav></nav>、<aside></aside> 视为低优先级内容，在生成首屏快照时可能直接跳过渲染，降低主线程压力<picture></picture> + <source media></source> 包裹在 <section></section> 内，媒体查询能在 HTML 解析阶段就生效，避免 CSSOM 构建后才触发响应式图片加载嵌套层级超 4 层会怎样
DOM 树深度每增加 1 层，V8 编译耗时平均上升约 2ms（实测 1000 节点对应 +12ms），同时 layout shift 分数显著恶化。常见错误是给每个语义标签再套一层 <div class="container">，导致 <code> → <div id="layout"> → <code><header></header> → <div class="wrapper"> → <code><h1></h1> 这类 5 层结构。
- 控制在 3–4 层内：推荐
<main></main>→<section></section>→<article></article>，中间不加无意义包裹层 -
<footer></footer>和<header></header>不应包裹在<div id="layout"> 内——它们语义独立，强行包裹会干扰辅助技术对“页面边界”的判断，间接扩大重绘范围 <li>需要 Grid/Flex 布局又不想破坏语义时，用 <code>display: contents替代<div> 包裹：父元素不出现在渲染树，子元素语义保留 <h3>关键 CSS 内联时最容易忽略的语义一致性</h3> <p>内联关键 CSS 的前提是 HTML 结构与样式选择器完全匹配。把 <code><header></header>的样式写进<style></style>，但实际 HTML 用了<div class="header">，那这段内联 CSS 就等于白写——不仅无效，还额外增加 HTML 体积。 <ul> <li>只对首屏可见的语义区块提取关键 CSS：<code><header></header>、<main></main>下第一个<section></section>、<article></article> - 避免“伪语义化”：比如用
<div role="main"> 代替 <code><main></main>，虽有 ARIA 表达，但不触发浏览器原生优化逻辑 - 服务端模板中若动态输出语义标签（如
<main></main>），需确保content不包含破坏层级的嵌套<div> <p>真正卡住性能的，往往不是某个标签选错，而是语义结构和资源调度策略之间存在隐性断层——比如用了 <code><main></main>却没配fetchpriority，或内联了关键 CSS 却把对应 HTML 改成了div。这种断层不会报错，但会让所有优化努力静默失效。
