如何使CSS渲染更高效

html-css012

如何使CSS渲染更高效,第1张

这是应该是浏览器开发者应该关心的(页面加载更快,用户就会更愉快)。Mozilla有一篇文章: about best practices . Google 当然也很关心这个问题,他们也有这样一篇文章:Optimize browser rendering。让我们了解下他们主要倡导的东东,然后讨论他们的实用性。从右到左浏览器如何读取你的CSS选择器有一个很重要的原则,那就是它们从右到左读取。这意味这像 ul li a[title="home"] 这样的选择器,a[title="home"] 将是最先被读取的。这一部分通常被称为 “key selector” (可否称为“目标选择器” -_-!)选择器的最后一部分,也是被选择的标签。ID's 是最有效率的,通用符是最慢的有四种目标选择器:ID, class, tag和通用符。看下他们各自的效率如何:

#main-navigation { } /* ID (最快) */

body.home #page-wrap { } /* ID */

.main-navigation { } /* Class */

ul li a.current { } /* Class *

ul { } /* Tag */

ul li a { } /* Tag */

* { } /* Universal (最慢) */

#content [title='home'] /* Universal */ 然后我们结合从右到左和目标选择器的概念,我们可以知道下面这个选择器并不高效:

#main-nav li { } /* 看着很快实则很慢 */

尽管这让人有点费解......因为ID's是最高效的,浏览器可以通过ID迅速的找到 li。但事实是,li 标签是被先读取的。不要用标签修饰死也不要像下面这样干:ul#main-navigation { }ID's 是唯一的,所以不需要用标签修饰,这只会让它更低效。

如果你可以避免的话,也不要用它修饰 class 。class 不是唯一的,所以理论上你可以把它用在不同的标签。如果你愿意的话,你可以用标签控制不同的样式,这样你可能需要标签修饰(比如:li.first),但这样做的人很少,所以,don't .绝对没有比用后代选择器更糟糕的做法了David Hyatt:

后代选择器是CSS里最昂贵的选择器,昂贵得可怕——特别是当它放在标签和通用符后面时。

就如下面这个东东一样,绝对的效率毒瘤:html body ul li a { }一个选择器渲染失败比这个选择器被渲染更高效我不是很确定是否有更好的证据去证明这一点,因为如果你有大量的选择器在CSS样式表里无法找到,这样的事情貌似很离奇,但一点必需注意的是,从右到左的解释一个选择器来说,一旦它找不到,那它就会停止尝试。然而如果它找到了,那它就需要花更多精力去解释了。试想一下为何你这样写选择器思考下这东东:#main-navigation li a { font-family: Georgia, Serif}你可能不需要从 a 选择器开始(如果你只是想换个字体)。下面这个可能更高效些:#main-navigation { font-family: Georgia, Serif}实用性还刻前面提到的Mozilla的一篇文章?已经有十年了。事实是:计算机比十年前变慢了(不是我理解错了,还是作者想说现在的WEB越来越复杂了)。我感觉这东东在当年似乎还更受重视。十年前我还是个21岁的英俊小生,当然我不觉得那里我会认识css这东东。所以我也无法跟你讲以前的情况......但我觉得渲染效率的问题之所以没被重视是因为这从来就不是一个大问题。

这是我的一些看法:不管怎样上面提到的东东都是有意义的,你可以按照上面的方法去做,因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者,而之前又没有考虑过那东东,那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢,那大可别太在意,在以后的工作中多注意就行了。超级快速,零实用性我们知道ID's 是最高效的选择器。当你想让渲染速度最高效时,你可能会给每个独立的标签配置一个ID,然后用这些ID写样式。那会超级快,也超级荒唐。这样的结果是语义极差,维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let’s hear it!顺便提一下,因为CSS选择器被很多javascript库使用,上面提到的东东仍然适用,ID选择器还是最快的,后代选择器和类似的东东比较慢。PS:看谁还敢用N多的后代选择器。。。还有反对我用ID的。。。哇哈哈。。。经典论坛交流:

移动互联网时代,用户对于网页的打开速度要求越来越高。首屏作为直面用户的第一屏,其重要性不言而喻。优化用户体验更是我们前端开发非常需要 focus 的东西之一。

从用户的角度而言,当打开一个网页,往往关心的是从输入完网页地址后到最后展现完整页面这个过程需要的时间,这个时间越短,用户体验越好。所以作为网页的开发者,就从输入url到页面渲染呈现这个过程中去提升网页的性能。

所以输入URL后发生了什么呢?在浏览器中输入url会经历域名解析、建立TCP连接、发送http请求、资源解析等步骤。

http缓存优化是网页性能优化的重要一环,这一部分我会在后续笔记中做一个详细总结,所以本文暂不多做详细整理。本文主要从网页渲染过程、网页交互以及Vue应用优化三个角度对性能优化做一个小结。

首先谈谈拿到服务端资源后浏览器渲染的流程:

关键渲染路径是浏览器将 HTML、CSS、JavaScript 转换为在屏幕上呈现的像素内容所经历的一系列步骤。也就是我们刚刚提到的的的浏览器渲染流程。

为尽快完成首次渲染,我们需要最大限度减小以下三种可变因素:

首先,DOM 和 CSSOM 通常是并行构建的,所以 CSS 加载不会阻塞 DOM 的解析。

然而,由于 Render Tree 是依赖于 DOM Tree 和 CSSOM Tree 的,

所以他必须等待到 CSSOM Tree 构建完成,也就是 CSS 资源加载完成(或者 CSS 资源加载失败)后,才能开始渲染。因此,CSS 加载会阻塞 Dom 的渲染。

