Chrome开发者工具不完全指南,Web性能优化

Twitter的”fave”动画

2015/05/12 · HTML5 · Twitter, 动画

本文由 伯乐在线 - 刘健超-J.c 翻译,胡屹 校稿。未经许可,禁止转载!
英文出处:cssanimation.rocks。欢迎加入翻译组。

Chrome开发者工具不完全指南:(三、性能篇)

2015/06/29 · HTML5 · 2 评论 · Chrome

原文出处: 卖烧烤夫斯基   

卤煮在前面已经向大家介绍了Chrome开发者工具的一些功能面板,其中包括ElementsNetworkResources基础功能部分和Sources进阶功能部分,对于一般的网站项目来说,其实就是需要这几个面板功能就可以了(再加上console面板这个万精油)。它们的作用大多数情况下是帮助你进行功能开发的。然而在你开发应用级别的网站项目的时候,随着代码的增加,功能的增加,性能会逐渐成为你需要关注的部分。那么网站的性能问题具体是指什么呢?在卤煮看来,一个网站的性能主要关乎两项,一是加载性能、二是执行性能。第一项可以利用Network来分析,我以后会再次写一篇关于它的文章分享卤煮的提高加载速度的经验,不过在此之前,我强烈推荐你去阅读《web高性能开发指南》这本书中的十四条黄金建议,这是我阅读过的最精华的书籍之一,虽然只有短短的一百多页,但对你的帮助确实无法估量的。而第二项性能问题就体现在内存泄露上,这也是我们这篇文章探讨的问题——通过Timeline来分析你的网站内存泄露。

虽然浏览器日新月异,每一次网站版本的更新就意味着JavaScript、css的速度更加快速,然而作为一名前端人员,是很有必要去发现项目中的性能的鸡肋的。在众多性能优化中,内存泄露相比于其他性能缺陷(网络加载)不容易发现和解决,因为内存泄露设计到浏览器处理内存的一些机制并且同时涉及到到你的编写的代码质量。在一些小的项目中,当内存泄露还不足以让你重视,但随着项目复杂度的增加,内存问题就会暴露出来。首先内存占有过多导致你的网站响应速度(非ajax)变得慢,就感觉自己的网页卡死了一样;然后你会看到任务管理器的内存占用率飙升;到最后电脑感觉死了机一样。这种情况在小内存的设备上情况会更加严重。所以,找到内存泄露并且解决它是处理这类问题的关键。

在本文中,卤煮会通过个人和官方的例子,帮助诸位理解Timeline的使用方法和分析数据的方法。首先我们依然为该面板区分为四个区域,然后对它们里面的各个功能进行逐一介绍:

图片 1

虽然Timeline在执行它的任务时会显得花花绿绿让人眼花缭乱,不过不用担心,卤煮用一句话概括它的功能就是:描述你的网站在某些时候做的事情和呈现出的状态。我们看下区域1中的功能先:

图片 2

在区域1主题是一个从左到右的时间轴,在运行时它里面会呈现出各种颜色块(下文中会介绍)。顶部有一条工具栏,从左到右,一次表示:

1、开始运行Timeline检测网页。点亮圆点,Timline开始监听工作,在此熄灭圆点,Timeline展示出监听阶段网站的执行状态。

2、清除所有的监听信息。将Timeline复原。

3、查找和过滤监控信息。点击会弹出一个小框框,里面可以搜索或者显示隐藏你要找的信息。

4、手动回收你网站内内存垃圾。

5、View:监控信息的展示方式,目前有两种,柱状图和条状图,在展示的事例中,卤煮默认选择条状图。

6、在侦听过程中希望抓取的信息,js堆栈、内存、绘图等。。。。

区域2是区域1的完全版,虽然他们都是展示的信息视图,在在区域2种,图示会变得更加详细,更加精准。一般我们查看监控视图都在区域2种进行。

区域3是展示的是一些内存信息,总共会有四条曲线的变化。它们对应表示如下图所示:

图片 3

区域4中展示的是在区域2种某种行为的详细信息和图表信息。

在对功能做了简单的介绍之后我们用一个测试用例来了解一下Timeline的具体用法。

XHTML

