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

快来打我* 2022-08-21 00:12 10阅读 0赞

## 页面性能的基础因素 ##

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

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

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

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

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

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

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

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

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

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

在后面Statistics页签会显示资源占比，以及启用缓存（下次访问）时需要发送的请求数和资源大小:  
![BasicOfPageSpeed\_YSlow\_Stat][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等。参考:[管好页面缓存][Link 2]

## 关键渲染路径 (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][BasicOfPageSpeed_Jank]  
如果使用PageSpeed Insights，可以得到关于Blocking CSS的建议。

[Link 1]: http://blog.csdn.net/horkychen/article/details/17517411
[BasicsOfPageSpeed]: /images/20220731/8fe15d233fde4616a4dd028932b1521f.png
[BasicOfPageSpeed_net]: /images/20220731/3ba39d45f4be448bbde5c82a2a5388c1.png
[BasicOfPageSpeed_net2]: /images/20220731/edeca4c1bf1644f8a4e5b198e42a2568.png
[BasicOfPageSpeed_Audit]: /images/20220731/ba2eb1ac0a5d450580e176d6908be829.png
[BasicOfPageSpeed_YSlow_Weight]: /images/20220731/37e8e370b67b4929b868bed77a389bc3.png
[BasicOfPageSpeed_YSlow_Stat]: /images/20220731/4a275bcc921d44f3b9b8dfd583e2da0d.png
[The future of loading CSS]: https://jakearchibald.com/2016/link-in-body/
[Image Optimization]: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization
[Link 2]: http://blog.csdn.net/HorkyChen/article/details/19369521
[BasicOfPageSpeed_Jank]: /images/20220731/7bc1d42471034ab18e5d847591ae6dfc.png