性能优化最怕两种极端：一种是完全不关注，页面慢了才到处打补丁；另一种是只会背术语，见到卡顿就机械套“虚拟列表、节流、防抖、懒加载”。真正有用的性能治理，从来不是背优化清单，而是先知道性能瓶颈通常出现在哪些层，再决定用什么策略处理。
这一篇会把浏览器渲染性能的几条核心线重新捋顺：DOM 与样式变更为什么可能引发布局成本，长任务为什么直接伤害交互体验，节流和防抖适用于哪些高频场景，首屏优化为什么不只等于“包小一点”。这些内容串起来，才能形成真正能落地的性能判断。
为什么前端性能问题大多绕不开主线程？
因为浏览器中的大量关键工作都依赖主线程：JavaScript 执行、事件处理、样式计算、布局、绘制、部分资源协调都与它紧密相关。一旦主线程被长时间占满，点击、滚动、输入和渲染反馈就会明显延迟。
这也是为什么你看到页面“卡”，第一反应不应该只是怀疑网络慢，而要先想：是不是有太多同步计算，是不是在高频交互里做了重工作，是不是渲染链路被拖住了。
重排和重绘，项目里应该怎么理解？
重排通常意味着布局重新计算，重绘则侧重视觉更新。对开发者来说，最关键的不是学术定义，而是知道某些 DOM 或样式变更比你想象中更贵。特别是当你频繁读布局、再写样式、再读再写时，很容易造成渲染抖动。
所以渲染优化的一个重要原则是：减少无序读写，尽量批量处理更新。很多性能问题不是单次操作太慢，而是操作时机和频率设计得很差。
长任务为什么会让页面“看起来像死了”？
长任务最大的伤害在于，它会让用户输入和浏览器渲染都排队等待。用户可能点了按钮、滚了页面、输入了字符，但因为主线程没空，反馈迟迟出不来，于是体验就像页面失灵。
这时候你要思考的通常不是“能不能优化一两行代码”，而是：
- 这段逻辑能不能拆小；
- 能不能延后到不影响当前交互的时机；
- 能不能并行或挪到 Worker；
- 能不能减少不必要计算。
性能治理很多时候不是“更快的代码”，而是“更合理的时机”。
为什么性能优化一定要形成“定位 -> 修改 -> 回看”的闭环？
因为性能问题非常容易被“感觉”误导。你以为是列表渲染太慢，结果真正卡的是接口返回后的一次性数据转换；你以为是脚本太大，结果真正阻塞的是第三方资源和字体加载。如果没有先定位、再修改、再回看结果，优化就很容易变成无效忙碌。
真正稳的性能治理通常都是闭环式的，而不是改完就默认已经更好了。
节流和防抖到底分别适合什么？
节流适合持续高频触发但又希望按一定频率响应的场景，例如滚动监听、窗口变化、鼠标移动；防抖适合用户停止一段时间后再执行的场景，例如搜索输入联想、表单延迟校验。它们本质上都在控制频率，但交互含义完全不同。
如果不区分场景，很容易出现一种情况：性能指标看似好了，用户体验却更差了。比如本该实时反馈的场景被过度延迟，本该只保留最后一次的场景却重复触发很多次。
首屏优化为什么不能只看包体积？
包体积当然重要，但首屏体验还和很多因素有关：
- 资源加载顺序是否合理；
- 是否存在阻塞渲染的脚本；
- 首屏是否加载了太多当前根本不需要的代码；
- 接口数据是否成为阻塞点；
- 图片、字体、第三方脚本是否过重。
这意味着，首屏优化是一条完整链路，不是单点指标游戏。很多项目压缩了几十 KB 却几乎没改善用户体验，因为真正阻塞的不是那里。
列表、表单和后台页面为什么特别容易出性能问题？
因为这些页面往往同时具备几个高风险因素：节点多、状态多、交互频繁、筛选和排序逻辑复杂，还经常伴随图表、弹窗、表格和上传能力。如果没有提前做结构分层，很容易出现一次状态变更牵动大面积更新、一次筛选操作触发多处重复计算、一次滚动加载把主线程拖满的情况。
所以在中后台和复杂页面里，性能治理往往不是局部优化，而是结构优化。你需要提前考虑哪些状态应该局部化，哪些组件可以拆分，哪些数据处理应该缓存，哪些大列表该延迟或分段渲染。
为什么有些“优化”会制造新的回归风险？
因为性能优化常常会改执行时机、缓存策略和渲染频率，这些改动本身就可能影响业务正确性。比如节流后某些交互反馈变慢，缓存后某些数据更新不及时，延迟渲染后某些空态或加载态判断变复杂。只看性能数字、不看交互正确性，很容易顾此失彼。
所以成熟的性能优化，通常会同时关注体验回归和功能回归，而不是只追求单点指标。
性能优化最重要的是“测量意识”
没有测量的优化，往往只是感觉。你必须学会借助浏览器开发者工具去看长任务、布局抖动、资源时序和脚本耗时。只有先定位瓶颈，才知道该优化代码、结构、时机还是资源。
这是性能优化和很多“经验主义技巧”的分水岭。成熟工程实践强调的是证据，不是猜测。
优化的优先级应该怎么排？
一个很实用的原则是：优先解决用户体感最明显、收益最大的瓶颈，再处理边角细节。通常顺序会是先看首屏和可交互时间，再看高频交互卡顿，再看大列表和复杂页面的局部热点，最后再处理零碎的微优化。
如果一开始就沉迷于很细的代码级别优化，却放着大资源阻塞、长任务和重复渲染不管，往往投入很多却收益有限。
团队里怎样避免“人人都在凭经验优化”？
一个很实际的方式是，把常见性能问题和定位路径沉淀成共识：遇到页面卡顿先看 Performance 面板，遇到高频事件先看是否存在不必要计算，遇到首屏慢先看资源与请求时序，遇到后台列表卡先看状态粒度和渲染范围。只要团队对排查路径有基本共识，性能治理就不容易沦为口水战。
常见误区
这一章最常见的误区包括：
- 一卡就上节流防抖，而不先定位主线程瓶颈；
- 把重排重绘当成背概念题，不放回真实渲染链路；
- 只盯包体积，不看请求时序和首屏阻塞资源；
- 忽略第三方脚本和大图资源的影响；
- 只做代码层优化，不做交互和结构层优化。
写在最后
前端性能不是“锦上添花”，而是用户是否愿意继续使用产品的基础条件。真正有效的性能优化，永远建立在对主线程、渲染成本、资源加载和交互时机的整体判断之上。下一篇我们继续拆 JavaScript 工程化，把构建、环境变量和产物管理讲得更细。