html质量差直接拖慢fcp、lcp和tti：嵌套过深（nodedepth＞6）延迟fcp超200ms；语义标签误用破坏lcp稳定性；script位置不当（如head内同步执行）拉长tti；内联资源超标（html＞15kb且内联占比＞30%）拖慢ttfb和解析。
HTML代码质量差，会直接拖慢FCP（首次内容绘制）、LCP（最大内容渲染）和TTI（可交互时间）——不是“可能影响”，而是浏览器解析、构建DOM、计算样式时的硬性开销。
嵌套过深导致FCP延迟
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次DOM节点创建+样式计算。移动端低端设备上，<div><div><div><div>
<p>这种结构会让FCP推迟200ms以上。</p>
<ul>
<li>用DevTools → Elements → 右键节点 → “Show DOM properties”查<code>nodeDepth，超过6层就要重构
<section></section>、<article></article>等语义标签不增加渲染成本，还能缩短CSS选择器匹配路径<table>里套<code><div>再套内容：单元格内样式计算成本翻倍，极易触发重排
<h3>script位置不当拉长TTI</h3>
<p><code><script></script>默认同步执行，放在
- 统计、埋点、第三方SDK一律加
defer：保证执行顺序，且不阻塞解析 - 纯交互逻辑（如按钮事件绑定）可用
async，但注意它不保序，且可能在document.body还没生成时就运行 - 真要操作DOM的脚本，必须放
前——别信“DOMContentLoaded比load快”的模糊说法，实测晚100ms加载，TTI就晚100ms
内联资源体积超标拖慢TTFB和解析起点
服务器返回的HTML体如果含大段<style></style>或<script></script>，不仅拉高TTFB（Time To First Byte），还会让HTML解析器卡在文本扫描阶段，延迟DOM构建起点。
- 单个
<style></style>块超过1KB，必须拆成外部<link rel="stylesheet">；CSS-in-JS生成的内联样式同理 -
<script></script>内联代码超50行，基本可判定为维护风险+性能隐患，应提取为模块文件 - 用
curl -I看响应头Content-Length，HTML体大于15KB时，重点检查内联资源占比——2026年实测，超30%即显著拖慢FCP
语义标签误用破坏结构解析与LCP稳定性
错用语义标签（如把<section></section>当<div>用、<code><main></main>重复出现、标题跳级）会让浏览器和辅助技术无法建立正确的内容索引，间接导致LCP计算异常或延迟触发。
-
<main></main>必须且只能出现一次，且不能嵌套在<header></header>、<footer></footer>或<nav></nav>内 -
<section></section>需自带<h2></h2>–<h6></h6>标题，否则优先用<div> <li>标题层级断层（比如从<code><h1></h1>直接到<h4></h4>）会让LCP候选元素被错误排除——用DevTools的Accessibility面板检查“Heading level”是否连续
真正卡顿的根源往往不在JS执行或图片加载，而在HTML本身：DOM树太深、解析被阻塞、首屏样式没及时到位、结构语义混乱让浏览器反复纠错。这些点不解决，后续所有优化都像给漏水的桶刷漆。
