实践一下前端性能分析

本文涉及的产品
.cn 域名,1个 12个月
简介:

最近在读一本经典书《高性能网站建设进阶指南》。

虽然书籍很多年前就出版了,但里面的内容还是耐人寻味,这次就好好的实践了一下。

纸上得来终觉浅,绝知此事要躬行,实践中将会发现一些问题。

有个官方网址《Even Faster Web Sites》,点击“Run the Examples”按钮,就能进入在线demo。

在Github上面有个叫awesome-wpo的项目,里面记录了各个方面关于性能的资源,有书籍、文章、工具等。

下面所有的实验都是在Chrome 49浏览器中执行的。

 

一、浏览器并行下载数量

浏览器的并发请求数目限制是针对同一域名的。

同一时间针对同一域名下的请求有一定数量限制,超过限制数目的请求会被阻塞。

所以我们经常能看到不同静态资源会有不同域名,例如图片、JavaScript、CSS等。

HTTP1.1与HTTP1.0,限制的数量还不一样。

1)HTTP1.1

先来看看browserscope网上的数量限制的统计结果,比IE6、IE7那会儿进步了很多。

接下来做一个对比,分别是一个域名两个域名,分别加载图片。

当一个域名的时候最多只能并发6个请求,而两个域名的时候能并发10个请求。

 

2)长连接

由于长连接的关系,HTTP1.1建议每个服务器建立少量的连接。

如果浏览器支持 keep-alive(长连接),它会在请求的包头中添加:

长连接的原理是使用同一个TCP连接来发送和接收多个HTTP请求/应答,而不是为每一个新的请求/应答打开新的连接的方法。

当客户端发送另一个请求时,它会使用同一个连接。这一直继续到客户端或服务器端认为会话已经结束,其中一方中断连接。

下图左边每次请求后都会断开,右边就是请求后不会马上断开。

所以想要高并发量还可以降级到HTTP1.0,不过具体情况如何,我还没试验过。

 

3)Cookie-free Domains

YSlow中有23条规则,第20条就是“Use Cookie-Free Domains for Components”。

在请求下载静态小图片、静态小文件的时候,浏览器会把它当成普通请求一样,在request的header信息里附加cookie信息。

如果每个header都附加1kB的cookie,那么对于一个有50个小文件的复杂网页来讲,就白白增加了50kB的传输量。

网上有很多相关的解决方案,可以尝试一下。

 

二、行内脚本阻塞并行下载

览器会保持css和js的解析顺序,如果把行内脚本放在样式表之后,会明显地延迟资源的下载(结果是样式表下载完成并且行内脚本执行完毕时,后续资源才能开始下载)。

这是因为行内脚本可能含有依赖于样式表中样式的代码,比如document.getElementsByClassName()

行内脚本就是将脚本直接写在HTML页面中。

<head>
  <link rel="stylesheet" href="css/all-normal.css" type="text/css" />
</head>
<body>
  <div id="content"></div>
  <script>
    var content = '';
    for(i=1; i<1000000; i++)
        content += '写入页面';
    document.getElementById('content').innerHTML = content;
  </script>
  <img src="images/ui.png" />
</body>

下面通过Chrom的工具查看下:

再来看看ui.png这个请求的详细情况,可以参考下Google中的文档,不过需要翻一下才能看到。

Stalled:浏览器得到要发出这个请求的指令,到请求可以发出的等待时间,一般是代理协商、以及等待可复用的TCP连接释放的时间,不包括DNS查询、建立TCP连接等时间等。

Request sent:请求第一个字节发出前到最后一个字节发出后的时间,也就是上传时间。

Waiting(TTFB) :请求发出后,到收到响应的第一个字节所花费的时间(Time To First Byte)。

Content Download:收到响应的第一个字节,到接受完最后一个字节的时间,就是下载时间。

 

的确出现了延时下载,我将“script”标签去掉后,看到的确是并行下载的。

 

三、图像优化

平时就会做图像优化,例如制作Sprite图等。这里是介绍下压缩图片。

关于压缩的原理,涉及到些算法,可以上网查询下。

网友Jia在《图片原理与优化》说:

常见的格式中JPG、PNG、GIF亦属于位图,所以它们的数据结构大致相同,只是每一种图片格式都有不同的压缩算法,不同的扫描方式,但是优化的方法都有一个共同点,都是围绕着每个像素颜色值来下手。

1)工具

公司现在开发都用gulp构建工具,里面就有个插件“gulp-image”,用这个工具压png图片,能压掉很多,jpg就不多了。

关于构建工具可以参考《前端自动化构建工具gulp记录

网上还提供很多在线工具,例如国外的tinypng,国内的tuhaokuai