由此可见,对于 CSSOM 缩小、压缩以及缓存同样重要,我们可以从这方面考虑去优化。

当浏览器遇到 script 标记时,会阻止解析器继续操作,直到 CSSOM 构建完毕,JavaScript 才会运行并继续完成 DOM 构建过程。

当页面中元素样式的改变并不影响它在文档流中的位置时(例如:color、background-color、visibility 等),浏览器会将新样式赋予给元素并重新绘制它,这个过程称为重绘。

回流(Reflow)

当 Render Tree 中部分或全部元素的尺寸、结构、或某些属性发生改变时,浏览器重新渲染部分或全部文档的过程称为回流。

有时即使仅仅回流一个单一的元素,它的父元素以及任何跟随它的元素也会产生回流。现代浏览器会对频繁的回流或重绘操作进行优化:浏览器会维护一个队列,把所有引起回流和重绘的操作放入队列中,如果队列中的任务数量或者时间间隔达到一个阈值的,浏览器就会将队列清空,进行一次批处理,这样可以把多次回流和重绘变成一次。

当你访问以下属性或方法时,浏览器会立刻清空队列:

因为队列中可能会有影响到这些属性或方法返回值的操作,即使你希望获取的信息与队列中操作引发的改变无关,浏览器也会强行清空队列,确保你拿到的值是最精确的。

避免频繁操作样式,最好一次性重写 style 属性,或者将样式列表定义为 class 并一次性更改 class 属性。

避免频繁操作 DOM,创建一个 documentFragment,在它上面应用所有 DOM 操作,最后再把它添加到文档中。

也可以先为元素设置 display: none,操作结束后再把它显示出来。因为在 display 属性为 none 的元素上进行的 DOM 操作不会引发回流和重绘。

避免频繁读取会引发回流/重绘的属性,如果确实需要多次使用,就用一个变量缓存起来。

对具有复杂动画的元素使用绝对定位,使它脱离文档流,否则会引起父元素及后续元素频繁回流。

图片懒加载在一些图片密集型的网站中运用比较多,通过图片懒加载可以让一些不可视的图片不去加载,避免一次性加载过多的图片导致请求阻塞(浏览器一般对同一域名下的并发请求的连接数有限制),这样就可以提高网站的加载速度,提高用户体验。

将页面中的img标签src指向一张小图片或者src为空,然后定义data-src(这个属性可以自定义命名,我才用data-src)属性指向真实的图片。src指向一张默认的图片,否则当src为空时也会向服务器发送一次请求。可以指向loading的地址。注意,图片要指定宽高。

当载入页面时,先把可视区域内的img标签的data-src属性值负给src,然后监听滚动事件,把用户即将看到的图片加载。这样便实现了懒加载。

事件委托其实就是利用JS事件冒泡机制把原本需要绑定在子元素的响应事件(click、keydown……)委托给父元素,让父元素担当事件监听的职务。事件代理的原理是DOM元素的事件冒泡。

优点:

例如有一个列表需要绑定点击事件,每一个列表项的点击都需要返回不同的结果。

传统写法:

传统方法会利用for循环遍历列表为每一个列表元素绑定点击事件,当列表中元素数量非常庞大时,需要绑定大量的点击事件,这种方式就会产生性能问题。这种情况下利用事件委托就能很好的解决这个问题。

改用事件委托:

输入搜索时,可以用防抖debounce等优化方式,减少http请求;

这里以滚动条事件举例:防抖函数 onscroll 结束时触发一次,延迟执行

节流函数:只允许一个函数在N秒内执行一次。滚动条调用接口时,可以用节流throttle等优化方式,减少http请求;

下面还是一个简单的滚动条事件节流函数:节流函数 onscroll 时,每隔一段时间触发一次,像水滴一样

参考链接: https://zhuanlan.zhihu.com/p/113864878?from_voters_page=true

提高网站页面的加载速度的方法其实有很多,那本文主要从下面四个角度进行讨论,分享常用的提高网页加载速度的技巧:

一、网页压缩技术

对于网页压缩而言,相信各位站长都比较熟悉,主要是启用服务器Gzip,对页面Gzip压缩,减少元素的体积,从而减少数据的传输,进而提高网页的加载速度。

二、Css优化

(1)css位置

CSS说明如果出现在<body>后,页面需要重新渲染,打开速度受到影响。所有css定义代码的位置要放到网站<body>之前。

(2)css sprite技术

网站上的一些图片可以采用css sprite技术进行合并,减少加载请求次数,从而提高网页的加载速度。

(3)css代码优化

通过对css代码属性的简写、移除多余的结构(frameworks)和重设(resets)等一系列的方法和技巧来简化css代码,减小css文件的大小。

三、JS优化

(1)JS位置

网页代码中对js进行优化的时候,建议将JS放在页面最后,这样可以加快页面打开速度。

(2)合并JS

合并相同域名下的js,通过减少网络连接次数从而提高网页的打开速度。

(3)LazyLoad(延迟加载)技术

Lazy Load是一个用JavaScript 编写的 jQuery 插件,它可以延迟加载长页面中的图片。在浏览器可视区域外的图片不会被载入,直到用户将页面滚动到它们所在的位置。

四、缓存静态资源

通过设置浏览器缓存,将css、js等不太经常更新的文件缓存在浏览器端,这样同一访客再次访问你的网站的时候,浏览器就可以从浏览器的缓存中获取css、js等,而不必每次都从服务器读取,这样在一定程度上加快了网站的打开速度,又可以节约服务器流量。