<!DOCTYPE html> <html> <head> <title></title> <style type="text/css"> div{ height: 20px; widows: 20px; font-size: 26px; font-weight: bold; } </style> </head> <body> <div id="div1"> HELLO WORLD0 </div> <div id="div2"> HELLO WORLD2 </div> <div id="div3"> HELLO WORLD3 </div> <div id="div4"> HELLO WORLD4 </div> <div id="div5"> HELLO WORLD5 </div> <div id="div6"> HELLO WORLD6 </div> <div id="div7"> HELLO WORLD7 </div> <button id="btn">click me</button> <script type="text/javascript"> var k = 0; function x() { if(k >= 7) return; document.getElementById('div'+(++k)).innerHTML = 'hello world' } document.getElementById('btn').addEventListener('click', x); </script> </body> </html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<!DOCTYPE html>
<html>
<head>
    <title></title>
    <style type="text/css">
        div{
            height: 20px;
            widows: 20px;
            font-size: 26px;
            font-weight: bold;
        }
    </style>
</head>
<body>
    <div id="div1">
        HELLO WORLD0
    </div>
    <div id="div2">
        HELLO WORLD2
    </div>
    <div id="div3">
        HELLO WORLD3
    </div>
    <div id="div4">
        HELLO WORLD4
    </div>
    <div id="div5">
        HELLO WORLD5
    </div>
    <div id="div6">
        HELLO WORLD6
    </div>
    <div id="div7">
        HELLO WORLD7
    </div>
    <button id="btn">click me</button>
    <script type="text/javascript">
        var k = 0;
        function x() {
            if(k >= 7) return;
            document.getElementById('div'+(++k)).innerHTML = 'hello world'
        }
        document.getElementById('btn').addEventListener('click', x);
    
    </script>
</body>
</html>

新建一个html项目,然后再Chrome中打开它,接着按F12切换到开发者模式,选择Timeline面板,点亮区域1左上角的那个小圆圈,你可以看到它变成了红色,然后开始操作界面。连续按下button执行我们的js程序,等待所有div的内容都变成hello world的时候再次点击小圆圈,熄灭它,这时候你就可以看到Timeline中的图表信息了,如下图所示:

图片 4

在区域1中,左下角有一组数字2.0MB-2.1MB,它的意思是在你刚刚操作界面这段时间内,内存增长了0.1MB。底部那块浅蓝色的区域是内存变化的示意图。从左到右,我们可以看到刚刚浏览器监听了4000ms左右的行为动作,从0~4000ms内区域1中列出了所有的状态。接下来我们来仔细分析一下这些状态的具体信息。在区域2种,滚动鼠标的滚轮,你会看到时间轴会放大缩小,现在我们随着滚轮不断缩小时间轴的范围,我们可以看到一些各个颜色的横条:

图片 5

在操作界面时,我们点击了一次button,它耗费了大约1ms的时间完成了从响应事件到重绘节目的一些列动作,上图就是在789.6ms-790.6ms中完成的这次click事件所发生的浏览器行为,其他的事件行为你同样可以通过滑动滑轮缩小区域来观察他们的情况。在区域2种,每一种颜色的横条其实都代表了它自己的独特的意义:

图片 6

每次点击都回到了上面的图一样执行若干事件,所以我们操作界面时发生的事情可以做一个大致的了解,我们滑动滚轮把时间轴恢复到原始尺寸做个总体分析:

图片 7

可以看到,每一次点击事件都伴随着一些列的变化:html的重新渲染,界面重新布局,视图重绘。很多情况下,每个事件的发生都会引起一系列的变化。在区域2种,我们可以通过点击某一个横条,然后在区域4种更加详细地观察它的具体信息。我们以执行函数x为例观察它的执行期的状态。

图片 8

随着在事件发生的,除了dom的渲染和绘制等事件的发生之外,相应地内存也会发生变化,而这种变化我们可以从区域3种看到:

图片 9

在上文中已经向大家做过区域3的介绍,我们可以看到js堆在视图中不断地再增长,这时因为由事件导致的界面绘制和dom重新渲染会导致内存的增加,所以每一次点击,导致了内存相应地增长。同样的,如果区域3种其他曲线的变化会引起蓝色线条的变化,这是因为其他(绿色代表的dom节点数、黄色代表的事件数)也会占有内存。因此,你可以通过蓝色曲线的变化形势来确定其他个数的变化,当然最直观的方式就是观察括号中的数字变化。js内存的变化曲线是比较复杂的,里面参杂了很多因素。我们所列出来的例子实际上是很简单的。目前相信你对Timeline的使用有了一定的认识,下面我们通过一些Google浏览器官方的实例来更好的了解它的作用(因为观看示例都必须FQ,所以卤煮把js代码copy出来,至于简单的html代码你可以自己写。如果可以FQ的同学就无所谓了!)

