2024年，一个前端团队花了两周优化首屏加载，最后发现瓶颈出在一张卡片组件的动画上。改完这一行代码，渲染时间从180ms降到47ms。
问题不是图片太大，也不是JS太臃肿，是浏览器的"过度热心"。
CSS的contain属性2016年就写进了规范，但直到最近才被大规模用起来。它解决的是浏览器渲染机制的一个底层矛盾：默认情况下，页面任何一个元素的变化，浏览器都要重新计算整个布局树——哪怕你只改了一个按钮的颜色。
这就像你在家换了个灯泡，物业却重新检查整栋楼的电路。
浏览器为什么"管太宽"
CSS的渲染流程分几步：样式计算、布局（Layout）、绘制（Paint）、合成（Composite）。麻烦出在第二步。当你修改某个元素的宽度或位置，浏览器必须回答一个问题：这会影响到其他元素吗？
为了保险起见，答案是"会"。于是整个页面重新布局。
前端工程师@Surma在Chrome团队时做过测试：一个2000个节点的页面，修改最深层的一个div的margin，触发重排的范围覆盖全部节点。耗时随页面复杂度指数级增长。
「我们做过一个内部项目，列表页卡到掉帧，最后定位到一个轮播组件。它每3秒自动切换，每次切换整个页面闪一下重绘。」一位字节跳动的前端工程师在2023年的技术分享中提到，「加了contain: layout paint之后，GPU占用从40%降到12%。」
contain的四种"隔离级别"
contain不是开关，是四个独立维度的组合：
layout —— 元素的布局不影响外部，外部的布局也不影响它。相当于告诉浏览器："这个盒子的尺寸和位置，别管外面怎么变，按我自己的规则算。"
paint —— 元素的绘制被裁剪到自身边界。子元素溢出部分不会被绘制，也不会触发外部重绘。适合那种内部动画很花哨、但不想污染周边的组件。
size —— 元素的尺寸计算不依赖子元素。这意味着你可以先渲染父容器，再慢慢填充内容，而不必等子元素全部就位。对骨架屏和流式布局很关键。
style —— 元素的样式（主要是计数器、引用等CSS属性）不穿透到外部。这个用得最少，但在复杂文档结构里能避免意外副作用。
四个全选？写contain: strict就行。这是大多数组件的"安全模式"。
实战中的取舍
不是每个div都值得加contain。它是有代价的：创建新的渲染层需要内存，过度使用会增加合成器的工作压力。
Chrome的渲染团队给过一个经验法则：组件边界清晰、内部变化频繁、对外影响可控的节点，优先考虑。典型场景包括：无限滚动列表的单个条目、弹窗/抽屉等浮层、第三方嵌入的iframe替代品、复杂图表和动画区域。
反例也有。如果你给一个高度依赖父容器宽度的弹性子元素加contain: layout，布局会直接崩掉——因为它真的需要知道外面有多宽。
2023年，Vercel的Next.js团队在核心组件库里全面启用contain。他们的基准测试显示，大规模列表的交互响应速度提升了2-4倍，内存占用反而下降了约15%。原因是减少了不必要的重排缓存。
现代性能优化的"隐形战场"
前端性能优化正在从"资源层面"转向"渲染层面"。压缩图片、代码分割、懒加载这些手段已经普及，边际收益越来越低。
真正的瓶颈藏在浏览器的主线程调度里。
CSS contain、content-visibility、will-change这些属性，本质上是把一部分调度决策权从浏览器手里拿回来，交给开发者。你比浏览器更清楚哪些组件是独立的。
「我们内部有个说法：不加contain的组件，默认就是'全局变量'。」一位蚂蚁集团的技术专家在D2前端技术论坛上提到，「现在代码评审会专门检查这个，比查console.log还严格。」
浏览器厂商也在推这件事。Chrome DevTools的Performance面板现在会标红那些"不必要的重排"，并提示是否适合加contain。Firefox和Safari的实现进度稍慢，但基础支持已经齐全。
一个值得注意的细节：contain和Shadow DOM的封装理念是呼应的。Web Components的自定义元素天然带有样式隔离，但布局隔离仍然需要显式声明。两者结合，才能真正做到"组件即边界"。
回到开头那个案例。字节跳动的团队最后把contain写进了组件库的脚手架模板，每个新组件默认带contain: layout paint style，需要打破隔离时再手动移除。这比写文档、做培训都管用。
你的项目里，有多少"全局变量"式的组件在偷偷拖累性能？
热门跟贴