html不支持自动分块加载，实际是流式解析、渐进渲染与资源调度共同作用的结果；嵌套过深（≥7层）会阻塞dom构建，内联资源过大或script位置错误更会彻底中断流式解析。
HTML结构本身不“支持”或“触发”分块加载，浏览器排版引擎（即渲染管线）根本不存在“按HTML结构自动分块”的机制；所谓“分块加载”效果，实际是流式解析 + 渐进式渲染 + 合理资源调度共同作用的结果，而糟糕的结构会直接打断这个过程。
为什么嵌套过深会让流式渲染卡在中间
浏览器解析HTML是逐字符、自上而下流式的，但每遇到一个未闭合的<div>，就要在内存中维护一个打开标签栈。当嵌套超过6层（比如<pre class="brush:php;toolbar:false;"><div><div><div><div><div><p></p></div></div></div></div></div>），解析器不仅要匹配结束标签，还要为每一层创建节点、挂载父级、计算初始样式——这些操作无法并行，且必须串行完成。一旦某一层因内存压力或超时被截断（尤其在低端Android设备上），后续所有内容都不会进DOM树，更谈不上“分块渲染”。
</pre>
<ul>
<li>DevTools里右键任意节点 → <code>Show DOM properties 查 <code>depth 值，≥7 就已处于高风险区
用 document.querySelector('body').children.length 快速验证：如果返回值远大于视觉区块数（如首页只该有3个一级区块，却返回12），说明解析器被冗余包裹拖慢了
<table> 内嵌套 <code><div> 会放大问题：表格解析本就需要整行预读，再加多层 <code><div>，极易触发同步 Layout，让流式中断
<h3>script位置错误让“分块”彻底失效</h3>
<p>所谓“首屏先出来、后面慢慢加载”，前提是HTML能持续解析下去。而一个没加 <code>defer 或 async 的 <script></script> 放在 <main></main>、<section></section> 全部卡在内存里没进DOM，用户看到的就是白屏，不是“分块”，是“阻塞”。
- 非关键脚本（统计、监控、第三方SDK）必须加
defer：不阻塞解析，还能保序执行
- 纯交互逻辑（如按钮绑定）可用
async，但别在里操作DOM——document.getElementById('btn') 极可能返回 null
- 真要操作首屏元素的脚本，放
内联CSS/JS体积失控直接杀死流式起点
浏览器必须先把HTML文本全部扫描完，才能开始构建DOM树。“全部扫描”不等于“全部下载完”，而是指从响应体开头到第一个字节结束——所以如果你在 <style></style> 里塞了15KB的CSS（gzip后仍超10KB），解析器就得卡在那段文本里反复扫描、词法分析、生成AST，期间不做任何渲染。这不是“加载慢”，是解析被钉死。
- 单个
<style></style> 块超过1KB，就该拆成外部 <link rel="stylesheet">
-
<script type="application/json"></script> 里塞初始化数据？超过4KB就该考虑fetch异步加载，别塞进HTML正文
- 用
curl -I 查响应头 Content-Length，HTML体超15KB时，优先检查内联资源占比
语义标签不是“加分项”，而是流式解析的加速锚点
浏览器对 <header></header>、<main></main>、<section></section> 等语义标签有内置解析优化提示。比如遇到 <main></main>，渲染引擎会提前标记“这是关键内容区”，在流式解析过程中给其子节点分配更高优先级的样式计算和布局资源；而连续5个 <div> 则无此待遇，全靠暴力遍历匹配。
<ul>
<li>
<code><main></main> 缺失或重复，不仅影响SEO，还会让爬虫和浏览器都放弃识别主体内容区，导致首屏关键文本不被优先处理
<h1></h1> 塞在 <footer></footer> 里，浏览器虽能渲染，但会降权其语义权重，连带影响整块区域的样式继承链计算效率
用 <section></section> 替代 <div class="section"> 不只是语义升级，实测可减少约15%的样式匹配耗时（因祖先链更短、选择器路径更明确）
<p>真正难调的从来不是某段CSS动画或某个JS函数，而是你在写第一行HTML时就定下的结构契约：要不要嵌套、在哪关标签、用什么语义容器——这些决定在浏览器解析器读到第一个<code>时就已经生效，之后所有优化都是补救。
浏览器解析HTML是逐字符、自上而下流式的，但每遇到一个未闭合的<div>，就要在内存中维护一个打开标签栈。当嵌套超过6层（比如<pre class="brush:php;toolbar:false;"><div><div><div><div><div><p></p></div></div></div></div></div>），解析器不仅要匹配结束标签，还要为每一层创建节点、挂载父级、计算初始样式——这些操作无法并行，且必须串行完成。一旦某一层因内存压力或超时被截断（尤其在低端Android设备上），后续所有内容都不会进DOM树，更谈不上“分块渲染”。
</pre>
<ul>
<li>DevTools里右键任意节点 → <code>Show DOM properties 查 <code>depth 值，≥7 就已处于高风险区
document.querySelector('body').children.length 快速验证：如果返回值远大于视觉区块数（如首页只该有3个一级区块，却返回12），说明解析器被冗余包裹拖慢了<table> 内嵌套 <code><div> 会放大问题：表格解析本就需要整行预读，再加多层 <code><div>，极易触发同步 Layout，让流式中断
<h3>script位置错误让“分块”彻底失效</h3>
<p>所谓“首屏先出来、后面慢慢加载”，前提是HTML能持续解析下去。而一个没加 <code>defer 或 async 的 <script></script> 放在 <main></main>、<section></section> 全部卡在内存里没进DOM，用户看到的就是白屏，不是“分块”，是“阻塞”。
- 非关键脚本（统计、监控、第三方SDK）必须加
defer：不阻塞解析，还能保序执行 - 纯交互逻辑（如按钮绑定）可用
async，但别在里操作DOM——document.getElementById('btn')极可能返回null - 真要操作首屏元素的脚本，放
前；别信“DOMContentLoaded比load快”的模糊说法，实测晚100ms加载，LCP就晚100ms
内联CSS/JS体积失控直接杀死流式起点
浏览器必须先把HTML文本全部扫描完，才能开始构建DOM树。“全部扫描”不等于“全部下载完”，而是指从响应体开头到第一个字节结束——所以如果你在 <style></style> 里塞了15KB的CSS（gzip后仍超10KB），解析器就得卡在那段文本里反复扫描、词法分析、生成AST，期间不做任何渲染。这不是“加载慢”，是解析被钉死。
- 单个
<style></style>块超过1KB，就该拆成外部<link rel="stylesheet"> -
<script type="application/json"></script>里塞初始化数据？超过4KB就该考虑fetch异步加载，别塞进HTML正文 - 用
curl -I查响应头Content-Length，HTML体超15KB时，优先检查内联资源占比
语义标签不是“加分项”，而是流式解析的加速锚点
浏览器对 <header></header>、<main></main>、<section></section> 等语义标签有内置解析优化提示。比如遇到 <main></main>，渲染引擎会提前标记“这是关键内容区”，在流式解析过程中给其子节点分配更高优先级的样式计算和布局资源；而连续5个 <div> 则无此待遇，全靠暴力遍历匹配。
<ul>
<li>
<code><main></main> 缺失或重复，不仅影响SEO，还会让爬虫和浏览器都放弃识别主体内容区，导致首屏关键文本不被优先处理
<h1></h1> 塞在 <footer></footer> 里，浏览器虽能渲染，但会降权其语义权重，连带影响整块区域的样式继承链计算效率<section></section> 替代 <div class="section"> 不只是语义升级，实测可减少约15%的样式匹配耗时（因祖先链更短、选择器路径更明确）
<p>真正难调的从来不是某段CSS动画或某个JS函数，而是你在写第一行HTML时就定下的结构契约：要不要嵌套、在哪关标签、用什么语义容器——这些决定在浏览器解析器读到第一个<code>时就已经生效，之后所有优化都是补救。
