嵌套深度超6层会显著拉高低端机cpu能耗，因解析器省电模式下主动降频，每多一层嵌套即增加节点插入、样式匹配与布局预备计算；实测iphone se（2020）电池低于20%时fcp从320ms升至580ms。
嵌套深度超6层会显著拉高低端机CPU能耗
不是“卡不卡”的问题，是解析器在省电模式下主动降频——每多一层嵌套，就多一次节点插入 + 样式匹配 + 布局预备计算。实测中，<div>
<div><div><div><div><p></p></div></div></div></div> 在电池低于20%的iPhone SE（2020）上，FCP从320ms跳到580ms，主线程调度被系统压缩得更保守。
<p>验证方式极简单：Chrome DevTools → Elements → 右键任意节点 → <code>Show DOM properties → 查 depth 值。超过6必须动刀，别信“看起来还行”。
- 语义标签如
<section></section>、<main></main>、<article></article>不省电，但能绕过选择器匹配陷阱，降低重排概率 - 避免在
<table> 单元格里嵌 <code><div> 再套 <code><div> —— 表格样式计算本就重，嵌套后极易触发同步 Layout <li>SSR/静态生成输出的 HTML 要重点检查 <code>data-reactroot或_next容器是否无意加深了父级嵌套 - 把重复的
<div class="item"></div>列表，改用<ul><li></ul>—— 同样语义，节点数通常少15%~20% - 移除无意义包裹层：
<div class="wrapper"><div class="content"><div class="inner">…</div></div></div>直接压成<main>…</main> - 注释、空格、冗余
- 首屏图加
fetchpriority="high"，强制提前 fetch - 所有
<img>加decoding="async"，避免解码阻塞主线程（尤其WebP/AVIF格式） - 慎用
loading="lazy"：低端机上它常和fetchpriority="low"叠加，首屏图可能永远等不到滚动触发 - 用
curl -I看响应头Content-Length，HTML体 >15KB 就要查内联资源占比 - 单个
<style></style>或<script></script>标签内代码行数 >50，基本可判定需拆出 - 关键CSS必须内联，但严格控在14KB以内；其余一律外链 +
media条件加载
DOM节点数超800直接触发低端机解析瓶颈
移动端稳定底线是800个节点以内。不是浏览器限制，而是低端芯片解析链路太长：节点越多，内存分配越碎，GC压力越大，尤其在Android省电模式下，V8 GC会被延迟触发，导致内存驻留升高、CPU持续小幅度抖动。
排查用 document.querySelectorAll('*').length 一行就能测；优化不是删功能，而是换结构：
fetchpriority 和 decoding 是首屏图能效关键杠杆
低端机上，图片加载不是“慢”，是“被系统节流”。默认所有 <img> 都标记为 fetchpriority="low"，浏览器会推迟加载直到主文档解析完——这在深度嵌套结构里，等于把图片塞进一个更长的队列尾端。
实操只改两属性，立竿见影：
内联CSS/JS超50行就是性能隐患源
不是“有没有用”，是“浏览器解析器卡在哪”。大段内联 <style></style> 或 <script></script> 会让HTML parser停在文本扫描阶段，DOM构建起点被迫延后——这对FCP是硬性延迟，且无法被CDN或缓存绕过。
判断标准很粗暴：
真正容易被忽略的，是那些“看起来只是辅助样式”的内联块——比如一个 display: none 的隐藏弹窗CSS，它照样参与全量选择器匹配，照样拖慢解析。优化不是砍功能，是让每一行HTML都承担明确、可测的职责。
