语义化标签本身不提升渲染速度，但它是性能优化的必要前提：支持资源精准调度、快速DOM定位、降低渲染压力、减少嵌套开销，并需与关键CSS内联、preload及content-visibility协同生效。
语义化标签本身不提速，但它是性能优化的启动开关
浏览器解析 <header> 和 <div class="header"> 的耗时几乎一样，DOM 构建、样式计算、布局阶段都不会因标签名改变而变快。语义化不是“加速指令”，而是让后续优化手段有据可依：比如 <main> 是唯一能被 document.querySelector('main') 快速定位的原生节点，SSR hydration 可跳过非 <main> 区域；<nav> 被部分 Chromium 版本识别为可预加载链接的上下文；<picture> + <source media> 配合 <section>，能让媒体查询在 HTML 解析阶段就生效，避免等 CSSOM 构建完才选图。
常见错误现象：把所有 <div> 换成语义标签后跑 Lighthouse，Performance 分数没变化，就认为“语义化没用”。其实问题出在没配套落地——比如没对 <main> 下首个 <section> 提取关键 CSS，也没加 content-visibility: auto 或 fetchpriority="high"。
嵌套过深比标签名错误更伤首屏性能
实测显示，当某容器下嵌套超过 5 层且子节点总数超 200 时，首次绘制（FP）平均延迟 80–120ms，尤其在低端安卓 WebView 中更明显。DOM 树每深一层，V8 编译耗时平均上升 12ms，layout shift 分数也同步恶化。
-
<main>→<section>→<article>是合理三层；再套<div class="wrapper">就冗余 -
<footer>和<aside>不该包裹在<div id="layout">内——它们语义独立，强行包裹会干扰辅助技术对“页面边界”的判断 - 用
display: contents替代无意义包裹层：它让父元素不参与渲染树，但保留子元素语义，适合需要 Grid 布局又不想破坏结构的场景
<main> 的写法错一个字符，就可能让优化全失效
<main> 必须是 <body> 的直接子元素，且只能出现一次。嵌套在 <header> 或 <nav> 里，等于告诉屏幕阅读器“导航栏里藏着主内容”，逻辑冲突；重复输出则让浏览器无法判断哪块是真正核心，Lighthouse 直接报 Multiple main landmarks 错误。
立即学习“前端免费学习笔记（深入）”；
兼容性坑点：
- Safari ≤13.1 对
<main>的隐式role="main"支持不全，需显式写<main role="main"> - 服务端模板或 CMS 渲染时容易因条件分支漏判，导致多个
<main>同时输出 - DevTools 的 Accessibility 面板会直接标红提示，但很多团队只看 Console，忽略这个信号
<section> 和 <article> 用错，会拖慢爬虫和 JS 查询
<section> 表示有标题的独立主题块，必须含 <h1>–<h6>；<article> 是可独立分发的内容单元（如博客正文、新闻稿），带完整元信息，能被 RSS 抓取、搜索引擎作为独立条目索引。把整页商品列表包进一个 <section>，其实每条商品都该是 <article>。
错用后果：
- 爬虫误判内容层级，降低 SEO 权重
-
document.querySelectorAll('section')返回大量无意义节点，影响 JS 执行效率 - 辅助技术无法建立正确大纲，用户无法用快捷键跳转到目标章节
- 动态插入内容时，JS 若未校验已有 heading 层级，会导致
<h4>被识别为新章节起点，上层内容被跳过
<main> 出现次数的条件校验，以及构建流程中对 heading 层级的自动拦截。 
