前言
上章梳理了浏览器三大核心内容:渲染引擎、渲染过程、兼容性。其中渲染过程的回流与重绘是CSS中很重要的概念。了解与认识它们,可编写性能更好的代码。
有些同学说,怎么不开发完毕再找时间优化代码?试问有多少同学在项目开发完毕会拿出空余时间重构或优化代码。何必不在编码时对代码实现一次完美的优化?接着隆重介绍本章两位主角。
回流
回流又称重排,指改变几何属性的渲染。感觉“回流”较高大上,后续统称回流吧。
可理解为将整个网页填白,对内容重新渲染一次。只不过以人眼的感官速度看浏览器回流是不会有任何变化的,若你拥有闪电侠的感官速度看浏览器回流(实质是将时间调慢),就会发现每次回流都会将网页清空,从左上角第一个像素点从左到右从上到下这样一点一点渲染,直至右下角最后一个像素点。每次回流都会呈现该过程,只是感受不到而已。
渲染树的节点发生改变,影响了节点的几何属性,导致节点位置发生变化,此时就会触发浏览器回流并重新生成渲染树。回流意味着节点的几何属性改变,需重新计算并生成渲染树,导致渲染树的全部或部分发生变化。
重绘
重绘指改变外观属性而不影响几何属性的渲染。相比回流,重绘在两者中会温和一些,后续谈到的CSS性能优化就会基于该特性展开。
渲染树的节点发生改变,但不影响节点的几何属性。由此可见,回流对浏览器性能的消耗高于重绘且回流一定伴随重绘,重绘却不一定伴随回流。
为何回流一定伴随重绘?整个节点的位置都变了,肯定要重新渲染它的外观属性啊!
属性分类
以下对一些常见几何属性与外观属性分类,其实同种分类的属性都有一些共同点,大家可自行感受。推荐一个属性渲染状态可视化的网站CssTriggers,可查看每个属性在渲染时产生的影响。
- 几何属性:包括布局、尺寸等可用数学几何衡量的属性
- 布局:
display、float、position、list、table、flex、columns、grid等 - 尺寸:
margin、padding、border、width、height等
- 布局:
- 外观属性:包括界面、文字等可用状态向量描述的属性
- 界面:
appearance、outline、background、mask、box-shadow、box-reflect、filter、opacity、clip等 - 文字:
text、font、word等
- 界面:
如何理解回流重绘
有无更好的方式可帮助理解回流重绘?答案是有的。
某一天星巴克发行一套很有纪念价值的杯子,男同胞们为了买到心仪的杯子给女友当惊喜礼物,通宵达旦搬张板凳去星巴克门口排队。此时形成的队伍是有序的,毕竟大家都是文明人,不可能随便插队吧,先到先拿,这道理谁都懂!
可是总有一些人不按常理出牌,别人排队排得那么辛苦,他一到来就仗着自己有钱有势人多马多,插队到最前面。若他插队成功,那后面的人都要往后挪一位。此时队伍就要重新往后挪,甚至引发多人斗殴,但混乱的情况总会被控制下来,此时就得重新排队,而原先的队伍顺序经过这次斗殴就可能不根据原先的队伍顺序排队了。几何属性变了,就要重新排队,这就是回流。重新排队啊!
一位漂亮妹纸排队排得久肚子呱呱叫,就与另一位同伴交换,她去买早餐,而这位同伴代替她的位置。各位男同胞可能发现这位妹纸更漂亮了。没错,外观属性改变了,变漂亮了,但除了妹纸,其余人的位置与顺序都无发生变化,所以肯定不会发生上述重新排队的情况。外观属性变了,但几何属性未变,这就是重绘。无需重新排队,还有漂亮妹纸看,大家都很乐意啊!
性能优化
回流重绘在操作节点样式时频繁出现,同时也存在很大程度上的性能问题。回流成本比重绘成本高得多,一个节点的回流很有可能导致子节点、兄弟节点或祖先节点的回流。在一些高性能电脑中可能无影响,但回流发生在手机中(明摆说某些安卓手机),就会减缓加载速度,增加电量消耗。
在上章引出一个定向法则:回流必定引发重绘,重绘不一定引发回流,可利用该法则解决一些因为回流重绘而引发的性能问题。在优化性能前,需了解什么情况可能产生性能问题,以下罗列一些常见情况。
- 改变窗口大小
- 修改盒模型
- 增删样式
- 重构布局
- 重设尺寸
- 改变字体
- 改动文字
很多同学可能不知,回流重绘其实与浏览器的事件循环有关,以下源自对HTML文档的理解。
- 浏览器刷新频率为
60Hz,即每16.6ms更新一次 - 执行事件循环完成微任务
- 判断
document是否需更新 - 判断
resize/scroll事件是否存在,存在则触发事件 - 判断
Media Query是否触发 - 更新动作并发送事件
- 判断
document.isFullScreen是否为true(全屏) - 执行
requestAnimationFrame回调 - 执行
IntersectionObserver回调 - 更新界面
上述过程就是浏览器每帧可能会做到的事情,若在一帧中有空闲时间,就会执行requestIdleCallback回调。
回到正题,通过定向法则回流必定引发重绘,重绘不一定引发回流可知,尽量减少回流重绘,就是CSS性能优化中一个很好的指标。
如何减少和避免回流重绘
使用visibility:hidden替换display:none
从以下方面对比display:none与visibility:hidden,display:none简称DN,visibility:hidden简称VH。
- 占位表现
- DN不占据空间
- VH占据空间
- 触发影响
- DN触发回流重绘
- VH触发重绘
- 过渡影响
- DN影响过渡不影响动画
- VH不影响过渡不影响动画
- 株连效果
- DN后自身及其子节点全都不可见
- VH后自身及其子节点全都不可见但可声明子节点
visibility:visible单独显示
两者的占位表现、触发影响和株连效果就能说明VH代替DN的好处,从两者区别中就能找出恰当的答案了。
使用transform代替top
top是几何属性,操作top会改变节点位置引发回流,使用transform:translate3d(x,0,0)代替top,只会引发图层重绘,还会间接启动GPU加速。
避免使用Table布局
牵一发而动全身用在Table布局身上就很适合了,可能很小的一个改动就会造成整个<table>回流,有兴趣的同学可用Chrome Devtools的Performance调试看看,在此就不演示了。
通常可用<ul>、<li>和<span>等标签取代table系列标签生成表格。
避免规则层级过多
浏览器的CSS解析器解析css文件时,对CSS规则是从右到左匹配查找,样式层级过多会影响回流重绘效率,建议保持CSS规则在3层左右。
避免节点属性值放在循环中当成循环变量
for (let i = 0; i < 10000; i++) {
const top = document.getElementById("css").style.top;
console.log(top);
}
呵呵,每次循环操作DOM都会发生回流,应在循环外部使用变量保存一些不会变化的DOM映射值。
const top = document.getElementById("css").style.top;
for (let i = 0; i < 10000; i++) {
console.log(top);
}
动态改变类而不改变样式
不要尝试每次操作DOM改变节点样式,这样会频繁触发回流。
更好的方式是使用新的类名预设节点样式,在执行逻辑操作时收集并确认最终更换的类名集合,在适合时机一次性动态替换原来的类名集合。有点像vue的依赖收集机制,不知这样描述会不会更易理解。
大家可研究强大的classList,它能满足我所说的需求。
将频繁回流重绘的节点设置为图层
渲染过程最后一步,提到将回流重绘生成的图层逐张合并并显示在屏幕中。可将其理解成Photoshop的图层,若不对图层添加关联,图层间是不会互相影响的。同理,在浏览器中设置频繁回流或重绘的节点为一张新图层,那新图层就能够阻止节点的渲染行为影响别的节点,这张图层中如何变化都无法影响到其他图层。
设置新图层有两种方式,将节点设置为<video>或<iframe>,为节点声明will-change。will-change是一个很叼的属性,第12章会详细讲述。
使用requestAnimationFrame作为动画帧
动画速度越快,回流次数越多,上述提到浏览器刷新频率为60Hz,即每16.6ms更新一次,而requestAnimationFrame()正是以16.6ms的速度更新一次,所以可用requestAnimationFrame()代替setInterval()。
属性排序
在进入属性排序的话题前,先来看看以下代码。
.elem {
width: 200px;
background-color: #f66;
align-items: center;
color: #fff;
height: 200px;
justify-content: center;
font-size: 20px;
display: flex;
}
.elem {
display: flex;
justify-content: center;
align-items: center;
width: 200px;
height: 200px;
background-color: #f66;
font-size: 20px;
color: #fff;
}
若不特别指明,可能大家觉得这两段代码无异样,顶多就是属性顺序不同,但仔细观察两段代码,就会发现第一段代码好像无根据地随便排列,第二段代码好像根据某些规范顺序排列。
属性排序指根据预设规范排列属性。提供一个预设规范,根据该规范以一定的顺序排列所有属性。
曾经我也是随机排列属性顺序,想到什么写什么,反正能实现就行,但反过来看,随意真的好吗?每次维护代码都需反复确认某个属性是否存在,混乱的属性排序让我有时无法在脑海中构思出更好的排版,所以我会下意识了解与认识属性排序,利用一些预设规范合理管理我的代码。
曾经有一个著名的网站CSSTricks做了一份属性排序的调查问卷,调查结果如下。
- A:随意排序占
39% - B:根据类型排序占
45% - C:根据单行代码长度排序占
2% - D:根据属性字母排序占
14%
发现B选项占比最多,很可惜,这份调查问卷都是针对国外开发者,所以我在自己的微信粉丝群中发起了调查问卷,结果还是B选项占比最多。
因为人数过少,怕可信度不高,所以我又去Github中随机寻找200个国内项目,通过一个周末的时间细心对比了所有css文件,统计出以下结果。
- A:随意排序占
38% - B:根据类型排序占
58% - C:根据长度排序占
1% - D:根据字母排序占
3%
结果还是B选项占比最多,不过这也说明不了什么问题。毕竟CSS编码的灵活性比JS编码更高,随意也是一件不错的事情。可能就是在维护代码时眼花缭乱,问了一位编码很随意的同事(每次开发项目时都把Lint关掉,搞到每次Commit代码都手忙脚乱),他如实说出了随便排列属性顺序经常会重复编写某些属性,导致属性冗余。
其实属性排序有很多优点。
- 突出
CSS艺术之美 - 防止属性重复编写
- 快速定位到问题代码
- 锻炼无视图架构网页的能力
- 快速在脑海中构思排版与布局
- 提高代码的可读性与可维护性
很多开发者都会给属性做排序,可见大家对属性排序都是持有肯定的态度,只在排序方式中会有一定的分歧。根据长度排序与根据字母排序是较简单易用的排序方式,但忽略了属性间的关联性。根据类型排序又会分为很多种,主要还是围绕着盒模型。
- 根据类型排序
- 根据长度排序
- 根据字母排序
属性排序并不会影响样式的功能与性能,只是让代码看起来更简洁更规范。
想法
我有一个想法,就是根据回流重绘的原理,涉及几何属性与外观属性,结合盒模型与从外到里的结构排序属性。综合太极图的哲学思想,将一些回流的几何属性排在最前面,毕竟这些属性决定了节点的布局、尺寸等与本质有关的状态,有了这些状态才能派生出节点更多的外观属性,逐一组成完整的节点。
好比一座摩天大楼的构筑过程,从打桩(存在)、搭设(布局)、主体(尺寸)、砌体(界面)、装修(文字)、装潢(交互)到验收(生成一个完整的节点),每步都基于前一步作为基础才能继续下去。
太极图哲学思想:太极生两仪,两仪生四象,四象生八卦,从无极生太极开始,一直通过物质派生而构筑一个完整的立体结构,这一过程又显然是一个立体并包括位次顺序的四维关系。
理解
若编写一个节点样式,先声明display还是width?display决定了该节点的开始状态,是none,还是block,还是inline,还是其他。若先声明width,万一后续声明display:inline表示该节点是行内元素,行内元素无法显式声明宽高,那width不是白白浪费了?所以推荐声明display在首位,毕竟它声明了该节点最开始的状态:有还是无。
排序
根据上述想法与理解,我将属性排序根据布局 → 尺寸 → 界面 → 文字 → 交互的方式顺序定义。把交互属性放到后面是因为transform与animation会让节点重新生成新图层,新图层不会对其他图层造成影响。
布局属性
- 显示:
display、visibility - 溢出:
overflow、overflow-x、overflow-y、scroll-behavior、scroll-snap-align - 浮动:
float、clear - 定位:
position、left、right、top、bottom、z-index - 列表:
list-style、list-style-type、list-style-position、list-style-image - 表格:
table-layout、border-collapse、border-spacing、caption-side、empty-cells - 弹性:
flex-flow、flex-direction、flex-wrap、justify-content、align-content、align-items、align-self、flex、flex-grow、flex-shrink、flex-basis、order - 多列:
columns、column-width、column-count、column-gap、column-rule、column-rule-width、column-rule-style、column-rule-color、column-span、column-fill、column-break-before、column-break-after、column-break-inside - 格栅:
grid-columns、grid-rows
尺寸属性
- 模型:
box-sizing - 边距:
margin、margin-left、margin-right、margin-top、margin-bottom - 填充:
padding、padding-left、padding-right、padding-top、padding-bottom - 边框:
border、border-width、border-style、border-color、border-colors、border-<direction>-<param> - 圆角:
border-radius、border-top-left-radius、border-top-right-radius、border-bottom-left-radius、border-bottom-right-radius - 框图:
border-image、border-image-source、border-image-slice、border-image-width、border-image-outset、border-image-repeat - 大小:
width、min-width、max-width、height、min-height、max-height
界面属性
- 外观:
appearance - 轮廓:
outline、outline-width、outline-style、outline-color、outline-offset、outline-radius、outline-radius-<direction> - 背景:
background、background-color、background-image、background-repeat、background-repeat-x、background-repeat-y、background-position、background-position-x、background-position-y、background-size、background-origin、background-clip、background-attachment、bakground-composite - 遮罩:
mask、mask-mode、mask-image、mask-repeat、mask-repeat-x、mask-repeat-y、mask-position、mask-position-x、mask-position-y、mask-size、mask-origin、mask-clip、mask-attachment、mask-composite、mask-box-image、mask-box-image-source、mask-box-image-width、mask-box-image-outset、mask-box-image-repeat、mask-box-image-slice - 滤镜:
box-shadow、box-reflect、backdrop-filter、mix-blend-mode、filter、opacity - 裁剪:
object-fit、clip、clip-path - 事件:
resize、zoom、cursor、pointer-events、touch-callout、user-modify、user-focus、user-input、user-select、user-drag
文字属性
- 模式:
line-height、line-clamp、vertical-align、direction、unicode-bidi、writing-mode、ime-mode - 文本:
text-overflow、text-decoration、text-decoration-line、text-decoration-style、text-decoration-color、text-decoration-skip、text-underline-position、text-align、text-align-last、text-justify、text-indent、text-stroke、text-stroke-width、text-stroke-color、text-shadow、text-transform、text-size-adjust - 字体:
src、font、font-family、font-style、font-stretch、font-weight、font-variant、font-size、font-size-adjust、color - 内容:
tab-size、overflow-wrap、word-wrap、word-break、word-spacing、letter-spacing、white-space、caret-color、quotes、content、content-visibility、counter-reset、counter-increment、page、page-break-before、page-break-after、page-break-inside
交互属性
- 模式:
will-change、perspective、perspective-origin、backface-visibility - 变换:
transform、transform-origin、transform-style - 过渡:
transition、transition-property、transition-duration、transition-timing-function、transition-delay - 动画:
animation、animation-name、animation-duration、animation-timing-function、animation-delay、animation-iteration-count、animation-direction、animation-play-state、animation-fill-mode
到此已整合了95%的属性,可满足很多属性排序的需求。其他未列入的属性,可根据自身使用习惯增加与调整。
配置
编码时纯粹靠脑海中根据预设规范排列属性肯定存在难度,也不方便频繁修改代码。记住这些属性排序估计很费脑力,这么多属性,肯定使用工具自动化处理啊!
为了提供通用性,我开源了一个集成Stylelint与Eslint的VSCode配置工具@yangzw/bruce-std,配合VSCode插件为用户提供前端文件的代码校验、代码修复和错误提示的功能。
打来CMD工具,执行以下命令安装bruce-std,具体如何使用请查看文档详情。好用的话给我一个Star作为鼓励哈!
npm i -g @yangzw/bruce-std
到了配置插件这一步,其实操作不复杂,直接把过程罗列出来,跟着我一步一步完成。
- 打开
VSCode - 选择左边
工具栏的插件,搜索并安装Stylelint,安装完毕重启VSCode - 选择
文件 → 首选项 → 设置,设置中可选用户或工作区- 用户:配置生效后会作用于全局项目
- 工作区:配置生效后只会作用于当前打开项目
- 点击
设置右上角中间图标打开设置(json),打开的对应文件是settings.json - 加入以下内容并重启
VSCode:为了保障每次改动都能正常格式化代码,必须重启VSCode
{
// 默认自定义配置
"css.validate": false,
"less.validate": false,
"scss.validate": false,
"editor.codeActionsOnSave": {
"source.fixAll.stylelint": true
},
// 扩展自定义配置
"stylelint.configBasedir": "path/@yangzw/bruce-std",
"stylelint.configFile": "path/@yangzw/bruce-std/stylelint/stylelintrc.js",
"stylelint.customSyntax": "postcss-scss", // 可变❗
"stylelint.stylelintPath": "path/@yangzw/bruce-std/node_modules/stylelint",
"stylelint.validate": ["html", "css", "scss", "less", "vue"]
}
上述配置的path为@yangzw/bruce-std模块所在的Npm根目录,可执行npm config get prefix获取Npm根目录并替换path。
- 执行
npm config get prefix获取Npm根目录,例如是E:/Node/prefix/node_modules - 将上述配置的
path替换为E:/Node/prefix/node_modules
校验不同类型代码需实时修改stylelint.customSyntax的值。
- CSS/SCSS:
postcss-scss - CSS/LESS:
postcss-less - HTML/VUE:
postcss-html
上述步骤操作完毕就可愉快地敲代码了。每次保存文件可自动格式化代码,该功能不仅将代码根据规范整理与排序,甚至尽可能根据修复方案格式化出正确的代码。

另外就是一些概念性的东西,感觉解释的太生硬了
当你执行 npm config get prefix 显示没有获取到路径的时候。 运行 npm root -g 就可以获取到完整的路径了, @yangzw 在 node_modules 文件夹里
cmd + , 就可以打开设置,左上角这个标,点进去就是 settings.json
感谢作者大大的答复!!!
支持正版从我做起
这里看不懂是怎么操作的,我压根找不到什么用户什么的,我打开了全局的setting.json配置文件把代码加上去,但是颜色是灰色的,我不知道为什么。