删掉没用的嵌套比压缩空格更立竿见影：dom节点每增100个拖慢解析20–40ms；应通过devtools断点、css选择器检查冗余div，删除cms占位符，用语义化标签替代无意义容器，并清除模板残留和空注释。
删掉没用的嵌套，比压缩空格更立竿见影DOM节点每增加100个，平均拖慢解析20–40ms；而一个按钮被套5层
，就凭空多出4个节点——浏览器得逐层确认、回溯、建立关系，但最终什么也没干。这不是“写法不美”，是真实卡顿源。- 打开DevTools → Elements面板，右键可疑 → “Break on subtree modifications”，交互触发后看哪些包裹层根本没变化
- 用CSS选择器搜索
div[class]，逐个检查对应class是否真在CSS里有规则；没匹配的，连同整个<div class="xxx">一并删掉<li>特别警惕CMS或低代码导出的<code><div data-id="123">，只要没JS通过<code>data-id查它，就是纯噪音用语义化标签替代无意义容器，浏览器解析路径更短
浏览器对<header></header>、<nav></nav>、<main></main>等标签有预判优化：它们天然单层、语义明确，解析器不用反复试探父子关系。一堆同级<div>则强制它做更多工作。<ul><li><code><div class="main-header"> → 改成<code><header class="main-header"></header>，类名保留，只换标签
-
<div class="nav-list"><ul>...</ul></div> → 改成<nav><ul>...</ul></nav>
- 避免
<section><div>
<h2>这种写法：<code><h2></h2>必须直接子级于<section></section>，否则语义断裂，解析器还得兜一圈清掉模板残留和空注释，别让它们白占解析时间
注释不渲染，但浏览器仍要逐字读取、跳过；千行注释≈多花3–8ms。更麻烦的是模板语法残留，比如{{header}}或{% include "footer.html" %}，它们不报错，却会干扰SSR/静态生成时的DOM构建顺序。
- 删净所有
{{、{%、<code>@@include及其闭合符（如}}、%}）
- 删掉形如
<!-- START NAV -->这类区块注释——除非你真用构建工具做条件注入，否则只是噪音
- 确认
<meta charset="utf-8">在HTML前1024字节内，否则浏览器可能先按latin1乱解码再重载，引发闪动
别把整页列表塞进初始HTML，动态插入更轻量
一个含100项的<ul></ul>列表，光HTML字符就超15KB，DOM节点轻松破千。浏览器解析它比加载一个JS文件还慢——这不是“内容多”，是结构误配。
- 把列表HTML拆成独立文件（如
/data/list-1.html），初始HTML只留<ul id="list-root"></ul>
- 用
fetch() + insertAdjacentHTML('beforeend', html)动态插入，首屏不阻塞
- 避免
innerHTML = '<li>...</li>'拼接长字符串：V8解析HTML字符串比document.createElement()慢3–5倍
实际项目里，最常被忽略的是“删完不验证”：改完结构后务必F5刷新，用DevTools的“Rendering”面板勾选“Paint flashing”，看是否仍有意外重绘；再跑一次Lighthouse，对比“DOM size”和“Parse HTML”耗时——结构优化不是一劳永逸，而是每次迭代都要重审的活儿。
DOM节点每增加100个，平均拖慢解析20–40ms；而一个按钮被套5层
，就凭空多出4个节点——浏览器得逐层确认、回溯、建立关系，但最终什么也没干。这不是“写法不美”，是真实卡顿源。
- 打开DevTools → Elements面板，右键可疑→ “Break on subtree modifications”，交互触发后看哪些包裹层根本没变化
- 用CSS选择器搜索
div[class]，逐个检查对应class是否真在CSS里有规则；没匹配的，连同整个<div class="xxx">一并删掉<li>特别警惕CMS或低代码导出的<code><div data-id="123">，只要没JS通过<code>data-id查它，就是纯噪音用语义化标签替代无意义容器，浏览器解析路径更短
浏览器对
<header></header>、<nav></nav>、<main></main>等标签有预判优化：它们天然单层、语义明确，解析器不用反复试探父子关系。一堆同级<div>则强制它做更多工作。<ul><li><code><div class="main-header"> → 改成<code><header class="main-header"></header>，类名保留，只换标签<div class="nav-list"><ul>...</ul></div>→ 改成<nav><ul>...</ul></nav>- 避免
<section><div> <h2>这种写法：<code><h2></h2>必须直接子级于<section></section>，否则语义断裂，解析器还得兜一圈清掉模板残留和空注释，别让它们白占解析时间
注释不渲染，但浏览器仍要逐字读取、跳过；千行注释≈多花3–8ms。更麻烦的是模板语法残留，比如
{{header}}或{% include "footer.html" %}，它们不报错，却会干扰SSR/静态生成时的DOM构建顺序。- 删净所有
{{、{%、<code>@@include及其闭合符（如}}、%}） - 删掉形如
<!-- START NAV -->这类区块注释——除非你真用构建工具做条件注入，否则只是噪音 - 确认
<meta charset="utf-8">在HTML前1024字节内，否则浏览器可能先按latin1乱解码再重载，引发闪动
别把整页列表塞进初始HTML，动态插入更轻量
一个含100项的
<ul></ul>列表，光HTML字符就超15KB，DOM节点轻松破千。浏览器解析它比加载一个JS文件还慢——这不是“内容多”，是结构误配。- 把列表HTML拆成独立文件（如
/data/list-1.html），初始HTML只留<ul id="list-root"></ul> - 用
fetch()+insertAdjacentHTML('beforeend', html)动态插入，首屏不阻塞 - 避免
innerHTML = '<li>...</li>'拼接长字符串：V8解析HTML字符串比document.createElement()慢3–5倍
实际项目里，最常被忽略的是“删完不验证”：改完结构后务必F5刷新，用DevTools的“Rendering”面板勾选“Paint flashing”，看是否仍有意外重绘；再跑一次Lighthouse，对比“DOM size”和“Parse HTML”耗时——结构优化不是一劳永逸，而是每次迭代都要重审的活儿。
- 用CSS选择器搜索
