语义化标签选错会导致屏幕阅读器无法识别导航意图、SEO抓取失效、Lighthouse报可访问性警告、CSS解析变慢及辅助技术跳过关键内容。
语义化标签选错会导致什么实际问题
用 <div class="nav"> 代替 <nav>，表面看页面照样显示，但屏幕阅读器读不出导航意图，SEO 抓取时无法识别内容权重分布，Chrome DevTools 的 Accessibility 面板直接标红“missing landmark”。更隐蔽的问题是：CSS 选择器如 nav ul li a 比 .nav ul li a 解析更快——浏览器原生标签有内部优化，class 匹配要遍历全部 DOM 节点。
-
<main>出现两次或嵌套在<section>里，会触发 Lighthouse 可访问性警告，部分辅助技术跳过第二处<main> -
<section>没配<h2>或aria-labelledby，会被当成普通容器，丧失语义分组能力 - 把广告位硬塞进
<aside>，其实它只适用于与当前内容强关联的补充信息（如文章侧边引用），纯广告该用<div role="complementary">
DOM 嵌套超过三层为什么真会影响性能
不是“理论上慢”，而是实测滚动卡顿、CSS 匹配延迟可复现。浏览器构建 DOM 树是深度优先遍历，每多一层嵌套，解析耗时线性上升；而 CSS 选择器匹配成本是指数级——.a .b .c .d p 要逐层回溯父节点，比 article p 多查 3 层。
- 用 Chrome DevTools 的 Elements 面板按
Ctrl+Shift+C点击任意元素，看右下角显示的 “Path” 深度，超过html > body > main > section > article这种 5 层结构就要警惕 - 单个
<section>下子元素超 50 个（比如长列表），滚动时重排明显变慢；改用DocumentFragment批量插入，或拆成多个<section> - Flex/Grid 能直接砍掉 2–3 层包裹：三栏布局不用
<div class="row"><div class="col">…</div></div>，写display: grid就够
script 和 link 放错位置的真实后果
一个没加 defer 的 <script src="app.js"> 放在 <head> 里，不是“可能白屏”，而是必然中断 HTML 解析——连 <body> 都没生成，用户看到的就是纯白屏，Lighthouse Performance 分数直接崩到 20 以下。
-
<link rel="stylesheet">后面紧跟着没defer的<script>，CSSOM 构建会被卡住，首屏渲染延迟翻倍 -
@import写在 CSS 文件里（比如main.css里含@import "theme.css"），浏览器必须串行加载，无法并发，比并列多个<link>慢 300ms+ - 内联脚本
<script>init();</script>默认阻塞，加type="module"才自动defer；统计类脚本用async，但别指望它执行完再操作 DOM
preload 用错反而拖慢加载速度
<link rel="preload"> 不是“提前下载就一定好”，它是向浏览器发强提示：“这个资源我马上就要”。如果预加载了非首屏 JS，它会挤占带宽，导致真正关键的字体或图片下载变慢。
立即学习“前端免费学习笔记（深入）”；
- 只对明确在
DOMContentLoaded前必须就位的资源生效：首屏字体、loading="eager"的<img>、核心路由 JS -
<link rel="preload" href="font.woff2" as="font">必须加crossorigin属性，否则字体被 CORS 策略拒绝，页面文字 fallback 到系统字体 - 别对所有 JS 都
preload：它不控制执行时机，只抢带宽；defer才管执行顺序和时机
语义标签不是装饰，嵌套层级不是数字游戏，preload 也不是越多越好——所有优化动作都得对应到具体瓶颈：是可访问性断点？滚动卡顿？还是首屏白屏？盯着 DevTools 的 Network 和 Rendering 面板找根因，比套模板重要得多。
