必须唯一且为顶层容器，否则浏览器放弃early-exit优化导致lcp延迟；嵌套超4层时比更轻量因自带解析捷径，但滥用反增开销。
HTML语义化标签本身不减少字节、不加速网络传输，但它能显著降低浏览器解析、样式匹配和首屏渲染的隐性开销——前提是用对地方、避开常见反模式。
为什么 <main></main> 能让 LCP 提前触发而不是拖慢它
Chrome 对 <main></main> 有 early-exit 解析优化：遇到它就标记“主内容边界”，直接影响 Largest Contentful Paint（LCP）的计算起点。但若 <main></main> 里塞了 banner、导航、广告，或页面存在多个 <main></main>，浏览器会放弃该优化，回退到逐节点扫描 DOM 的低效路径。
- 必须全页唯一，且只包裹用户真正要阅读/操作的核心区块（如商品列表、表单主体、文章正文）
- Next.js 或 Remix 等框架中，避免在布局组件和页面组件里各写一个
<main></main> - 不要给
<main></main>加display: contents—— 它会剥离语义锚点，导致 early-exit 失效
<picture></picture> + <source media></source> 怎么减少无效图片请求数
关键不在“加载更快”，而在“根本不去加载”。浏览器在 HTML 解析阶段就根据 media 和 type 匹配首个有效 <source></source>，其余直接忽略。而纯 <img src="x.webp"> 在 Safari 15.6 或旧安卓 WebView 中可能 404 或降级失败，触发重试逻辑。
-
<picture></picture>内部的<img>必须带src或srcset，否则整个结构无图可显 - 不要把
<picture></picture>套在<div class="hero-image"> 里——多一层嵌套就多一次样式匹配和 layout check <li>实测混合设备流量下，合理使用可减少 12–18% 的移动端无效图片请求（HTTP Archive 2026 Q1）</li> <h3>嵌套超 4 层时，<code><section></section>比<div> 更轻量的原因 <p>每个 <code><div> 是通用容器，浏览器需额外推导其作用域、继承链和 ARIA 隐式角色；而 <code><section></section>、<nav></nav>等标签自带解析捷径和 DOM 节点优化策略。但滥用同样有害：把按钮包进<section></section>、用<section></section>替代<ul></ul>列表，反而增加无意义层级。- 检查嵌套深度：DevTools → Elements → 右键节点 → “Show DOM properties”，看
nodeType路径长度是否 > 4 - 相邻
<div class="wrapper"><div class="inner"> 直接合并为 <code><div class="wrapper inner">，CSS 用 BEM 控制 <li> <code>display: contents是替代无意义包裹层的安全方案：父元素不进渲染树，子元素语义保留
最容易被忽略的是标题层级断裂：
<h2></h2>出现在<main></main>外、小节用了<h3></h3>但主内容还没出现<h2></h2>——这会让辅助技术生成错乱大纲，比不用语义标签更伤性能和可访问性。 - 检查嵌套深度：DevTools → Elements → 右键节点 → “Show DOM properties”，看
