前端性能优化(十五)

简化绘制的复杂度、减小绘制区域

绘制,是填充像素的过程,这些像素将最终显示在用户的屏幕上。通常,这个过程是整个渲染流水线中耗时最长的一环,因此也是最需要避免发生的一环。

如果布局被触发,那么接下来绘制_一定_会被触发。因为改变一个元素的几何属性就意味着该元素的所有像素都需要重新渲染!

除此之外,如果改变元素的非几何属性,也可能触发绘制,比如背景、文字颜色或者阴影效果,尽管这些属性的改变不会触发布局。整个渲染流水线会像下图所示:

使用Chrome DevTools来迅速定位绘制过程中的性能瓶颈

使用Chrome DevTools能够迅速定位出当前页面中正在进行绘制的区域。打开DevTools,按下键盘的ESC键。在弹出的面板中,选中rendering选项卡,然后选中“Show paint rectangles”:

打开了Chrome的这个选项之后,每当页面中有绘制发生时,屏幕上就会闪现绿色的方框。如果你看到绿色方框覆盖了整个屏幕,或者覆盖了一些你觉得不应该发生绘制的区域,那么很可能这次绘制是可以被优化的,你就需要看看这次绘制的更多细节了。

Chrome DevTools中有一个选项能让你看到更多关于绘制的细节:paint profiler。打开DevTools的Timeline选项卡,选中面板顶部的“Paint”选项,你就开启了paint profiler。需要注意的是,请务必_仅在需要分析绘制问题的时候才开启该选项_。因为运行paint profiler本身也会耗费浏览器的资源,对页面性能的结果多少会有点影响。最好是按需启用它,而不是一直让它开启着。

完成了上述设置之后,你就可以对页面进行绘制性能分析了。运行Timeline记录功能,你就会记录到相当详细的绘制分析信息。在某一帧的记录上点击paint记录,你就会看到这一帧的绘制分析结果:

点击paint profiler,会打开一个视图,里面会显示绘制了哪些元素、花了多长时间、以及每个具体的paint调用:

这个分析器能让你了解绘制区域和绘制复杂度(体现为花费了多长时间),这两个方面正好是你可以对绘制做优化的地方(当然我们首先得努力避免绘制的发生,在无法避免的情况下才对绘制做优化)。

提升移动或渐变元素的绘制层

绘制并非总是在内存中的单层画面里完成的。实际上,浏览器在必要时将会把一帧画面绘制成多层画面,然后将这若干层画面合并成一张图片显示到屏幕上。

这种绘制方式的好处是,使用tranforms来实现移动效果的元素将会被正常绘制,同时不会触发对其他元素的绘制。这种处理方式和思想跟图像处理软件(比如Sketch/GIMP/Photoshop)是一致的,它们都是可以在图像中的某个单个图层上做操作,最后合并所有图层得到最终的图像。

在页面中创建一个新的渲染层的最好方式就是使用CSS属性will-change,Chrome/Opera/Firefox都支持该属性。同时再与transform属性一起使用,就会创建一个新的组合层:

.moving-element {
  will-change: transform;
}

对于那些目前还不支持will-change属性、但支持创建渲染层的浏览器,比如Safari和Mobile Safari,你可以使用一个3D transform属性来强制浏览器创建一个新的渲染层:

.moving-element {
  transform: translateZ(0);
}

但需要注意的是:不要创建太多的渲染层。因为每创建一个新的渲染层,就意味着新的内存分配和更复杂的层的管理。关于这方面的更多信息,请参考优先使用渲染层合并属性、控制层数量

如果你已经把一个元素放到一个新的渲染层里,那么可以使用DevTools来确认这么做是否真的改进了渲染性能。别盲目创建渲染层,一定要分析其实际性能表现。

减少绘制区域

有时候尽管把元素提升到了一个单独的渲染层,渲染工作依然是必须的。渲染过程中一个比较有挑战的问题是,浏览器会把两个相邻区域的渲染任务合并在一起进行,这将导致整个屏幕区域都会被绘制。比如,你的页面顶部有一个固定位置的header,而此时屏幕底部有某个区域正在发生绘制的话,整个屏幕都将会被绘制。

