html结构深度超6层会显著拖慢fcp，需用语义化标签替代深层嵌套；script应defer/async或置底；首屏内容须前置以优化lcp；关键图必设fetchpriority="high"与loading="eager"。
HTML文档结构不是“写完就能跑”的静态骨架，它直接决定浏览器构建DOM树的速度、关键内容何时进入渲染流程、以及首屏能否在1秒内可见。结构写得深、乱、靠后，性能问题就藏在里面——和JS写得多不多、CSS有没有压缩，关系不大。
嵌套超过6层会显著拖慢FCP
浏览器解析HTML是流式、自上而下逐节点进行的，每多一层嵌套，就多一次DOM节点创建 + 样式匹配 + 布局计算触发机会。在低端安卓机或iOS旧款设备上，<div>
<div><div><div><p></p></div></div></div>这种结构会让首次内容绘制（FCP）延迟200ms以上。
<ul>
<li>用Chrome DevTools → Elements面板右键任意节点 → <code>Show DOM properties，查看depth值；超过6就要重构
<section></section>、<main></main>、<article></article>替代三层<div>堆叠的，优先替换——它们不增加解析开销，还能让CSS选择器更扁平（比如<code>main h1比div div div h1匹配更快）
<td>里嵌套<code><div>：表格单元格内样式计算本就重，再加嵌套极易触发同步Layout，尤其在flex容器中混用时
<h3>
<code>script放错位置等于主动卡住首屏
<script></script>默认同步执行，放在或顶部时，浏览器必须暂停HTML解析、下载并执行完脚本，才能继续构建DOM树。这不是JS代码质量的问题，而是CRP（关键渲染路径）被硬性阻断。
- 非关键逻辑（统计、埋点、第三方SDK）一律加
defer：保证按顺序执行，又不阻塞HTML解析 - 纯交互脚本（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行——若操作DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作DOM的脚本，放
前；别信“DOMContentLoaded比load快”的模糊说法——实测晚100ms加载，首屏就晚100ms - 内联脚本（如
<script>init();</script>）永远阻塞，且无法用defer/async缓解，必须外链化
首屏内容写在HTML底部 = LCP天然拉长
浏览器不会“跳着解析”。关键内容（如主标题、首图、核心表单）如果写在HTML靠后位置，哪怕体积再小，也得等前面所有标签解析完才进入DOM树。LCP（最大内容绘制）自然被拉长，3G网络下可能超3秒。
- 把
<h1></h1>、<img fetchpriority="high">、<form></form>等首屏元素尽量前置，哪怕要牺牲一点模板复用性 - 导航栏这类非首屏内容，可考虑用
loading="lazy"+fetchpriority="low"降权，或拆成异步<template></template>+ JS插入 - 避免在
里用<script></script>动态插入首屏DOM——这等于把CRP从“HTML流式解析”退化为“JS执行后重建”，完全绕开浏览器原生优化 - 删掉所有
display: none但仍在DOM里的冗余节点——它们不参与渲染树，但会占用DOM解析和内存，尤其在列表页、搜索页中易堆积
fetchpriority和decoding是图片加载的真实开关
默认所有<img>都被标记为low优先级，哪怕它是LCP候选元素；解码也默认同步执行，一张200KB的图就能卡住主线程。这两个属性不是锦上添花，而是解决滚动卡顿、首图延迟的核心手段。
- 首屏关键图必须加
fetchpriority="high"+loading="eager"（别用lazy） - 大于100KB的图片建议加
decoding="async"；小图标或SVG保持默认即可 -
fetchpriority="low"适合埋点脚本、分析SDK、非可视占位图等，明确告诉浏览器“别抢带宽” - 对
loading="lazy"的图不要preload——它和预加载语义冲突，浏览器可能忽略或重复请求
真正容易被忽略的是：结构优化不是“改完语义标签就结束”，而是持续检查depth值、验证fetchpriority是否生效、确认script是否真的没阻塞——这些细节不体现在代码审查里，却直接决定用户第一眼看到页面的时间。
