超长单页HTML压缩必须分层处理：先保功能（禁用破坏性配置、保留关键注释与空格）、再压体积（精准压缩CSS/JS）、最后调渲染（预计算offsetTop、优化display:none）。
超长单页 HTML（2000+ 行、多区块、含大量文本/结构）不能靠简单删空格解决；手动压缩无效，工具默认配置会破坏滚动监听和 DOM 计算逻辑，必须分层处理：先保功能，再压体积，最后调渲染。
html-minifier-terser 默认配置会破坏滚动懒加载逻辑
很多项目用 html-minifier-terser 一键压缩后，发现按需渲染失效、offsetTop 计算为 0、display: none 区块无法激活——根本原因是它默认移除注释 + 折叠空白，但你的 JS 初始化代码可能依赖预计算的 DOM 结构对齐（比如靠换行或空格维持的父子嵌套视觉位置），或注释里埋了区块标识（如 <!-- section-3-start -->）。
- 禁用
--remove-comments，或改用正则精准清除开发注释（保留<!-- lazy-section:.*?-->这类标记） - 禁用
--collapse-whitespace，改用--minify-css true --minify-js true --remove-optional-tags false，避免误删</p>导致段落合并错位 - 在 JS 初始化前加一行
<script>document.documentElement.classList.add('minified');，CSS 中用.minified .box { display: none; }替代内联 style，防止压缩后 class 名被误删
滚动监听前必须预计算 offsetTop，且不能被压缩干扰
浏览器在压缩 HTML 后可能重排 DOM（尤其移除空白导致 <div><p> 变成 <div><p> 紧贴），使 element.offsetTop 值偏移。若你在 scroll 事件里实时调用，性能差且结果不准；若压缩后才首次运行 updateBoxMetrics()，又可能因 DOM 尚未完全就绪而取到 0。
- 把预计算逻辑提前到
<script>标签中，并包裹在document.addEventListener('DOMContentLoaded', ...)内 - 避免用
getBoundingClientRect().top替代offsetTop，前者受 CSS transform / scroll-margin 影响，后者更稳定 - 在压缩命令中显式保留关键空行：
--custom-html-remark 'section-start|section-end'（需自定义插件），或改用注释锚点 + 正则提取区块范围
压缩后首屏仍卡顿？检查是否遗漏 display: none 的副作用
单纯给非首屏区块加 style="display: none" 不够。Chrome DevTools 的 Layers 面板会显示：即使 display: none，若区块含大量子元素或内联样式，浏览器仍会解析其 CSSOM 并构建部分 RenderObject，造成内存占用高、滚动时偶发重排。
立即学习“前端免费学习笔记（深入）”；
- 用
visibility: hidden+height: 0+overflow: hidden组合替代纯display: none，确保不参与布局计算 - 对每个懒加载区块，移除其内部所有
script标签（改为按需动态createElement('script')），防止压缩后 JS 提前执行污染全局作用域 - 确认服务器返回的
Content-Type是text/html;charset=utf-8，否则某些压缩工具会错误解码中文字符，导致 DOM 解析中断
真正棘手的不是“怎么压小”，而是“压完还能不能正确触发下一块”。所有压缩操作必须以不改变 DOM 节点树深度、不干扰 offsetParent 链、不破坏 JS 初始化时机为前提——这要求你把压缩步骤拆进构建流程，在 HTML 生成后、JS 注入前完成，而非当成发布前的黑盒操作。
