页面是一帧一帧绘制出来的，当每秒绘制的帧数（FPS）达到 60 时，页面是流畅的，小于这个值时，用户会感觉到卡顿。 1s 60帧，所以每一帧分到的时间是 1000/60 ≈ 16 ms。所以我们书写代码时力求不让一帧的工作量超过 16ms。 帧开始。窗口尺寸变更，页面滚去等的处…

数据环境 高频率:WebSocket按毫秒级接收数据.高性能消耗:接收到的每一条数据都需要进行计算处理 中量数据:需要渲染的数据量很大 要求:实时更新 如果不做优化,会造成浏览器渲染卡顿

使用 React 开发复杂的需求，时常会碰到性能问题。近期做业务过程就遇到一次，页面十分卡顿。此文将笔者排查问题的过程以及性能优化解决方案记录下来跟大家分享。

什么？今天我被 Leader 拉进小黑屋了！“有很多用户吐槽咱的页面太卡了”，本文将从笔者近期参与的一个实际业务需求出发，总结性能优化思路，讲述我在 React 中后台场景下性能问题排查的心路历程

从15个点入手，优化前端大量数据渲染与频繁数据更新引发的浏览器阻塞、卡顿问题，惰性加载、DOM合并、虚拟列表、分批加载、简化结构 、Web Workers 、操作优化、差异更新、逐帧渲染等等...

前言 最近在为公司项目做技术选型的时候，尝试用了许多款React生态里的状态管理工具，到最后来来去去还是觉得Zustand的轻量和使用方式更加舒服，同时为了能够更好的使用和定位问题，也去尝试阅读了一下

一直以来，体验都是得物技术部的关键词之一。本文从本次交易后台性能优化实践出发，同时介绍应用整体架构和设计，希望可以给参与网站性能建设的同学提供一定的学习和参考价值。

Promise已经火了很多年了，网上的各种对Promise的解读也非常之多，从A+规范到手撕源码等系列的文章也是层出不穷，都是在扒一些底层原理，今天就来聊一聊一个比较特殊的问题，那就是一个永远不会完成

直接点击使用皮肤就可以啦，谢谢大家的支持！！！ 前端打包后，静态文件的名字被改成一串 Hash 值（例如 app.abc123.js 或 style.abcdef.css），主要是为了缓存管理和性能优