页面性能的基础因素 - 《Designing for Performance》

标签: 性能优化前端
2632人阅读 评论(1) 收藏 举报
分类:

页面性能的基础因素

最近读这本小书Designing for Performance,突然想到之前一篇网络性能评价只写了一半,在这里也里也算一个做个补充。

考虑页面性能可以从两种场景,第一个场景也是因素最多的场景,即首次访问。第二个场景则是重复访问,缓存将起决定性作用。

不同的页面类型的性能优化策略也是不一样的,比如富文本页面,富多媒体页面,响应式设计的页面,游戏页面等。

浏览器也提供了很多工具和插件,比如Chrome DevTools, YSlow和PageSpeed Insight都有相应的插件,可以为开发者提供页面优化建议,这是最为简捷的方式。我在这里也主要使用Chrome进行分析,部分会配合WebPageTest工具。

要优化页面性能,了解浏览器如何渲染页面是非常重要的。以下是浏览器加载的整套流程,特别强调了对首次打开性能影响很大的网络加载流程:
BasicsOfPageSpeed
其中如果HTTPS,建立连接的过程中还需要进行身份认证。

通过Chrome Inspect中的网络也可以看到整个加载数据量,以及耗时:
BasicOfPageSpeed_net
上图是新浪首页的数据,共发出415请求,收到6.5MB的数据,主要是图片大多,果然是个大站!

点开可以看到细节的数据耗时:
BasicOfPageSpeed_net2
上面可以看到为请求建立与服务器的连接的开销还是比较大的。特别是在移动网络下,DNS解析,错误重连的成本都非常高,浏览器厂商也都会针对性的进行优化。

无论是以前的Pipeline, 和现在的Http2都可以达到连接复用的目的,也可以省掉这部分的开销。

Chrome的开发者工具提供了Audit, 可以提供网络相关优化和页面性能优化的建议, 比如:
BasicOfPageSpeed_Audit

在Chrome Web Store里安装YSlow和PageSpeed Insights插件,就可以进一步分析页面的性能,以及提供相关的建议。下图是YSlow的显示页面组件的内容:
BasicOfPageSpeed_YSlow_Weight

在后面Statistics页签会显示资源占比,以及启用缓存(下次访问)时需要发送的请求数和资源大小:
BasicOfPageSpeed_YSlow_Stat
可惜这只是理想,新浪有些资源的url带有随机数,也就是每次请求的url并不相同,会导致http cache无法使用,会重新加载。

最终新浪首页的性能显示不怎么样,YSlow给出了D,附上一堆建议,点来Grade页签就可以看到。

PageSpeed Insights会给出相类似的建议,不过个人还是建议使用PageSpeed Insights, 它给出的建议会更加符合当前业界的标准。

影响加载的主要因素

除了TTFB这种主要由网络环境和后台服务器决定的因素外,页面设计,以及包括User Agent(客户端,如浏览器)可能影响的因素包括:

  • 连接管理 (连接数和复用)
    在HTTP下本来有一个Pipeline的机制,用来达到一个HTTP连接来并发获取多个资源,但是服务器支持的少。
    另一种方法是Keep alive的常连接。即User Agent尝试保持若干个连接,完成一个资源的加载后,这个连接可以继续用来加载另一个资源。这样就没有重新建立连接的开销。
    而HTTP 2最大的特色就是让每一个连接支持多个资源的并发请求。

  • 请求数
    减少请求数,就是要减少资源请求。比如将多张小图合成一张Sprite图片就是典型的做法。也不是请求数越少越好,极端的将所有资源都放到页面里,就是灾难了。还要从浏览器解析、渲染页面的行为上来定义。比如head中的CSS加载会阻塞页面解析,如果使用body中的<link rel="stylesheet">,区分出可显示共域的CSS, 页尾的CSS属生,让浏览器只在需要时加载相应的CSS反而能获得更好的用户体验。参考:The future of loading CSS

  • 请求大小
    因为网络里上行和下行的速度差异,请求的大小也会对页面性能有所影响, 所以要避免不必要的请求头信息,其中Cookie最为明显。首先Cookie的存储、检索和提取就要耗费性能,再加上Cookie的应用往往是针对某个域名下或者路径下的所有请求,会导致性能的影响被放大。

  • 资源大小
    如果资源较小,当然收取数据的时间就会减少,后续的处理也会更加有效率。比如JS可以使用一些工具简化,图片也可以根据不同的应用,选择不同的图片格式(算法),或者压缩比。特别是值得注意的是一些图片常常含有一些不需要的信息,比如EXIF,地理位置信息,自定义调色板等,有时会很大,也可以使用一些工具进行简化。之前遇到过一些图片网站里用户上传的图片超大的情况,就是因为图片里保留了一些Photoshop的冗余信息。参考: Image Optimization
    HTML5新的响应式图片更是允许根据客户端(User Agent)的屏幕大小,而选择不同的图片。

  • HTTP Cache
    网络层的缓存模块,负责管理可缓存的资源,尽量复用缓存中已经有的可用资源。最快的请求就是不发请求,善于使用Http Cache,可以大大优化除首次打开外页面性能。但是一些网站遇到一些缓存问题时,常常简单的为url增加一个随机数,让缓存失效,这样既让客户端的整体缓存命中率下降(缓存了很多不必要的资源),强烈建议不要使用这种方法。
    Http Cache的实现各个浏览器并不相同,命中率也有差异。对前端开发者也是不可见的,如果需要更加细粒度的控制缓存,可以使用H5提供的存储功能,比如Local Storage, App Cache等。参考:管好页面缓存

关键渲染路径 (Critical Rendering Path)

开始加载页面,到实际显示出内容,有一个最小的路径,即关键渲染路径。尽量缩短这条路径才能真正优化到用户的体验。
最核心的流程是浏览器收到页面数据后解析为DOM (Document Object Model), 加载CSS文件,生成CSSOM,计算各个元素的排版数据生成Layout Tree, 结合者CSSOM生成Render Tree,再交由渲染模块完成渲染显示出页面内容。
这过程中包括很多的并发行为,因为串行完成的性能不可能达到用户体验的要求。

  • CSS
    在这个路径主要是注意一些会阻塞页面解析的元素,如CSS。前面提到CSS文件放到head和body中的方式。

  • JavaScript
    直接出现在页面中的JavaScript会阻塞页面解析, 所以需要将一些JavaScript可以改为异步加载和执行。

定义:可操作时间 (Time To Interactivity)
可操作时间是指从开始加载页面到用户可以在页面进行操作(如搜索,点击链接等)的时间。
通过优化关键渲染路径可以减少可操作时间,包括以下方法:

  • 异步加载内容
  • 优先加载可见内容
  • 遵循CSS/JS加载的最佳实践 (看YSlow和PageSpeed Insights的报告)
  • 缓存资源
  • 优先保证主要用户行为尽早可用

比如下面这个Chrome DevTools显示出一个Long Frame, 从前面一个Frame这里花去了很长的时间,这一般代表卡顿的出现 (只有9fps)。
BasicOfPageSpeed_Jank
如果使用PageSpeed Insights,可以得到关于Blocking CSS的建议。

2
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1525165次
    • 积分:16778
    • 等级:
    • 排名:第616名
    • 原创:221篇
    • 转载:30篇
    • 译文:47篇
    • 评论:362条
    微博/MSN/EMail

    新浪微博:Horky
    QQ:324014340
    Mail:horky.chen@gmail.com
    微信公众号 (聚焦软件开发):
    博客专栏
    最新评论