应先确认模块是否被js依赖、css选择器匹配或承载语义（如data-*、aria属性），再结合chrome devtools“break on node removal”验证运行时依赖，最后用lighthouse检查dom节点数变化。
删掉没被 JS 依赖、没被 CSS 选择器匹配、也没承载语义的模块，比压缩整个 HTML 文件更直接有效——实测删一个空 <section></section> 能让低端安卓机首屏快 150ms。
怎么确认某个模块真能删
别只看它“在页面上不显示”。很多模块初始隐藏但被 JS 动态控制（比如弹窗容器、表单步骤面板），盲目删除会导致功能崩溃。关键看三件事：
- 在 Chrome DevTools 的 Elements 面板中右键该模块根节点 → “Break on” → “node removal”，刷新页面并操作所有交互，若断点触发，说明 JS 在运行时依赖它
- 全局搜索它的
id或class（比如search-modal），检查是否出现在 JS 的querySelector、getElementById或 CSS 的后代选择器（如.header .nav ul li）里 - 检查是否含
data-*属性（如data-module="analytics"）或 ARIA 属性（如aria-labelledby="help-title"）——即使视觉为空，也可能被无障碍技术或埋点逻辑读取
哪些模块最常被误留
这些是 CMS 导出、模板克隆或历史迭代后高频残留的“僵尸模块”，删前不用犹豫，但删后必须验证布局是否错位：
-
<div id="debug-overlay"></div>、<div class="temp-wrapper"></div>：开发阶段占位，上线前必须清空 - 无标题也无内容的
<section></section>，比如只有<section><div class="empty-state"></div></section>，且父级没用到section语义做样式隔离 - CMS 自动插入的空
<table> 块，形如 <code><table><tr><td></td></tr></table>，且 computed 样式里没有display: table类属性 - 重复的
<script></script>加载同一 SDK，比如两个<script src="https://cdn.example.com/analytics.js"></script> - 打开 Lighthouse，跑一次“Avoid an excessive DOM size”，确认总节点数
- 手动触发所有 JS 行为：点开折叠菜单、切换 Tab、提交表单、上传文件，观察控制台是否出现
Cannot read property 'appendChild' of null这类因 DOM 节点缺失导致的错误 - 用 W3C Validator（validator.w3.org）校验 HTML 结构，重点看
Element not allowed as child报错——比如把<main></main>嵌套进了<header></header>，这种语义错位不会立刻报错，但会影响 SSR 和屏幕阅读器 - 检查
<link rel="preload">和<meta name="viewport">是否还在，它们不渲染但决定资源加载节奏和响应式行为
删完怎么验证没崩
不是刷新页面看看“有没有报错”就完事。真实风险藏在边缘路径里：
真正难的不是“删什么”，而是删完之后，那个原本靠三层 <div> 堆出来的间距、靠空 <code><td> 撑开的列宽、或者靠注释块隔开的 JS 模块边界，会不会突然消失。结构精简不是减法练习，是重新校准整个渲染链路的起点。</td>