下图来自于tinypng网,国宝熊猫帮我压缩了54%的质量,不过这个网站我上了好久才上去。

 

2)webP

WebP,是一种支持有损压缩和无损压缩的图片文件格式,派生自图像编码格式 VP8。

根据 Google 的测试,无损压缩后的 WebP 比 PNG 文件少了 45% 的文件大小,即使这些 PNG 文件经过其他压缩工具压缩之后,WebP 还是可以减少 28% 的文件大小。

兼容性方面,Android兼容性较好,毕竟是自己的东西,不过IOS Safrai完全不支持,下图中显示中国的浏览器已经覆盖到了67.37%。

 

四、iframe

在多年前曾经写过一篇基础概念的iframe,叫《iframe的一些记录》。

一直能看到iframe的种种缺点,但是并没有通过数据表达出来,这次用数据说明一下。

1)阻塞onload事件

在“Iframes Blocking”这个页面中,通过iframe加载一个页面,这个页面要4秒后才加载完,直接导致的父页面也要4秒后才能加载成功。

 

2)脚本位于iframe之前

在“Script Before Iframe”这个页面中,script脚本标签写在了iframe之前。

图中红色框框中的就是iframe中的内容,的确被阻塞了。

后面又试验了一下将CSS放在iframe之前之后,并不会被阻塞。

 

3)iframe中连接共享

在“Parent and Iframe Connections”这个页面中,父页面和iframe中的页面都包含了5张图片。

这五张图片并不是并行下载,而是有先后顺序的,红色方框中的图片来自于iframe。

 

五、CSS选择符

下面这些就是CSS选择符

#toc { margin-left: 20px; }
.chapter { font-weight: bold; }
A { text-decoration: none; }
H1 + #toc { margin-top: 40px; }
#toc > LI { font-weight: bold; }
#toc A { color: #444; }
* { font-family: Arial; }
[href="#index"] { font-style: italic; }
[title~="Index"] { font-style: italic; }
A:hover { text-decoration: underline; }

归纳下来有5种选择符,元素、关系、属性、伪类和伪对象选择符。

CSS选择符是从右向左匹配的,在MDN的《编写高效的 CSS》中介绍了几种高效CSS指南。

 

1)选择器测试结构

在“Selector Tests”页面中有6种写好的,页面中1000个那种结构。

1. Baseline设置了CSS类,但不会匹配

2. Tag就多了个A标签CSS设置

3. Class设置了A中的class属性

4. Child使用了关系选择符中的子选择符“>”

5. Descendant使用了关系选择符中的包含选择符

6. Universal使用了通配符

<div>
  <div>
    <div> <p> <a id='id0001' class='class0001'>0001</a> </p> </div>
    ...
    <div> <p> <a id='id1000' class='class1000'>1000</a> </p> </div>
  </div>
</div> 

 

2)耗时记录

 

Baseline

Tag

Class Child Descendant Universal
CSS类

.noclass0001 {

  background: #CFD; 

}
...
.noclass1000 {

  background: #CFD;

}

A {

  background: #CFD;  

}
.noclass0001 {

  background: #CFD;

}
...
.noclass1000 {

  background: #CFD;

}

.class0001 {

  background: #CFD;  

}
...
.class1000 {

  background: #CFD;

}

DIV > DIV > DIV > P > A.class0001 {  

  background: #CFD;

}
...
DIV > DIV > DIV > P > A.class1000 {

  background: #CFD;

}

DIV DIV DIV P A.class0001 {  

  background: #CFD;

}
...
DIV DIV DIV P A.class1000 {

  background: #CFD;

}

P.pclass0001 * {

  background: #CFD;

}
...
P.pclass1000 * {

  background: #CFD;

}

耗时

85ms

63ms 71ms 101ms 77ms 501ms

耗时

60ms

67ms 479ms 185ms 444ms 76ms

耗时

59ms

1116ms 64ms 73ms 67ms 54ms

耗时

69ms

62ms 68ms 67ms 62ms 83ms

耗时

52ms

63ms 68ms 78ms 68ms 77ms

耗时

60ms

62ms 72ms 87ms 67ms 81ms

去掉最高和最低后

平均耗时

62ms

63.75ms 69.75ms 84.75ms 69.75ms 79.25

 还有一个“create your own”自定义类:

 

还附赠了4个选择器:“A.class DIV”,“id > A”,“.class [href]”,“DIV:first-child”。

 

行内脚本阻塞并行下载demo:

http://download.csdn.net/download/loneleaf1/9519133

 

参考资料:

浏览器允许的并发请求资源数是什么意思?

HTTP持久连接

chrome的timeline的问题?

了解无阻塞加载javascript脚本技术

无损压缩网站上的图片

图片原理与优化

图片格式与设计那点事儿

Clever PNG Optimization Techniques

