用豆包网页版做长对话最难受的不是AI偶尔答非所问而是聊了二十轮、三十轮之后整个页面的滚动开始“粘手”。鼠标滚轮轻轻一格页面要么纹丝不动要么顿一下再猛跳一截快速往上翻历史消息时甚至能看到半屏幕白屏闪过去。这个卡顿我忍了很久一开始怀疑是浏览器插件装太多把所有扩展全部禁用一遍没用又换了Chrome、Edge轮着试同样的问题照旧。直到我打开DevTools录了一段滚动的Performance记录才发现问题根本不出在我的环境而是页面自身在超长对话场景下的渲染开销确实扛不住。这篇文章就是把我整个排查和解决过程完整记录下来为什么会卡、卡在哪个环节、为什么选择用篡改猴Tampermonkey插件来做优化以及优化脚本的完整设计思路和实测效果。如果你也在用这类AI对话网页长对话一多就开始掉帧、滚动卡顿这篇应该能帮你省很多事。文章里所有代码和思路都是我在自己机器上验证过的但浏览器页面随时会改版类名和DOM结构要以你当时的页面为准。1. 先把“卡”这件事查明白豆包页面滚动卡顿的根因动手优化之前最重要的事情不是写代码而是搞清楚页面到底为什么卡。没有根因分析就乱投医大概率会把页面改出一堆新问题。我的排查路线是这样的。1.1 复现与观测从“感觉卡”到“看到卡”先把问题稳定复现出来新建一个豆包对话连续追问足够多的问题把对话滚到两百条消息以上然后快速上下滚动。只要这个操作能稳定出现掉帧问题就可靠了。然后打开DevTools里的Performance面板点一下录制在页面上做十秒来回滚动操作停止录制后那一大堆彩色条就是浏览器每一帧的工作情况。重点看主线程Main里有没有红色块——浏览器主线程上一个任务超过50毫秒就属于长任务Long Task这种长任务一旦密集出现滚动不卡才怪。我录下来的结果非常典型滚动过程中频繁出现红色长任务单次最长跑到300毫秒以上Rendering渲染和Painting绘制占了大半时间主线程上能看到连续的重排Layout操作。再用Elements面板随便点开一条历史消息你会发现一条消息内部的嵌套结构非常深——外层容器套气泡、气泡套文本节点、文本节点里还有内联样式和额外元素。在Console里跑一下document.querySelectorAll(*).length长对话场景下总节点数轻松突破一万甚至几万。上万个大大小小的DOM节点全部躺在文档里每次滚动浏览器都要去计算它们的布局、绘制、上下层关系这就是卡顿的根源。1.2 长对话页面的三个性能黑洞把问题拆解开其实滚动卡顿是三个因素叠在一起的第一DOM节点数量爆炸。和表格大数据卡顿的场景类似容器原生控件在数据量上去之后性能骤降这类产品最终都需要换用自定义渲染或虚拟列表。豆包的对话页也是同一类问题历史消息不回收、不虚拟化所有内容一次性全部保留在DOM里节点越多滚动时浏览器需要处理的布局计算量越大。第二强制同步布局触发频繁。页面在滚动过程中如果做了“先读后写”的操作——比如读了元素的offsetHeight、offsetTop紧接着又去改某个元素的样式——浏览器就会被迫在滚动帧里同步执行一次重排。这种布局抖动layout thrashing在Performance面板里通常会被标成“Forced reflow”警告。它是最典型的隐形杀手很多优化代码不仅没用反而因为读写顺序处理不当火上浇油。第三合成层数量管理失控。很多前端页面为了实现平滑动画会给元素叠加transform: translateZ(0)或will-change: transform这类强制提升合成层的样式。初衷是好的但一旦给几百上千个元素都开了独立合成层GPU内存就吃不消了滚动时的合成开销反而暴涨。从DevTools的Layers面板能直接看到页面创建了多少个合成层长对话页面里这个数字通常非常吓人。搞清楚这三个问题之后优化思路就很明确了在不改变页面交互、不破坏消息结构的前提下用外部脚本削减DOM节点的渲染开销把滚动时不必要的布局和绘制压到最低。这就到了选择实施工具的时候。2. 选型逻辑为什么是Tampermonkey用户脚本确定要做“外部优化”之后我还有几个可选方案重新封装浏览器、改hosts、加载浏览器扩展……但我最终选了Tampermonkey也就是国内常说的篡改猴插件。原因很简单也很实际。2.1 官方设置里没有控制渲染开销的开关豆包的设置面板里能调整的通常只有外观主题、文字大小、语音音色这类日常选项并不提供“降低动画效果”“限制历史消息加载数量”“关闭消息飞入动画”这种性能相关开关。这就意味着用户层面的需求产品目前没有给到任何入口。我不可能去改豆包的服务端代码唯一能动的就是浏览器端加载出来的页面本身。2.2 用户脚本的介入方式与运行时机Tampermonkey这类用户脚本管理器本质上是一个往网页里注入自定义JavaScript和CSS的容器。脚本写好之后只要页面匹配对应的match规则Tampermonkey就会在指定的时机把脚本注入到页面里执行。这里有一个非常重要的参数run-at。它决定脚本什么时候运行。像滚动卡顿优化这种操作需要在页面内容渲染完成之后再介入否则脚本可能跑得太早没等到滚动容器生成。我用的document-idle也就是页面空闲阶段执行比document-end稍晚一点但足够稳定。脚本注入后DOM已经就位能直接找到滚动容器并附加上优化逻辑。比起自己写浏览器扩展用户脚本还有一个优势它不需要打包、不需要过应用商店审核、不需要关心扩展签名改脚本点保存刷新页面就能生效。对个人开发者来说这是最低门槛的浏览器端定制方案。2.3 能力边界能改前端行为改不了内部引擎也得承认用户脚本的优化范围是有限的。它能在DOM层面做文章——改样式、改节点结构、节流滚动事件、插入占位元素但读取不了页面内部的闭包状态也改不了底层的渲染引擎和浏览器内核。这意味着我没法做“让豆包只渲染最近100条消息”这种产品级改造只能在既有DOM结构的基础上做缓解优化。提前把这个边界框清楚后面设计具体方案的时候就不容易跑偏目标不是把豆包重写成一个虚拟滚动的完美客户端而是用最小的侵入成本把滚动卡顿从“忍不了”降到“勉强流畅”。3. 优化脚本的核心设计从节流到轻量化整个脚本的设计分为四个层次定位滚动容器、节流滚动事件、防抖处理动态插入的消息节点、对离屏的历史消息做轻量化处理。下面逐个说。3.1 先定位真正的滚动容器很多优化脚本的失败从第一步就错了——以为滚动事件是绑在window或document上的。实际上在豆包这类前后端分离的应用里滚动通常发生在页面某个内部容器上window根本不产生滚动。定位滚动容器的方法不复杂写个小脚本在Console里遍历一遍元素即可document.querySelectorAll(*).forEach((el) { if (el.scrollHeight el.clientHeight 50) { const s getComputedStyle(el); if (s.overflowY auto || s.overflowY scroll || s.overflowY overlay) { console.log(el, el.scrollHeight, el.clientHeight); } } });跑出来的结果里占用容器高度足够大、能产生滚动条的那个元素就是目标。找到之后后续所有对滚动事件的监听都绑在这个元素上而不是window。这个细节决定了脚本有没有真正生效。提示豆包的DOM结构在不同版本里会变建议每次排查都重新跑一遍这段代码确认滚动容器。类名和嵌套层级可以不关心只要确认是哪个元素在真实滚动就行。3.2 滚动事件降频用 requestAnimationFrame 合并处理滚动事件在用户快速拨动滚轮时一秒能触发几十次甚至上百次。如果每次触发都做一次完整的DOM扫描和样式修改优化脚本本身就变成了卡顿制造者。所以第一件事就是把滚动处理改成“一帧只处理一次”。标准做法是用requestAnimationFrame做一个锁const scrollContainer await waitForScrollContainer(); let ticking false; scrollContainer.addEventListener(scroll, () { if (!ticking) { window.requestAnimationFrame(() { applyOptimizations(scrollContainer); ticking false; }); ticking true; } }, { passive: true });这里有两个关键技术点一是passive: true。加了它之后浏览器就知道这个滚动监听器不会调用preventDefault()于是可以走浏览器原生的滚动优化路径不必等待JavaScript执行完再决定是否拦截滚动。这个被动标志是滚动性能的生命线。二是我在监听时也推荐监听滚动容器的scroll事件而不是document因为scroll事件本身不冒泡。真要全局捕获那就只能改成document.addEventListener(scroll, handler, { passive: true, capture: true });但既然我们前面已经精确定位了滚动容器最自然的监听目标就是容器自己没必要走捕获阶段绕圈子。3.3 MutationObserver 防抖优化跟着内容增量走豆包对话是流式生成AI回一句话的过程中DOM节点会被频繁追加。如果每一次节点插入都立刻触发一次消息优化那脚本会在回复生成期间反复扫描整个页面反而卡上加卡。更好的做法是用MutationObserver监听滚动容器内部的节点变化但回调里做一层防抖debounce等一批DOM变化稳定下来之后再执行新消息的轻量化处理let debounceTimer null; const mo new MutationObserver(() { clearTimeout(debounceTimer); debounceTimer setTimeout(optimizeNewMessages, 200); }); mo.observe(scrollContainer, { childList: true, subtree: true });原理很好理解连续追加节点的时候每次都把计时器清零只有停顿超过200毫秒才真正执行一次优化。这样AI在流式输出过程中脚本完全保持安静等到一句话输出结束的间隙才做一次集中处理。200毫秒这个值是我调过的太短会在流式输出中间频繁触发太长则让新消息在屏幕上干等。实测下来200毫秒是性能和响应速度之间的一个合理平衡点。3.4 历史消息轻量化contain 加离屏判定这是整个优化脚本里最核心、也最需要注意的一层。目标很明确已经被用户滚出屏幕、处在视口之外的历史消息浏览器依然在为它们的布局、样式和绘制买单。我们可以在不删除节点、不改变滚动高度的前提下用CSS的contain属性把这些节点的渲染影响隔离掉。contain的作用很好理解它告诉浏览器这个元素内部的布局、样式、绘制都自成一体不会影响外部。加了contain的节点浏览器在处理外层容器重排的时候可以大幅减少重复计算的量。但注意contain有好几个值效果不同风险也不同contain: layout隔离内部布局影响基本安全contain: style隔离计数器和样式副作用也基本安全contain: paint隔离绘制但同时会把子元素的绘制裁剪到容器范围内容易出事。实际操作中我的策略是只有对“已经完全滚出视口、高度不会再变化的消息节点”才加contain: layout style宁可少管一点也不用paint去冒裁剪风险。同时给离屏历史消息内部关闭动画和过渡因为这些动画一旦触发就是白花开销._dbt_scroll_smooth { contain: layout style; } ._dbt_scroll_smooth * { animation: none !important; transition: none !important; }离屏判定可以在rAF节流回调里做遍历消息节点用getBoundingClientRect()判断是否超出视口上下边界function isOffscreen(el) { const rect el.getBoundingClientRect(); return rect.bottom 0 || rect.top window.innerHeight; }不过这里有个效率问题长对话里消息节点成千上万每次都全量遍历依然昂贵。所以我在脚本里维护了一个Set保存已经处理过的节点并且只处理“上一次处理之后新增的消息”。这样就算聊到上万条消息每次滚动也只检查新增的那一小段开销可以忽略不计。3.5 为什么没有用虚拟滚动你可能想问为什么不干脆做虚拟滚动只渲染视口内的消息把滚出去的消息替换成空占位符这不才是终极解法吗理论上的确如此但在这个场景里落地非常难。虚拟滚动需要精确估算每一条消息的高度生成过程中消息高度还在变化滚动位置要保持稳定用户翻上下文时要能准确恢复内容这些在AI流式输出页面里全是雷区。我不建议用Tampermonkey脚本去实现完整虚拟滚动因为一旦算错一行高度整个页面滚动位置就乱套了体验会比卡顿更糟糕。与其冒险重写渲染逻辑不如先靠contain和动画关闭把渲染成本压下来在不动产品逻辑的前提下把体验拉回可用区间。这就是前面说的方案要贴合实际边界。4. 实测效果与踩坑记录脚本写完只是第一步真正花时间的是验证效果和踩坑修复。这部分我记录几个最有价值的实测结论和翻车经历。4.1 验证方法与实测结论要客观判断优化有没有生效只看“感觉流畅了”是不够的。我恢复了一套靠谱的验证流程打开DevTools的Performance面板录制十秒滚动操作观察长任务红色块的频率和数量再看Summary面板里Scripting、Rendering、Painting三者的占比变化。优化前滚动时的长任务数量非常多Rendering和Painting占比将近一半。优化后长任务数量明显下降Rendering的开销显著减少滚动的“粘滞感”基本消失——但是没有完全消失。毕竟底层的DOM节点数量还在那里只要页面没有产品级虚拟列表超长对话里的性能瓶颈就无法彻底根治。脚本做的事情是把能省的开销省掉让频繁滚动时不再出现那种“页面冻结半秒再跳”的极端体验。如果你也想快速验证DevTools的Rendering标签里有一个FPS meter选项打开后能实时看滚动时的帧率。优化前在长对话里可能掉到十几帧优化后通常能稳定在50帧以上更关键的是帧率的波动变得平缓了。4.2 坑1contain: paint 会裁剪浮层和菜单第一版脚本里我图省事直接给所有历史消息加了contain: paint。结果第二天就发现消息里某些浮层元素比如操作菜单、代码块复制按钮的悬浮层在滚动时会出现被截断的诡异现象。这就是contain: paint的副作用——它把子元素的可视范围裁剪到了容器矩形内部浮出容器边界的部分统统被裁掉。修复方法是把paint从contain的取值里去掉只用layout style。效果虽然少了绘制隔离但布局和样式隔离已经能挡住绝大部分的重复计算开销安全性高得多。4.3 坑2滚动高度不能动——别用 display:none 清旧消息优化早期我想过更激进的做法把滚出视口的旧消息直接display: none从渲染树上摘掉。这种方式确实能把DOM开销降得非常低但坑也大——当用户回滚翻看上下文时被隐藏的节点全部白屏内容需要重新渲染。而且更麻烦的是display: none会让元素高度从文档流里消失整个滚动条的总高度瞬间缩水用户滚到一半会发现页面突然“到底了”再往上一翻又“变长”了。滚动位置错乱体验直接崩掉。所以千万不要用隐藏节点的方式去优化滚动。任何要保留内容、又要减少渲染负担的场景contain都比display: none干净得多。4.4 坑3scroll 监听要用 passive容器要找对这是最容易被忽视的脚本基础问题。监听scroll事件时不加{ passive: true }浏览器会因为担心你会在事件里调用preventDefault而放弃一些滚动优化路径结果就是页面反而更卡。另外如果监听对象是window而页面实际滚动容器是内部元素这个监听器就是摆设你还以为脚本生效了实际什么都没发生。这两个问题我都踩过。排查的时候可以在控制台手动触发一次滚动并打印日志确认回调真的被执行了、执行的是预期的事件目标再继续往下调优。4.5 关于脚本维护的现实提醒Tampermonkey脚本不是写一次就一劳永逸的。豆包页面改版、前端框架升级、组件类名变更都可能导致脚本里的选择器失效。我自己的脚本里所有选择器都尽量用特征匹配而不是硬编码类名比如通过“消息节点有某种通用标记”来判断这样抗改版能力强一些。同时我也会在脚本里加几个console.log方便出问题时快速定位。如果你照着这篇文章的思路把脚本写出来了放在Tampermonkey里跑一段时间大概率会遇到某个选择器失配的情况。别慌打开DevTools重新看一眼当前页面的DOM结构把新的类名替换进去就行——用户脚本的维护其实就是这么一件细水长流的事。最后分享一个小技巧不要只把优化逻辑局限在豆包上同样的思路定位滚动容器、滚动事件节流、MutationObserver防抖、离屏节点contain可以直接搬去其他AI对话类网页解决同类滚动卡顿问题。我后来在几个不同的长对话工具页面上都做过类似的注入脚本骨架完全一样只需要调整消息节点的选择器和容器判定条件。这个模式比针对某个站点写死一套脚本要实用得多。
