HTML本身无“函数加载”概念，所谓“加载慢”实为JS执行卡顿、DOM阻塞、资源延迟或渲染拖累；document.write()会清空文档流、中断解析，已被废弃；动态插入应改用innerHTML或append；SSR/模板中禁用document.write；视觉更新须用requestAnimationFrame对齐刷新率；preload仅用于确定即用资源，避免误用抢占带宽；真卡顿常源于批量DOM操作、强制回流或DevTools深度日志，优化前应录Performance分析主线程瓶颈。
HTML 本身没有“函数加载”这个概念——所谓“HTML函数加载慢”，实际是 JavaScript 执行卡顿、DOM 操作阻塞、资源加载延迟或渲染管线被拖累的表现。直接优化“HTML函数”毫无意义，得定位到具体瓶颈环节。
为什么 document.write() 会让页面卡死
它不是“慢”，而是会清空当前文档流、强制中断 HTML 解析器，重新构建 DOM 树。现代浏览器已将其标记为废弃，且在 DOMContentLoaded 后调用会直接报错 TypeError: document.write is not supported。
- 所有动态插入内容的场景，改用
element.innerHTML = ...或element.append(...) - 若需在解析中注入脚本（极少见），用
document.currentScript定位并操作父容器，而非写入整个文档 - 服务端渲染（SSR）或模板引擎输出时，确保不生成
document.write调用
requestAnimationFrame 不是万能，但不用它动画一定掉帧
在笔记本上，setTimeout(fn, 16) 因系统调度不准、电池节能模式、JS 主线程阻塞等原因，实际延迟常达 30–50ms，导致视觉撕裂。而 requestAnimationFrame 会自动对齐屏幕刷新周期，且标签页不可见时暂停执行。
- 所有视觉更新（位置、透明度、尺寸）必须包在
requestAnimationFrame里，哪怕只改一次 - 不要嵌套调用：
requestAnimationFrame内不要再递归注册自己，用单次注册 + 外部状态判断控制持续性 - 数据状态检查（如滚动位置、是否进入视口）放在
requestAnimationFrame外，只把渲染逻辑放进去
预加载 link rel="preload" 加错反而更慢
它提前触发下载，但不执行，也不保证顺序。加错会抢占带宽，挤掉关键 CSS/HTML，首屏反而变长。
立即学习“前端免费学习笔记（深入）”；
- 只对「确定马上要用」的资源用：
as="font"（必须配crossorigin）、首屏<img>的src、异步import()立刻要加载的模块（as="script"） -
preload≠prefetch：后者是为后续路由准备，浏览器优先级低，别混用 - 避免对 CSS 中 @import 的资源重复
preload，CSS 解析器自己会发起请求
真正卡顿往往藏在 DOM 批量操作、同步 layout 强制回流、或 DevTools 开着时 console.log(div) 深度遍历子树这些细节里——它们不会报错，但会让笔记本风扇狂转、动画一卡一卡。优化前先开 Performance 面板录一段，看主线程哪段在红着喘气。