WebP 探寻之路

提升网站用户体验—WebP 图片的高效使用





    本文转自 咖啡机(K.F.J)   博客园博客,原文链接:http://www.cnblogs.com/strick/p/5475758.html,如需转载请自行联系原作者


相关文章
|
1月前
|
缓存 前端开发 JavaScript
利用代码分割优化前端性能:策略与实践
在现代Web开发中,代码分割是提升页面加载性能的有效手段。本文介绍代码分割的概念、重要性及其实现策略,包括动态导入、路由分割等方法,并探讨在React、Vue、Angular等前端框架中的具体应用。
|
18天前
|
编解码 前端开发 开发者
探索无界:前端开发中的响应式设计深度实践与思考###
本文将带你领略响应式设计的精髓,一种超越传统页面布局限制的设计策略,它要求开发者以灵活多变的思维,打造能够无缝适应各种设备与屏幕尺寸的Web体验。通过深入浅出的讲解、实际案例分析以及技术实现细节的探讨,本文目的是激发读者对于响应式设计深层次的理解与兴趣,鼓励在实际应用中不断创新与优化。 ###
62 10
|
1月前
|
编解码 前端开发 开发者
前端开发中的响应式设计实践
前端开发中的响应式设计实践
|
1月前
|
编解码 前端开发 UED
探索无界:前端开发中的响应式设计深度解析与实践####
【10月更文挑战第29天】 本文深入探讨了响应式设计的核心理念,即通过灵活的布局、媒体查询及弹性图片等技术手段,使网站能够在不同设备上提供一致且优质的用户体验。不同于传统摘要概述,本文将以一次具体项目实践为引,逐步剖析响应式设计的关键技术点,分享实战经验与避坑指南,旨在为前端开发者提供一套实用的响应式设计方法论。 ####
65 4
|
1月前
|
JavaScript 前端开发 开发者
前端框架对比:Vue.js与Angular的优劣分析与选择建议
【10月更文挑战第27天】在前端开发领域,Vue.js和Angular是两个备受瞩目的框架。本文对比了两者的优劣,Vue.js以轻量级和易上手著称,适合快速开发小型到中型项目;Angular则由Google支持,功能全面,适合大型企业级应用。选择时需考虑项目需求、团队熟悉度和长期维护等因素。
56 1
|
29天前
|
编解码 前端开发 UED
探索无界:前端开发中的响应式设计哲学与实践####
本文不拘泥于传统摘要的框架,而是以一种对话的方式,引领读者踏入响应式设计的奇妙世界。想象一下,互联网如同一片浩瀚的海洋,而网页则是航行其中的船只。在这片不断变化的海域中,如何让我们的“船只”既稳固又灵活地适应各种屏幕尺寸和设备?这正是响应式设计的魅力所在。通过深入浅出的探讨,我们将一同揭开它背后的哲学思想与实战技巧,让你的网页在任何设备上都能展现出最佳姿态。 ####
22 0
|
1月前
|
JavaScript 前端开发 API
前端框架对比:Vue.js与Angular的优劣分析与选择建议
【10月更文挑战第26天】前端技术的飞速发展让开发者在构建用户界面时有了更多选择。本文对比了Vue.js和Angular两大框架,介绍了它们的特点和优劣,并给出了在实际项目中如何选择的建议。Vue.js轻量级、易上手,适合小型项目;Angular结构化、功能强大,适合大型项目。
45 1
|
1月前
|
前端开发 JavaScript API
现代前端框架中的响应式编程实践
现代前端框架中的响应式编程实践
37 0
|
2月前
|
人工智能 资源调度 数据可视化
【AI应用落地实战】智能文档处理本地部署——可视化文档解析前端TextIn ParseX实践
2024长沙·中国1024程序员节以“智能应用新生态”为主题,吸引了众多技术大咖。合合信息展示了“智能文档处理百宝箱”的三大工具:可视化文档解析前端TextIn ParseX、向量化acge-embedding模型和文档解析测评工具markdown_tester,助力智能文档处理与知识管理。
|
2月前
|
JavaScript 前端开发 算法
前端优化之超大数组更新:深入分析Vue/React/Svelte的更新渲染策略
本文对比了 Vue、React 和 Svelte 在数组渲染方面的实现方式和优缺点,探讨了它们与直接操作 DOM 的差异及 Web Components 的实现方式。Vue 通过响应式系统自动管理数据变化,React 利用虚拟 DOM 和 `diffing` 算法优化更新,Svelte 通过编译时优化提升性能。文章还介绍了数组更新的优化策略,如使用 `key`、分片渲染、虚拟滚动等,帮助开发者在处理大型数组时提升性能。总结指出,选择合适的框架应根据项目复杂度和性能需求来决定。