[转载]管理好页面图片，减小页面加载时http连接，优化页面 - Web前端当前位置:& &&&[转载]管理好页面图片，减小页面加载时http连接，优[转载]管理好页面图片，减小页面加载时http连接，优化页面&&网友分享于：&&浏览：0次[转载]管理好页面图片，减少页面加载时http连接，优化页面
点我查看原文
浏览器渲染页面的时候，遇到图片标签或者css中的背景图片设置，先会到本地缓存中寻找是否已经下载了这张图片，如果已经下载过了就直接从缓存中加载；否则会到图片指定的路径下载到本地缓存。而且这种下载是阻塞式的（部分浏览器内核已经实现异步加载图片。比如火狐）。也就是说在下载这些图片的时候，页面渲染处于暂停状态，必须等到图片下载完成了再继续渲染。
所以，如果一个页面中有大量的图片需要加载，先不说图片本身的大小对下载速度的消耗，每次图片下载都是一次http请求，都要经历3次协议握手，这对页面加载速度的影响是显而易见的！！如果图片再大一点，每张一两百K，杯具了……
那么如何管理这些页面图片、背景图片以加快页面渲染速度呢？下面，我将我的一些经验分享给大家。
一、页面图片处理
1.延迟加载
1)所需技术:
先使用一种空白的图片grey.gif代替指定的图片元素（lazyLoad允许指定页面上那些图片需要延迟加载。比如$("img.lazy").lazyload()表示class为lazy的图片延迟加载。$("img ").lazyload()表示所有图片都延迟加载）。
当页面滚动条滚动到该图片时，再将图片的src还原。
有时，你可能浏览某些网页时，滚动页面滚动条时发现有些图片显示为正在加载。就是使用这种技术实现的。
&img src="test.jpg" alt=""/&
jQuery(document).ready(function() {
$("img").lazyload();//更多的配置请参考官网
注意：lazyload好处在于并不会影响页面元素的开发。你不需要在img标签上附加任何的配置。lazyLoad会自动将图片的src设置为空白图片 grey.gif。
2.异步加载
异步加载跟延迟加载有点不一样。延迟加载是当滚动条滚动到图片位置时，重新加载图片；而异步加载就是页面加载完成后，将指定的图片重新加载。
跟延迟加载一样，需要将图片的src属性先指定为一张空白的图片。然后将图片本来的地址放入 lazyload 属性（属性名称可以自己定义）。页面加载完成后，使用javascript将图片的src属性替换为data属性的地址。这有点像是在模拟火狐浏览器异步加载图片的行为，呵呵。
&img src="grey.gif" alt="" lazyload="test.jpg"/&
注意：这里需要事先将src属性设置为grey.gif，并将真实的src放入lazyload属性。
下面使用javascript替换src：
jQuery(document).ready(function() {
$("img:[lazyload]").each(function(){
$(this).attr("src",$(this).attr("lazyload"));
二、背景图片处理
1.不需要平铺的背景图片
将这些图片进行归类，icon的一类、button的一类、其他背景素材一类……
归类好后，将他们分别放入一张大的png背景图片中
需要使用背景的地方，通过css的background-position进行指定背景位置
.bg1{background: url(/img/imgBg.png) no-repeat -100px -50 overflow:}
2.需要平铺的背景图片
将横向平铺的和纵向平铺的分别归类
将这些图片剪裁成等宽（横向平铺）、等高（纵向平铺）。最好宽度或者高度设为1px
将这些图片放入一张大的png图片中
使用css的background-position进行指定背景位置，并设置background-repeat为repeat-x或者repeat-y
.bg2{background: url(/img/imgBg_repeatX.png) repeat-x 0px -50}
定义一组公共样式：bg、repeatXBg、repeatYBg，指定背景图片路径
在需要使用背景的css中直接指定background-position
.bg{background: url(/img/background/base.png) no- overflow:}
.repeatXBg{background: url(/img/background/base_repeatX.png) repeat-}
.repeatYBg{background: url(/img/background/base_repeatY.png) repeat-}
页面样式：
bg1{background-position: 0px -33 }
repeatXBg1{background-position: 0px -33 }
repeatYBg1{background-position: -33px 0 }
&div class="bg bg1"&&/div&
&div class="repeatXBg repeatXBg1"&&/div&
&div class="repeatYBg repeatYBg1"&&/div&
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有前端开发技术（5）
记得前百度工程师张云龙说过，页面前端优化问题绝对不仅仅是为页面提速的问题，更是工程的问题，有兴趣的同学可以阅读《》。里面有提到根据雅虎14条优化原则，《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点梳理出来的优化方向：
张云龙先生提及到的优化方向从提出到现在虽已相隔两年时间，前端技术也在飞速发展，但其提到的工程化思想仍是前端优化的一个大方向，亦有很大的指导意义。
当然这是另外更大的话题了，这篇文章并不是将本次的优化点按照萌妹子暖暖写的《》一一列出（当然并没有那么多，前端优化永远写不完，写不完：-
O），而是重点结合项目总结这一次优化中如何寻找优化点以及收益比较大的常见方法，希望可以对遇到相似问题的同学有帮助，前端大神可轻轻淡笑而过。
我们所说的高清图一般是指至少具有 Retina 屏级别精度的图片，就是平时所说的『2x』图。对于高清图的适配，一般会根据图片特点以及项目实际情况去制定适配方案。
纯色图一般应用到装饰性的小 icon，如侧导航的标题 icon：
此类图标由单色组成，可以根据一定的绘制规则制成 iconfont 图标，iconfont 的图标具有矢量性，其大小和颜色可以都可以通过样式来控制。
新版首页出现了 33 个单色图标，这些图标复用性很强，同一个图标在不同页面都有出现，而且同一个图标还有不一样的尺寸，如果用传统方法做成图片的话图片数量会很多，即使全部合并成 sprite 图，图片的 K 数也会很大，而且后期如果有修改的话还得重新合并 sprite 图，因此这次首页改版所有的纯色图标的高清适配全部使用 iconfont 图标：
改版所用到的 ICONFONT 图标生成以及管理选择了『』线上服务，在上面通过上传图标的
SVG 文件生成对应的字体文件，还可以根据图标分项目管理：
图标生成后，该服务还会自动打包好所需文件，并制成 DEMO 网页，供本地预览查找图标对应的字体编码以及使用方法：
相信前端的同学很早就使用过 ICONFONT 服务，笔者衷心感谢提供 ICONFONT 服务的&&组织，除了
ICONFONT 服务，THX 还提供了不少业界良心的前端精品工具服务，感谢他们为业界作出的贡献。
非纯色图通常用『2X』图适配，适配方案可以有很多选择：媒体查询、srcset属性、image-set属性、脚本控制。
媒体查询、srcset属性 和 image-set属性成功匹配的基本是高端浏览器，兼容性略差，脚本控制兼容性更佳，项目具体用哪一种要看『国情』了：
上图是我国PC端操作系统市场份额的大概分布情况，可以看出 95% 以上的用户都是使用 Windows 系统的，使用 Windows 系统的用户设备屏幕大部分都是普清屏，而使用高清屏的用户基本都是使用 Mac OS 系统，Mac OS 系统的浏览器又以『高富帅』Chrome 和 Safari 为主，因此只考虑适配 Mac OS 设备，最终选择比媒体查询更为方便的『srcset属性』和『image-set属性』方案：内容图使用 srcset 属性适配，背景图使用 image-set 属性适配高清图：
src=&images/bg_eco_v2_@1x.png& srcset=&images/bg_eco_v2_@1x.png 1x, images/bg_eco_v2_@2x.png 2x& alt=&&&
.chain_item_icon{
background-image: -webkit-image-set(url(&images/bg_chains_@1x.png&) 1x, url(&images/bg_chains_@2x.png&) 2x);
background-image: image-set(url(&images/bg_chains_@1x.png&) 1x, url(&images/bg_chains_@2x.png&) 2x);
新版京东云出现了很多设计类字体，也就是我们平时所说的非系统字体，如新版京东云首页版块标题用的字体 —-『方正兰亭超细黑体』
对于设计类字体，前端和视觉会达成共识不会大面积使用，因为该类字体的实现只能用图片或通过样式&@font-face&属性去实现：
图片方案：虽然可以高精度还原，兼容性强，但是每改动一处地方都需要换图，不方便维护，内容扩展性差，而且如果要适配高清设备，又得多一套图。
@font-face&属性方案：字体具有矢量性，高清设备可以轻松适配，内容扩展性强，但是不同的浏览器存在渲染的差异，兼容性略弱，@font-face字体文件大小一般又是
M 级别，会不同程度影响页面加载体验。
如果非系统字体应用的地方只有几个标题，而且不常改动的话，用图片方案较优，但是新版京东云在其它频道的首页也会应用到，内容较多，而且要适配高清图，所以图片方案并不适用，@font-face&属性方案更合适。
针对 『@font-face&属性方案』文件体积大和浏览器渲染差异的两个不足之处，采取了一个折中的方案，也就是浏览器的渲染差异在视觉可以接受的范围下，只抽取要用到的字体生成体积相对较小的字体文件。
Junmer 出品的&&工具可以大大满足这个需求，只需要将用到了字体源以及需要生成的文字内容加入到工具中，就可以生成相应的字体文件：
原来 2MB 的字体
生成的字体文件只有 11KB，字体文件体积减少达到了 99%
旧版首页加载的时候，一共有40个请求，其中图片的请求就有 31 个，占总请求数的 77%
有些可以合并的图片并没有做处理：
其中至少有 11 张图片是可以合并成一张图片的，也就是至少多了 27% 的额外请求数
首屏的图片资源加载了 31个，但其可见的图片只有 2 张，加载了 100% 的图片资源，首屏图片资源利用率只有 6%
只要用户没有完全浏览完网页就跳到其它页面的话，都会造成资源浪费。
首屏耗时较长的大图加载过程并没有做 Loading占位图 提示，有机会出现轮播图区域空白时间过长：
上图显示页面加载 1.8s 后，Banner 背景图还是没有出来，虽然网速飞快的用户有可能不出现这种情况，但是不排除网络慢的用户会碰上。
除此之外，图片加载失败的时候也没有做容错处理，就有机会出现图片加载失败的系统默认图标样式，会影响页面的美观性：
虽然新版首页的图片资源的排版和内容有所不同，但至少可以针对旧版额外请求数多、资源浪费、加载体验差这三个方向去改进。
减少图片额外请求数，收益比较明显的一般有三个方法：图片合并、iconfont 图标、Base64，三个方法都有各自的优缺点：
优点：兼容性强可缓存可提前加载多态图可提升图片加载显示体验
缺点：维护性差、合并图片类型以及大小控制限制高、有可能造成资源浪费
适合：修改更新少的常驻型低色位的装饰小图
优点：可缓存矢量性可控性强
缺点：存在浏览器渲染差异性、只能纯色、文件体积略大
适合：纯色图标
优点：无额外请求
缺点：不可缓存、兼容性差、代码冗余、可读性差、维护不便、CPU内存耗损大
适合：体积小复用率低的背景装饰图标
新版首页一共有 70 个图片资源，其中有 49 个是纯色图标，16 个是低色位非纯色图，5 个是高色位图。
49 个纯色图标全部使用了 Iconfont 方法处理，13 个低色位非纯色图使用了合并方法，一共有 62 个图片做了减少额外请求处理，最终图片资源请求数一共只有 14 个，其中纯色图的请求数占 2 个，低色位非纯色图请求数占 6 个，图片总请求数减少了
80% ，图片合并和 Iconfont 的额外请求处理率分别达到了 56% 和 96%
可以看到 Iconfont 的额外请求处理率相当出色，因为适合应用他的对象特点比较简单，而图片合并会受到合并图片的格式、资源分布、模块分布等情况影响，其额外请求处理率会相对低于 Iconfont。
我们可以得到一个优化图片额外请求的小结论：纯色图标优先考虑 Iconfont，低色位非纯色图片根据项目实际需要来做合并优化，Base64非特殊图片不使用
新版首页需要加载的图片资源一共有 14个，其中首屏的图片资源有 8 个，可见图片有 5 个，如果不作处理，那么首屏图片资源的利用率只有 35%
如果进行资源按需加载，在非首屏的图片资源实行懒加载，将轮播图不可见的两张图片做触发加载处理，这样首屏的加载图片资源只有 8 个，首屏图片资源利用率则可达到 60%，提高了 70% 的图片资源利用率，资源按需加载不失为一种避免资源浪费的最挂实践方法
图片加载的时间长短由很多因素决定，如服务器响应时间、用户所用网络带宽、图片大小等，但无论是哪一种情况，总有一个等待的过程，在这过程总会有一个空白时间，特别是占屏面积比较大的首屏轮播大图和采取懒加载的图片，即使图片空白时间很短，用户也会有不同程度的感知，会给用户带来一种唐突或漫长等待的感觉，如果加载过程给图片加上体积比较小的占位提示图，则会让用户有一个图片加载预知，当图片加载完成后再呈现给用户看，这样用户在图片加载过程中看到的都是完整的图片
当图片加载失败的时候，展示占位图，避免系统默认的图片加载失败图标出现
渐进增强是指从最基本的功能出发，在保证系统在任何环境中的可用性基础上，逐步增加功能，提高用户体验，
出现在页面比较重要位置的模块，如轮播图、导航等，如果需要做动画效果的话，在高低端浏览器上都应该能统一实现出来，新旧版首页首屏都以轮播图为主，轮播图切换都使用了渐隐渐现的动画效果。
旧版的动画实现在高低端浏览器都使用了 JQ 第三方动画库
type=&text/javascript& src=&js/jcloud_new/jquery.SuperSlide.2.1.1.js&&&
$(&.banner-slider&).slide({mainCell:&.bd ul&,effect:&fold&,autoPlay:true,interTime:4000,delayTime:1000});
$(&.box-slider&).slide({mainCell: &.bd ul&, effect: &left&, autoPlay: true, interTime: 5000, scroll: 6, vis: 6});
其实渐隐渐现的效果 CSS3 动画也能实现。新版首页的轮播图动画设置了 CSS3 动画后，再利用脚本控制样变化以触发 CSS3 动画，这样支持动画属性的浏览器就能以 CSS3 动画实现效果，而不支持的浏览器则通过脚本的属性判断，用 JQ 动画实现：
bottom: 0;
filter: alpha(opacity=0);
opacity: 0;
background: #fff;
@include trst(opacity 0.8s linear);
function imgChange(opt){
if(supports('transform')){
$imgList.eq(opt).addClass('active').css('opacity','1').siblings().removeClass('active').css('opacity','0');
$imgList.eq(opt).stop().animate({
'opacity': '1'
},800).addClass('active').siblings().stop().animate({
'opacity': '0'
},800).removeClass('active');
JQ 动画虽然兼容性好，但其动画性能远远不及 CSS3 动画，因此我们可以用以下的方法对动画性能实现渐进增强：高端浏览器可以通过触发 CSS3 动画实现效果，低端浏览器则使用 JQ 动画实现。
视觉渐进增强通常可以通过 CSS3 属性和增加 CSS3 动画来实现，现主流的网站基本都会对视觉做渐进增强处理。本次首页改版主要在多态元素、切换元素上做了处理
支持 CSS3 动画的 SexyGuy
不支持 CSS3 动画的 PoorGuy
浏览页面的时候，通过 Tab 键可以聚焦页面上的链接锚点，这时候浏览器会在锚点增加一个系统默认边框样式告诉用户锚点已选中，按&Enter&就可以打开选中的锚点，如
Chrome 浏览器上 google 首页的语音搜索按钮：
即使用户在浏览页面的时候鼠标突然失灵了也可以通过键盘操作继续完成浏览网页，这样的设计显然是为了增强页面的可用性。
但很多时候，在一些重要位置的内容，如全站的导航，产品经理或视觉设计师会要求将这个系统的样式去掉，于是很多同学可能会选择设置outline:none去掉边框样式，有些甚至会在全局
a 标签上设置，如旧版的京东云首页：
outline:none设置之后，页面上的所有链接虽然能通过Tab键聚焦，但链接并没有被选中的样式，没有办法直观辨出选中的链接
虽然并非所有用户都会用到 Tab 键，但还是会有少数用户会用到，如键盘党，而这种降低可用性的体验存在表明页面并没有健全，因此并不建议去掉outline样式。
如果真的有去掉&outline样式的需求怎么办？其实，页面链接一般都会被设计为多态的，利用链接的多态样式，为链接加上:focus伪类选中样式，Tab
选中链接后就会展示&:focus伪类样式了，如新版首页的导航：
可以为链接加上:focus伪类样式
.mod_hd_nav_sub_col{
color: #fff;
text-decoration:
&:hover,&:focus{
color: #ffe400;
text-decoration:
当选中链接还绑定有事件的时候，也应该为之绑定相应事件
$navBox.on({
'mouseenter': function () {
'focus': function(){
$(this).trigger('mouseenter');
'mouseleave': function () {
'blur': function(){
$(this).trigger('mouseleave');
}, '.mod_hd_nav_item');
处理完，虽然&outline样式去掉了，但依然可以用 Tab 键完成链接的选中
旧版首页所有的静态资源的更新发布方式都是采用覆盖式更新：
type=&text/javascript& src=&js/jcloud_new/jquery-1.7.2.min.js&&&
type=&text/javascript& src=&js/jcloud_new/jquery.SuperSlide.2.1.1.js&&&
type=&text/javascript& src=&js/jcloud_new/login_w.js&&&
type=&text/javascript& src=&/resource/js/cms.js&&&
覆盖式更新发布有机会遇到缓存问题以及在发布的时候导致页面错乱问题，详情可以看一下张云龙前辈在知乎对问题『』的回答，解决覆盖式更新产生的问题，现主流方法就是使用
MD5 文件名进行非覆盖式发布，京东云新版首页所有的静态资源的更新发布都采用了这种方式。
src=&//labs.qiang.it/pc/jcloud/gb/js/lib.min_2f4dab0c.js&&&
src=&//labs.qiang.it/pc/jcloud/gb/js/gb.min_b599b860.js&&&
src=&//labs.qiang.it/pc/jcloud/home/js/index.min_9d957a15.js&&&
OK，优化永远说不完的，以上所说的只是前端优化的冰山一角，业界绝不缺高大上的优秀优化方案，但从业务实际规模出发的话，这些小优化在本次改版中已得到很明显的收益，期待以后有更具规模的项目可以挥霍高大上的优化方案，最后把新旧版的页面都放到预览服务器上了
感谢你的阅读，本文由&&版权所有。如若转载，请注明出处：凹凸实验室（）
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：91409次
积分：1644
积分：1644
排名：第19902名
原创：18篇
转载：336篇
(1)(3)(4)(7)(8)(26)(62)(56)(58)(111)(21)前端性能优化（CSS动画篇） - 简书
前端性能优化（CSS动画篇）
现代浏览器在使用CSS3动画时，以下四种情形绘制的效率较高，分别是：
改变透明度
层？重绘？回流和重布局？图层重组？首先要了解CSS的图层的概念（Chrome浏览器）
浏览器在渲染一个页面时，会将页面分为很多个图层，图层有大有小，每个图层上有一个或多个节点。在渲染DOM的时候，浏览器所做的工作实际上是：
获取DOM后分割为多个图层
对每个图层的节点计算样式结果（Recalculate style--样式重计算）
为每个节点生成图形和位置（Layout--回流和重布局）
将每个节点绘制填充到图层位图中（Paint Setup和Paint--重绘）
图层作为纹理上传至GPU
符合多个图层到页面上生成最终屏幕图像（Composite Layers--图层重组）
Chrome中满足以下任意情况就会创建图层：
3D或透视变换（perspective transform）CSS属性
使用加速视频解码的&video&节点
拥有3D（WebGL）上下文或加速的2D上下文的&canvas&节点
混合插件（如Flash）
对自己的opacity做CSS动画或使用一个动画webkit变换的元素
拥有加速CSS过滤器的元素
元素有一个包含复合层的后代节点（一个元素拥有一个子元素，该子元素在自己的层里）
元素有一个z-index较低且包含一个复合层的兄弟元素（换句话说就是该元素在复合层上面渲染）
需要注意的是，如果图层中某个元素需要重绘，那么整个图层都需要重绘。比如一个图层包含很多节点，其中有个gif图，gif图的每一帧，都会重回整个图层的其他节点，然后生成最终的图层位图。所以这需要通过特殊的方式来强制gif图属于自己一个图层（translateZ(0)或者translate3d(0,0,0)），CSS3的动画也是一样（好在绝大部分情况浏览器自己会为CSS3动画的节点创建图层）
层和CSS动画
简化一下上述过程，每一帧动画浏览器可能需要做如下工作：
计算需要被加载到节点上的样式结果（Recalculate style--样式重计算）
为每个节点生成图形和位置（Layout--回流和重布局）
将每个节点填充到图层中（Paint Setup和Paint--重绘）
组合图层到页面上（Composite Layers--图层重组）
如果我们需要使得动画的性能提高，需要做的就是减少浏览器在动画运行时所需要做的工作。最好的情况是，改变的属性仅仅印象图层的组合，变换（transform）和透明度（opacity）就属于这种情况
现代浏览器如Chrome，Firefox，Safari和Opera都对变换和透明度采用硬件加速，但IE10+不是很确定是否硬件加速
触发重布局的属性
有些节点，当你改变他时，会需要重新布局（这也意味着需要重新计算其他被影响的节点的位置和大小）。这种情况下，被影响的DOM树越大（可见节点），重绘所需要的时间就会越长，而渲染一帧动画的时间也相应变长。所以需要尽力避免这些属性
一些常用的改变时会触发重布局的属性
盒子模型相关属性会触发重布局：
border-width
min-height
定位属性及浮动也会触发重布局：
改变节点内部文字结构也会触发重布局：
text-align
overflow-y
font-weight
font-family
line-height
vertival-align
white-space
这么多常用属性都会触发重布局，可以看到，他们的特点就是可能修改整个节点的大小或位置，所以会触发重布局
别使用CSS类名做状态标记
如果在网页中使用CSS的类来对节点做状态标记，当这些节点的状态标记类修改时，将会触发节点的重绘和重布局。所以在节点上使用CSS类来做状态比较是代价很昂贵的
触发重绘的属性
修改时只触发重绘的属性有：
border-style
border-radius
visibility
text-decoration
background
background-image
background-position
background-repeat
background-size
outline-color
outline-style
outline-width
box-shadow
这样可以看到，这些属性都不会修改节点的大小和位置，自然不会触发重布局，但是节点内部的渲染效果进行了改变，所以只需要重绘就可以了
手机就算重绘也很慢
在重绘时，这些节点会被加载到GPU中进行重绘，这对移动设备如手机的影响还是很大的。因为CPU不如台式机或笔记本电脑，所以绘画巫妖的时间更长。而且CPU与GPU之间的有较大的带宽限制，所以纹理的上传需要一定时间
触发图层重组的属性
透明度竟然不会触发重绘？
需要注意的是，上面那些触发重绘的属性里面没有opacity（透明度），很奇怪不是吗？实际上透明度的改变后，GPU在绘画时只是简单的降低之前已经画好的纹理的alpha值来达到效果，并不需要整体的重绘。不过这个前提是这个被修改opacity本身必须是一个图层，如果图层下还有其他节点，GPU也会将他们透明化
强迫浏览器创建图层
在Blink和WebKit的浏览器中，一当一个节点被设定了透明度的相关过渡效果或动画时，浏览器会将其作为一个单独的图层，但很多开发者使用translateZ(0)或者translate3d(0,0,0)去使浏览器创建图层。这种方式可以消除在动画开始之前的图层创建时间，使得动画尽快开始（创建图层和绘制图层还是比较慢的），而且不会随着抗锯齿而导出突变。不过这种方法需要节制，否则会因为创建过多的图层导致崩溃
Chrome中的抗锯齿
Chrome中，非根图层以及透明图层使用grayscale antialiasing而不是subpixel antialiasing，如果抗锯齿方法变化，这个效果将会非常显著。如果你打算预处理一个节点而不打算等到动画开始，可以通过这种强迫浏览器创建图层的方式进行
//灰度级示例
-webkit-filter: grayscale(100%);
-moz-filter: grayscale(100%);
-ms-filter: grayscale(100%);
-o-filter: grayscale(100%);
filter: grayscale(100%);
ps:"webkit-font-smoothing" 属性。这个属性可以使页面上的字体抗锯齿(antialiased)
transform变换是你的选择
我们通过节点的transform可以修改节点的位置、旋转、大小等。我们平常会使用left和top属性来修改节点的位置，但正如上面所述，left和top会触发重布局，修改时的代价相当大。取而代之的更好方法是使用translate，这个不会触发重布局
JS动画和CSS3动画的比较
我们经常面临一个抉择：是使用JavaScript的动画还是使用CSS的动画，下面将对比一下这两种方式
缺点：JavaScript在浏览器的主线程中运行，而其中还有很多其他需要运行的JavaScript、样式计算、布局、绘制等对其干扰。这也就导致了线程可能出现阻塞，从而造成丢帧的情况。
优点：JavaScript的动画与CSS预先定义好的动画不同，可以在其动画过程中对其进行控制：开始、暂停、回放、中止、取消都是可以做到的。而且一些动画效果，比如视差滚动效果，只有JavaScript能够完成
缺点：缺乏强大的控制能力。而且很难以有意义的方式结合到一起，使得动画变得复杂且易于出问题。优点：浏览器可以对动画进行优化。它必要时可以创建图层，然后在主线程之外运行。
Google目前正在探究通过JS的多线程（Web Workers）来提供更好的动画效果，而不会触发重布局及样式重计算
动画给予了页面丰富的视觉体验。我们应该尽力避免使用会触发重布局和重绘的属性，以免失帧。最好提前申明动画，这样能让浏览器提前对动画进行优化。由于GPU的参与，现在用来做动画的最好属性是如下几个：
也许会有一些新的方式使得可以使用JavaScript做出更好的没有限制的动画，而且不用担心主线程的阻塞问题。但在那之前，还是好好考虑下如何做出流畅的动画吧
[前端性能优化（CSS动画篇）]原文地址：()}