Note

  • 在DPI较高的屏幕上,固定定位的元素会自动地被提升到一个它自有的渲染层中。但在DPI较低的设备上却并非如此,因为这个渲染层的提升会使得字体渲染方式由子像素变为灰阶(详细内容请参考:[Text Rendering](http://www.html5rocks.com/en/tutorials/internals/antialiasing-101/?redirect_from_locale=zh#toc-text-rendering)),我们需要手动实现渲染层的提升。

减少绘制区域通常需要对动画效果进行精密设计,以保证各自的绘制区域之间不会有太多重叠,或者想办法避免对页面中某些区域执行动画效果。

简化绘制的复杂度

在绘制所涉及的一些问题中,有些问题是相对更耗费昂贵的。比如,绘制一个blur效果(比如阴影)就比绘制其他效果(比如一个红色方框)更费时。然而,在CSS方面,这些问题并非都是显而易见的:background: redbox-shadow: 0, 4px, 4px, rgba(0,0,0,0.5);可能看上去在性能方面没有太大的差别,但事实却并非如此。

上面提到的paint profiler能让你意识到是否该问问自己:有没有其他的方式(比如其他的样式修改方案)来实现同样的效果的同时,却能达到更好的性能。

你要尽可能的避免绘制的发生,特别是在动画效果中。因为每帧10毫秒的时间预算一般来说是不足以完成绘制工作的,尤其是在移动设备上。

时间: 2024-11-02 01:55:32

前端性能优化(十五)的相关文章

Oracle 学习之 性能优化(十五) ASH、ADDM、AWR

ASH(Active Session History) ASH以V$SESSION为基础,每秒采样一次,记录活动会话等待的事件.不活动的会话不会采样,采样工作由新引入的后台进程MMNL来完成.ASH buffers 的最小值为1MB,最大值不超过30MB.内存中记录数据.期望值是记录一小时的内容. AWR(Automatic Workload Repository) 自动工作负载信息库 ASH 内存记录数据始终是有限的,为了保存历史数据,引入了自动负载信息库(AutomaticWorkload

关于Yahoo十四条军规与前端性能优化

关于Yahoo十四条军规与前端性能优化 热度 4已有 223 次阅读2014-8-3 15:01 |个人分类:前端相关|系统分类:前端优化| 前端优化, yahoo, 性能优化 启用Gzip压缩.Gzip的思想就是把文件先在服务器端进行压缩,然后再传输.这样可以显著减少文件传输的大小.传输完毕后浏览器会 重新对压缩过的内容进行解压缩,并执行.目前的浏览器都能“良好”地支持 gzip.不仅浏览器可以识别,而且各大“爬虫”也同样可以识别,各位seoer可以放下心了.而且gzip的压缩比例非常大,一般

web前端性能优化

前言:  在同样的网络环境下,两个同样能满足你的需求的网站,一个“Duang”的一下就加载出来了,一个纠结了半天才出来,你会选择哪个?研究表明:用户最满意的打开网页时间是2-5秒,如果等待超过10秒,99%的用户会关闭这个网页.也许这样讲,各位还不会有太多感触,接下来我列举一组数据:Google网站访问速度每慢400ms就导致用户搜索请 求下降0.59%;Amazon每增加100ms网站延迟将导致收入下降1%;雅虎如果有400ms延迟会导致流量下降5-9%.网站的加载速度严重影响了用户体验,也决

Web前端性能优化——如何提高页面加载速度

前言:  在同样的网络环境下,两个同样能满足你的需求的网站,一个"Duang"的一下就加载出来了,一个纠结了半天才出来,你会选择哪个?研究表明:用户最满意的打开网页时间是2-5秒,如果等待超过10秒,99%的用户会关闭这个网页.也许这样讲,各位还不会有太多感触,接下来我列举一组数据:Google网站访问速度每慢400ms就导致用户搜索请 求下降0.59%;Amazon每增加100ms网站延迟将导致收入下降1%;雅虎如果有400ms延迟会导致流量下降5-9%.网站的加载速度严重影响了用户

【转】Web前端性能优化——如何提高页面加载速度

前言:  在同样的网络环境下,两个同样能满足你的需求的网站,一个"Duang"的一下就加载出来了,一个纠结了半天才出来,你会选择哪个?研究表明:用户最满意的打开网页时间是2-5秒,如果等待超过10秒,99%的用户会关闭这个网页.也许这样讲,各位还不会有太多感触,接下来我列举一组数据:Google网站访问速度每慢400ms就导致用户搜索请 求下降0.59%;Amazon每增加100ms网站延迟将导致收入下降1%;雅虎如果有400ms延迟会导致流量下降5-9%.网站的加载速度严重影响了用户

CSS3与页面布局学习总结(八)——浏览器兼容与前端性能优化

目录 一.浏览器兼容 1.1.概要 1.2.浏览器内核 1.3.浏览器市场份额(Browser Market Share) 1.4.兼容的一般标准 1.5.CSS Reset 1.6.CSS Hack 1.6.1.条件注释法 1.6.2.样式内属性标记法 1.6.3.选择器前缀法 1.7.文档模式 (X-UA-Compatible) 1.8.javascript兼容 二.前端性能优化 2.1.概要 2.2.减少HTTP请求数量 2.2.1.图片地图 2.2.2.精灵图片(Sprite) 2.2.

前端性能优化归纳总结

关于前端性能优化的总结,随处都可以看到这方面的文章,而优化方法,也无外乎那些"固定"方面,当然,有些方面已经过时,所以,在这里,我自己也总结一遍吧,加深理解,也希望是一种不同的总结形式. -----------------------正文总这里开始------------------------------------ 一.什么是前端性能优化(what)? 从用户访问资源到资源完整的展现在用户面前的过程中,通过技术手段和优化策略,缩短每个步骤的处理时间从而提升整个资源的访问和呈现速度.

基于大数据的用户行为预测在前端性能优化上的应用

首先,我得说,这篇文章有点标题党了,其实内容并没有标题看起来那么高大上.其次,本文只是做一个技术方案可能性的探讨,并没有提供完善的解决方案,至多给了一个Demo供参考. 目的 如需转载,请注明转自:http://www.cnblogs.com/silenttiger/p/4929841.html 前端性能优化,我觉得最主要的目的就两个:1.提升页面加载速度:2.节约服务器资源. 这里特别提一下节约服务器资源,很多人在做前端性能优化的时候,往往只考虑前端性能的问题,而完全忽视前端的性能优化对后端服

CSS3与页面布局学习笔记(八)——浏览器兼容性问题与前端性能优化方案

一.浏览器兼容 1.1.概要 世界上没有任何一个浏览器是一样的,同样的代码在不一样的浏览器上运行就存在兼容性问题.不同浏览器其内核亦不尽相同,相同内核的版本不同,相同版本的内核浏览器品牌不一样,各种运行平台还存在差异.屏幕分辨率不一样,大小不一样,比例不一样.兼容性主要可以分类为: 1).CSS兼容2).JavaScript兼容3).HTML兼容 这三类也是前端的主要组成部分,都存在一定的兼容性问题,知己知彼,百战百胜,我们先了解浏览器的发动机—内核. 多年前我们一直为IE6兼容烦恼,为它没少加

前端性能优化规则总结—读《高性能网站建设指南》

本文对<高性能网站建设指南>这本书中提出的14种基本的前端性能优化方案进行了总结,这本书介绍的优化方案比较过时了,不能完全满足目前前端性能优化,如果您浏览完能弄清楚每种方案的实施过程.就没必要看这本书了. 规则1-减少HTTP请求 1.使用图片地图 图片地图允许你在一个图片上关联多个URL,目标URL的选择取决于用户点击了图片上的哪个位置. 比如导航栏菜单有五个选项,为了美观,我们将菜单对应的超链接关联到图片上,可以使用五个分开的图片分别关联五个分开的超链接,此时加载这个导航菜单就要通过五次H