(官方测试用例一) 查看内存增长,代码如下:

JavaScript

var x = []; function createSomeNodes() { var div, i = 100, frag = document.createDocumentFragment(); for (;i > 0; i--) { div = document.createElement("div"); div.appendChild(document.createTextNode(i

  • " - "+ new Date().toTimeString())); frag.appendChild(div); } document.getElementById("nodes").appendChild(frag); } function grow() { x.push(new Array(1000000).join('x')); createSomeNodes();//不停地在界面创建div元素 setTimeout(grow,1000); }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
var x = [];
 
function createSomeNodes() {
    var div,
        i = 100,
        frag = document.createDocumentFragment();
    for (;i > 0; i--) {
        div = document.createElement("div");
        div.appendChild(document.createTextNode(i + " - "+ new Date().toTimeString()));
        frag.appendChild(div);
    }
    document.getElementById("nodes").appendChild(frag);
}
function grow() {
    x.push(new Array(1000000).join('x'));
    createSomeNodes();//不停地在界面创建div元素
    setTimeout(grow,1000);
}

通过多次执行grow函数,我们在Timeline中看到了一张内存变化的图:

图片 10

通过上图可以看出js堆随着dom节点增加而增长,通过点击区域1中顶部的垃圾箱,可以手动回收一些内存。正常的内存分析图示锯齿形状(高低起伏,最终回归于初始阶段的水平位置)而不是像上图那样阶梯式增长,如果你看到蓝色线条没有回落的情况,并且DOM节点数没有返回到开始时的数目,你就可以怀疑有内存泄露了。

下面是一个用异常手段展示的正常例子,说明了内存被创建了又如何被回收。你可以看到曲线是锯齿型的上下起伏状态,在最后js内存回到了初始的状态。(官方示例二)   js代码如下:

JavaScript

var intervalId = null, params; function createChunks() { var div, foo, i, str; for (i = 0; i < 20; i++) { div = document.createElement("div"); str = new Array(1000000).join('x'); foo = { str: str, div: div }; div.foo = foo; } } function start() { if (intervalId) { return; } intervalId = setInterval(createChunks, 1000); } function stop() { if (intervalId) { clearInterval(intervalId); } intervalId = null; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
var intervalId = null, params;
 
function createChunks() {
    var div, foo, i, str;
    for (i = 0; i < 20; i++) {
        div = document.createElement("div");
        str = new Array(1000000).join('x');
        foo = {
            str: str,
            div: div
        };
        div.foo = foo;
    }
}
 
function start() {
    if (intervalId) {
        return;
    }
    intervalId = setInterval(createChunks, 1000);
}
 
function stop() {
    if (intervalId) {
        clearInterval(intervalId);
    }
    intervalId = null;
}

执行start函数若干次,然后执行stop函数,可以生成一张内存剧烈变化的图:

图片 11

还有很多官方实例,你可以通过它们来观察各种情况下内存的变化曲线,在这里我们不一一列出。在这里卤煮选择试图的形式是条状图,你可以在区域1中选择其他的显示方式,这个全靠个人的爱好了。总而言之,Timeline可以帮助我们分析内存变化状态(Timeline直译就是时间轴的意思吧),通过对它的观察来确定我的项目是否存在着内存泄露以及是什么地方引起的泄露。图表在展示上虽然很直观但是缺少数字的精确,通过示图曲线的变化我们可以了解浏览器上发生的事件,最主要的是了解内存变化的趋势。而如果你希望进一步分析这些内存状态,那么接下来你就可以打开Profiles来干活了。这将是我们这个系列的下一篇文章要介绍的。

1 赞 9 收藏 2 评论

图片 12

Web性能优化:What? Why? How?

2015/06/23 · HTML5 · 1 评论 · 性能优化

原文出处: 木的树   

为什么要提升web性能?

Web性能黄金准则:只有10%~20%的最终用户响应时间花在了下载html文档上,其余的80%~90%时间花在了下载页面组件上。

web性能对于用户体验有及其重要的影响,根据著名的2-5-8原则:

  • 当用户在2秒以内得到响应,会感觉系统的响应非常快
  • 当用户在2-5秒之内得到响应,会感觉系统的响应速度还可以
  • 当用户在5-8秒之内得到响应,会感觉系统的响应非常慢,但还可以接受
  • 当用户在8秒之后都没有得到响应,会感觉系统糟透了,甚至系统已经挂掉;要么打开竞争对手的网站,要么重新发起第二次请求

凡事都需要研究,通过科学的研究我们就可以找到事物的发展规律。这里要感谢雅虎的工程师总结的14条前端优化法则,使得我们可以站在巨人的肩膀上。《高性能网站建设》这本书中的14条优化原则,总结起来主要是以下个方面的优化:

  1. 减少HTTP请求
  2. 页面内部优化
  3. 启用缓存
  4. 减少下载量
  5. 网络连接上的优化

为什么减少HTTP请求可以提高Web性能?

要回答这个问题,我们就要了解当浏览器向服务器发送一个http请求知道获取数据都经历哪些过程:

开启一个链接(tcp/ip的三次握手过程) -》 发送请求 -》 等待(网络延迟跟服务器的处理时间)-》 下载数据

我们看一下百度首页中的http请求在各阶段耗费的时间,上面不同的颜色代表下图中的不同阶段

图片 13

(点击查看大图)

可以看到除了图片之外,其余大部分http请求的事件花在了建立连接与等待阶段。

http协议建立在TIC/IP协议之上,在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 简单来说三次握手就是一个身份确认的过程:

(第一次握手:主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,主机B由SYN=1知道,A要求建立联机;)

晴儿:你是潇哥哥吗,我是晴儿

(第二次握手:主机B收到请求后要确认联机信息,向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包)

潇剑:这货是谁,一箫一剑走江湖,下一句是什么?

(第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number=(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。)

晴儿:这首诗。。。你真的是潇哥哥,一萧一剑走江湖,千古情愁酒一回。。。

潇剑:晴儿,你真的是晴儿。。。。

(啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪。。。。。。。。。。。。)

言归正传,这个过程也是需要消耗时间的,在百度首页找到一个极端的例子:图片 14

(点击查看大图)

而等待的时间通常也大于内容下载的时间,这里同样找到一个极端例子:图片 15

(点击查看大图)

由此我们可以得出结论:一个http请求绝大多数的时间消耗在了建立连接跟等待的时间,优化的方法是减少http请求。

如何提高web性能?

1、减少HTTP请求

一般来说要减少http请求通常从两个方面下手:减少图片的请求、减少脚本文件与样式表的请求

图片的减少通常有两种方式:css sprites、内联图片、IconFont。

CSS Sprites:将多张图片合并成一幅单独的图片,使用css的background-position属性,将html元素的背景图片放到sprites 图片中的期望位置上。使用这项技术的附加优点是他降低了下载量,合并后的图片比分离的图片和更小,因为它降低了图片自身的开销(颜色表、格式信息等等)。实际项目中css sprites是一项体力活,因为开发过程中需要对这张大图进行维护(添加、减少图片),张鑫旭同学的文章中有介绍如何管理sprites图片可以作为参考(这里)。如果需要在页面中为背景、链接、导航栏提供大量的图片,css sprites绝对是一种优秀的解决方案(干净的标签、较少的图片、较短的响应时间)。

内联图片:通过使用data:URL模式可以再页面中包含图片而无需任何额外的请求。缺点就是IE8以下的浏览器不支持这种方式,而IE8在数据大小上有限制,只能支持23kb以内的数据。对于较小的图片来说可以直接内联到web页面中,但对于大图片内联到页面里会导致页面变大,聪明的做法是使用css,将内联的图片作为背景使用,并放到外部样式表中,这意味着数据可以缓存在样式表内部。使用外部样式表虽然增加了一个http请求,但样式可以被浏览器缓存,得到额外的收获。另外一点需要注意:base64是有损压缩。

图片 16

IconFont:图标字体,这是近年来新流行的一种以字体代替图片的技术。它可以适应任何分辨率而不会出现图片模糊问题,与图片相比它具有更小的容量,更高的灵活性(像字体一样可以设置图标大小、颜色、透明度、hover状态、反转等),IE8以上的浏览器都支持该技术。在使用IconFont之前,你首先要确定你选则的字体库是否是收费。详细内容可以参考这篇文章:图标字体化浅谈

减少脚本与样式表的请求主要原则就是合并。在实际开发中我们遵循模块化的原则将代码分散到许多小文件中,按照软件开发的原则这是完全正确的,但对于上线页面来说,每一个文件都会产生一个http请求,严重影响性能。和css sprites一样,将这些小文件合并到一个文件中,可以减少http请求的数量并缩短最终用户响应时间。在合并过程中我们还需要使用工具精简(移除不必要的字符以减小文件大小缩减下载时间)和混淆(除了移除不必要字符外,还会改写源代码,比如函数和变量名使用更短的标量名)Javascript代码。对于采用AMD或CMD进行模块化开发的同学,在合并过程中通常会将依赖的其他模块打包到一个文件中,而模板html通常以字符串的方式内联到Javascript文件中。目前最常用的前端构建工具就是glup,这里有一篇初步应用的文章:前端 | gulp 打包 require.js 模块依赖

2、页面内部优化

关于页面内部优化主要方向:样式表放在顶部、脚本文件放在底部、避免css表达式、把脚本的样式表放在外部、移除重复脚本

关心性能的工程师都希望页面能否尽快的展现在用户面前,对于页面中很多内容的页面我们都希望内容能够逐步加载,为用户提供可视化回馈。而将样式表放在底部会导致浏览器阻止内容逐步呈现。为避免当页面变化时重绘页面元素,浏览器会阻塞页面呈现,直到样式表解析完毕(详细内容可以查看我的这篇博客)。所以如果将样式表放在顶部并不会减少资源的加载时间,它减少的是页面的呈现时间。小米主页曾经犯过这样的错误:图片 17

将样式表放在底部会阻塞页面的逐步呈现,而将script文件放在页面顶部同样会阻塞页面的逐步呈现。script元素会阻塞后续内容的解析,因为script中可以同过document.write来更改页面。解决的办法就是将script标签放在页面底部。这样既可以让内容逐步呈现,也可以提高下载的并行度。如果我们确定不需要document.write那可以为script标签加上asyn属性(Ie中要加上defer)提高并行下载度。

CSS表达式是ie支持的可以用来动态更改css属性的一种方式,我们不需要了解太多,她的书写方式如下,一旦在产品中发现expression关键字就要彻底消灭。

图片 18

使用外部脚本和样式这一条,我想凡是有点经验的工程师都会这么干。

移除重复脚本:这条说的主要是避免在页面中多次加入同一份Javascript代码,如果我们的开发中有依赖管理的方式比如AMD、CMD,基本不会出现这种情况。

 

3、启用缓存

关于缓存的使用这里介绍两套方案:expires/If-Modified-Since、Cache-Control/Etag;前者是HTTP1.0中的缓存方案,后者是HTTP1.1中缓存方案,若http头部中同时出现二者,后者的优先级更高。

If-modified-since的方式通常被称为条件Get。浏览器缓存中保存了一个文件的副本,但需要向服务器询问此副本是否可用。If-Modified-Since是浏览器将最后修改时间发送给服务器,服务器相应头中Last-Modified进行对比;若If-Modified-Since <= Last-Modified 则浏览器读取本地副本。此时响应状态为304 Not Modified, 并不在发送响应体。

图片 19

Expries:虽然使用条件GET和304响应能够节省时间,但浏览器跟服务器端仍然要发送一次请求进行确认。通过明确设置副本的过期时间可以避免条件GET。当浏览器发现响应头中的expires时,会将过期时间和文件一起保存到缓存中去。在过期之前一直从缓存中读取。expires头使用一个特定的时间来指定缓存的有效期,他要求浏览器与服务器时间完全一致。而且一旦过期,服务器端配置中需要重新设顶一个过期时间。

图片 20

ETag(实体标签):是服务器用于检查浏览器缓存有效性的一种机制。ETag在HTTP1.1中引入,ETag是唯一标识了一个组件的一个特定版本的字符串。唯一的格式约束是这个字符串必须使用双引号。如果浏览器要验证一个组件是否有效他会使用If-None-Match将etag字符串传送给服务器。如果ETag是匹配的,服务器端会返回304.(如果实体数据需要根据User-Agent或Accept-Language来改变时,ETag提供了更高的灵活性)。对于使用服务器集群的网站来说,从一台服务器到另一台服务器,ETag通常是无法匹配的。这是ETag的问题。而且即便同时使用If-Modified-Since和If-None-Match也并不能达到预期效果。解决方法总是有的:自定义Etag格式

图片 21

Cache-Control:HTTP1.1引入了来代替Expires,它使用max-age指令来指定副本被缓存多久,该指令以秒为单位定义了一个更新窗,组件从被请求开始到现在的秒数小于设定值,则一直使用副本。避免了一次http请求。相比Expries,Cache-Control指令提供了更细粒度的控制。详细内容请看大额同学的文章:透过浏览器看HTTP缓存

 

4、减少下载量

减少下载量最有效的方式就是开启gzip压缩,gzip是GNU开发的一种免费格式。压缩组件通过减小http响应的大小来加快响应速度。HTTP1.1通过使用DontTrackMeHere来标识支持的压缩,如果服务器看到这个标识,会使用请求头中的一种方式来压缩响应。并通过Content-Encoding来通知web客户端。很多网站会压缩html文件,实际上包括xml跟json在内的任何文本都可以压缩,但图片和pdf不应该压缩。根据经验通常可以对大于1kb或2kb的文件进行压缩。压缩通常能将响应的数据量减少70%。压缩的成本在于:服务器需要耗费额外的cpu进行压缩,客户端需要解压缩。所以需要在cpu的消耗和数据块的大小之间进行取舍。

 

5、优化网络连接

网络连接的优化主要有三个规则:使用CDN加速、减少DNS查找、避免重定向

CDN:CDN是地理上分布的web server的集合,用于更高效地发布内容。通常基于网络远近来选择给具体用户服务的web server。 这缩短了资源的传输响应时间,有效提高web性能。

DNS用于映射主机名和IP地址,一般一次解析需要20~120毫秒。浏览器会首先根据页面的主机名进行域名解析,在有ISP返回结果之前页面不会加载任何内容,所以减少DNS查找可以有效降低等待时间。为达到更高的性能,DNS解析通常被多级别地缓存,如由ISP或局域网维护的caching server,本地机器操作系统的缓存(如windows上的DNS Client Service),浏览器。IE的缺省DNS缓存时间为30分钟,Firefox的缺省缓冲时间是1分钟。 我们能做的是尽量减少一个页面的主机名,但要在浏览器最大并行下载数跟dns查找之间做权衡。根据雅虎的研究,最好将主机名控制在2-4个内。

重定向:将一个URL重新路由到另一个URL。重定向功能是通过301和302这两个HTTP状态码完成的,如:
HTTP/1.1 301 Moved Permanently
Location:
Content-Type: text/html

浏览器自动重定向请求到Location指定的URL上,重定向的主要问题是降低了用户体验。 种最耗费资源、经常发生而很容易被忽视的重定向是URL的最后缺少/,导致自动产生结尾斜线的原因是,浏览器在进行get请求是必须指定一些路径;如果没有路径它就会简单的使用文档根。(主机缺少结尾斜线是不会发生重定向:)

雅虎的14条优化规则在很长的一段时间里发挥着重要作用,随着技术的发展,单单这十四条原则已经不能够满足前端性能优化。在一些大公司出现了前端工程化这一概念,详细内容可以参考一下这篇文章:前端性能优化工程化进阶

 

参考资料:

web前端性能意思、关注重点、测试方案、

WEB站点性能优化实践(加载速度提升2s)

HTTP协议三次握手过程

高性能WEB开发 – 为什么要减少请求数,如何减少请求数!

我是如何对网站CSS进行架构的

图标字体化浅谈

利用ETag缓存优化请求

透过浏览器看HTTP缓存

1 赞 2 收藏 1 评论

图片 22

Twitter的“fave” 动画

最近 Twitter 通过引入一段新的动画重新设计了“fave”按钮(也叫“fav”)。这段动画并不依赖 CSS transition,而是由一系列图片组成的。下面展示如何用 CSS 的 animation-timing-function 属性中的 steps 时序函数(timing function)重新制作这段动画。

运动产生的错觉

这段动画的效果类似于观看古老的西洋镜,该装置呈现的是一系列连续的围绕着圆筒的插画。在下面的示例中,我们不使用圆筒,而是在某个元素内部呈现一系列图片。

示例

把鼠标悬停在星星上就可以看到动画效果(请到原文查看动画效果——译者注)。

在本示例中,我们将从制作一系列能组成动画的图片开始。在这里,我们使用来自 Twitter 的“fave”图标动画的部分图片集:

图片 23

为了能让这些帧动起来,我们需要把它们放置在一排上。在这个文件中,这些帧已经排列在一排上了,这意味着我们可以通过设置背景位置(background-position)属性使背景从第一帧过渡到最后一帧。

图片 24

本文由澳门新葡亰平台官网发布于web前端,转载请注明出处:Chrome开发者工具不完全指南,Web性能优化

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。