先用performance面板定位瓶颈:密集layout/paint是特效问题,xhr堆积是ajax问题;再针对性优化css动画与请求逻辑。
界面卡顿怎么快速定位是特效还是 ajax 拖慢的
先别急着关东西,得先分清锅是谁的。浏览器开发者工具的 performance 面板录一段操作,看主线程里密集的是 layout / paint(大概率是 css 动画、阴影、透明度变化这类视觉特效),还是大量 xhr 或 fetch 请求堆积在 network 时间轴上(那就是 ajax 拉垮了)。
常见错误现象:滚动卡、点击按钮后几秒才响应、输入框打字延迟——前两者偏渲染瓶颈,后者偏请求排队或回调处理太重。
- 如果
Performance里看到频繁的Recalculate Style或长Paint块,优先查 CSS 动画、transform缺失硬件加速、或用了box-shadow/filter在滚动容器上 - 如果
Network面板里一堆 pending 的/api/list或/search?q=xxx,且响应时间波动大,说明 AJAX 是瓶颈,关特效没用 - 注意:某些 UI 库(如 Ant Design、Element Plus)默认开启
transition+will-change,小数据量不显,一上真实列表立刻卡
关闭 Chrome/Firefox 里「看起来很酷」但真卡的 CSS 特效
不是所有动画都该关,而是关掉那些浏览器无法用 GPU 加速、又高频触发重排的。比如 opacity 和 transform 本身轻量,但加在 position: relative + 大量子元素的容器上,就会让合成层失效。
实操建议直接改 CSS,别依赖 JS 控制开关:
- 全局禁用过渡:加一条
* { transition: none !important; animation: none !important; }到开发环境样式末尾,立竿见影测效果 - 重点盯住
box-shadow、filter: blur()、backdrop-filter—— 这些在中低端设备上每帧都要重绘整个区域,比多 10 个 DOM 节点还伤 - 用
transform: translateZ(0)或will-change: transform强制提升图层?小心反效果:Chrome 会为每个加了它的元素单独建合成层,内存暴涨反而拖慢
AJAX 加载慢,光关特效没用,得动请求逻辑
用户点一下就发 5 个 GET /user/profile、GET /user/permissions、GET /user/notifications,再串行等,卡是必然的。优化核心不是“少发”,而是“发得更聪明”。
常见错误:用 async/await 串行写法硬等每个接口返回;或把所有 fetch 放 Promise.all 里,结果一个超时全挂。
- 合并请求:后端提供
/user/summary接口,一次返回 profile + permissions + notifications,前端少 2 次 RTT - 取消冗余请求:用户快速切换 Tab 时,前一个
fetch还没回来,新请求已发,老请求必须AbortController主动 abort,否则它还在后台占连接、吃内存 - 防抖搜索:输入框
input事件里,别每次打字都调fetch('/search?q='+val),用setTimeout+clearTimeout控制最小间隔(比如 300ms) - 缓存策略:对不变或低频变的数据(如省市区列表),加
cache: 'force-cache'或用localStorage存 10 分钟,别每次都走网络
Vue/React 里“关特效”容易被忽略的底层陷阱
框架层封装了一层又一层,你以为关了 fade 动画就完事,其实 v-if 切换组件、key 反复变化、甚至 useEffect 里没清理定时器,都会让 DOM 批量重建,比 CSS 动画还卡。
尤其要注意 SSR 渲染后客户端激活(hydration)阶段的卡顿,那不是特效问题,是 JS 执行阻塞了渲染线程。
- Vue 中避免在循环里用
v-if控制单个 item 显隐,改用v-show—— 后者只切display,不销毁重建 VNode - React 中别在
map里动态生成key={Math.random()},key 不稳定会导致整块列表重渲染 - 所有轮询(
setInterval)、事件监听(addEventListener)必须在组件卸载时清理,漏掉一个就可能让已卸载组件持续触发 setState,引发内存泄漏+卡顿 - Chrome DevTools 的
Memory面板拍个堆快照,搜Detached,如果有大量 detached DOM 节点,基本就是事件监听没卸载干净
卡顿从来不是单一原因,关特效或减请求只是表象。真正要盯的是主线程是否被 JS 长任务堵死、合成层是否被滥用、以及每个请求和渲染帧背后的真实开销。这些地方一松动,卡顿就松动。











