页面加载时间从380毫秒降到120毫秒，速度提升约3.16倍。这是一次从“卡顿”到“顺滑”的变换，发生在一个普通的生产问题排查过程中。

最后一步带来最大提升的是把增量插入替换成DocumentFragment。把要插入的节点先往文档碎片里组装好，组装完成后一次性把碎片append到真实DOM上，浏览器只做一次布局和重绘，开销一下子少了不少。测试时，数据量不大的那部分已经非常快，数据多的那一页更是明显——刷新几次，界面没有停顿感，交互回弹快很多。要说难以置信也挺夸张，但这是事实。

在用DocumentFragment之前，我已经做了一个看起来很“足够”的改造：把循环里每次innerHTML写入的方式改成先在变量里拼好HTML字符串，然后一次性赋值给容器的innerHTML。这个改动立刻把明显的卡顿消掉了一半以上。为了验证，我跑了Lighthouse，性能分数一下子提升了约212%，用户也立刻反馈页面顺了。那会儿我还以为到此为止就够了，没想到还可以更快。

再往前看，问题的核心其实是过度、频繁的DOM操作。原始代码里有一个典型的反模式：在循环内部每次都往DOM写数据，类似这样做，浏览器就得反复计算布局、样式、重绘。写一次DOM的代价远比一次内存字符串拼接大得多。实际运行里，这类写操作成百上千次，CPU瞬间就吃不消了，用户点个标签页都像在拖抽屉。

还有一类细节也把性能拉低了：一些高频事件监听器没有任何节制。输入键盘、窗口resize这些事件，原代码都是每次触发就走完整处理流程。把事件的触发频率用防抖控制住之后，CPU占用和界面卡顿都明显下降。我用的是一个简单的防抖：把处理函数包一层，延迟执行，直到触发停止超过某个阈值再真正调用。resize事件设了200毫秒，效果立竿见影，页面的重排次数直线下降，体验变得平稳。

还有个容易被忽略但确实糟糕的点：在循环内部重复调用querySelector之类的DOM查询。原代码里很多地方都是每次循环都再去找同一个元素，等于把一次本应做一次的工作做了N次。把查询结果缓存到变量后再复用，CPU负担就少了。这个改动看起来不起眼，但把不必要的DOM遍历拿掉后，整体流程更顺了。

描述到这里，时间要回溯到事件的起点。那晚我在咖啡馆，已经很晚了。刚给一个新功能上了生产，所有测试过得挺顺，代码评审也没问题。上线后用户开始用仪表盘，数据量不大，但界面响应却很慢。点击切页、切标签反应滞后，像老旧汽车在抖。现场挺尴尬的，因为这是我亲自推的版本，感觉哪儿不对劲，但日常检查都没发现明显问题。

半夜里开着笔记本，我先看了网络面板，想当然地把原因归到网络延迟上。请求都正常，延迟不高。接着打开了Performance记录和Timeline，结果显示主线程在做大量的布局和绘制工作。那时候有点懵：网络不是问题，服务器没异常，CPU却被前端的渲染任务吃掉。这就是所谓的“看起来对但不高效”的代码在作祟。

为了调试方便，我先放了几条日志，顺手把生成的HTML先拼成字符串再写入页面。这样临时变更一下，卡顿感果然消失了。我就照着这思路做了批量更新，再用开发者工具慢慢定位：哪些片段在循环里反复写入，哪些查询可以缓存，哪些事件需要节流或防抖。每改一处，界面就平一点，CPU占用也降一点。

在调整过程中，我把注意力从高大上的框架、构建工具、或者替换库上收回来，专注于浏览器对DOM的真实开销。浏览器处理DOM写操作的流程，会牵扯到样式计算、布局、合成层、重绘，每一步都不是免费的。减少这些操作的次数，比引入复杂抽象往往更有效。于是我先把写DOM的次数砍到最少，再处理事件频率，最后把碎片化的节点构造迁移到DocumentFragment里，一步步把问题逼出圈。

这一路的改动都很朴素：把多次写入合并成一次，把高频触发改成有限触发，把重复查询缓存一次。没有换框架，也没做大规模重构，改动点很小，但整体效果大。测了具体时间：从最初的380毫秒到最后的120毫秒，三倍多的提升。那晚的“尴尬”变成了一个挺好用的经验教训。然后我把这些改动整理进代码库，发了一个补丁。