前端性能优化小纪 -

标签: geek | 发表时间:2018-02-21 00:00 | 作者:
出处:http://itindex.net/relian

天下武功,无坚不破,唯快不破。对前端而言,快意味着要求资源体量更小、数量更精简、内容更早呈现、交互更加人性化。当项目做到一定程度,就应该考虑性能的问题,前端的性能优化有诸多有迹可循的理论和方法,比如 Yahoo!性能军规、Google PageSpeed Insights Rules。

我们团队一个比较老的项目首屏加载大概需要20多秒,这严重影响了用户体验,于是进行了一次首屏加载的性能优化。

浏览器渲染过程

首先,稍微了解一下,浏览器接收到HTML/CSS/JavaScript等资源后的渲染过程:

浏览器在收到 HTML 文档之后会对文档进行解析开始构建 DOM (Document Object Model) 树,进而在文档中发现样式表,开始解析 CSS 来构建 CSSOM(CSS Object Model)树,这两者都构建完成后,开始构建渲染树。

DOM树描述了文档的结构与内容,CSSOM树则描述了对文档应用的样式规则,想要渲染出页面,就需要将DOM树与CSSOM树结合在一起,这就是渲染树。渲染树构建完毕后,浏览器得到了每个可见节点的内容与其样式,下一步工作则需要计算每个节点在窗口内的确切位置与大小,也就是布局阶段。当Layout布局事件完成后,浏览器会立即发出Paint Setup与Paint事件,开始将渲染树绘制成像素,绘制所需的时间跟CSS样式的复杂度成正比,绘制完成后,用户就可以看到页面的最终呈现效果了。

暂缓JavaScript解析

在上图构建DOM树时,<script>标签可能会阻塞html解析,从而影响首页加载速度,可以使用async进行异步加载或者用defer进行延迟加载。

async属性表示脚本会在下载后尽快执行,但不能保证脚本会按照顺序执行。

defer属性表示脚本会先下载,但会在整个页面都解析完成后再运行,并且按照脚本出现的先后顺序执行。

用网上一张图能比较明显得看出两者的不同之处。

蓝色线代表网络读取,红色线代表执行时间,这俩都是针对脚本的;绿色线代表 HTML 解析。

用这两个属性可以很好解决由<script>引起地加载缓慢问题。

减少不必要的HTML标签

从浏览器渲染的流程可以看出,如果HTML中有很多不必要的标签会影响DOM解析速度并且增加了HTML文件的大小,可以对嵌套过深的结构进行优化,去除不必要的标签。

减少CSS嵌套

CSS嵌套过深,会影响浏览器查找选择器的速度,一定程度上产出了很多冗余的字节,一般最多嵌套3层。

启用CSS Sprite

CSS Sprites在国内很多人叫css精灵,是一种网页图片应用处理方式。它允许你将一个页面涉及到的所有零星图片都包含到一张大图中去,这样一来,当访问该页面时,载入的图片就不会像以前那样一幅一幅地慢慢显示出来了。

该项目首页有有三张svg的图片,参考SVG Sprite对这三张照片进行了svg sprite的简单处理,后续在angular/cli中也可以参照这个SVG icon system with angular-cli对项目中的svg图片进行统一的处理。

进行css sprite处理时,注意以下几点:

  • 把图片横向合并,这样图片大小更小
  • 间距不要太大,这对图片大小影响不是很大,但对客户端解压时需要的内存更少

进行css sprite处理后,降低了首页资源请求次数。

对于图标类的图片,最好用iconfont来减少图片的额外请求。

压缩静态资源

合并打包后的js、css、图片文件体积一般会比较大,这个时候要对它们进行压缩处理。gulp和webpack都有相应的压缩插件。

针对个别图片,有时候也可以单独拿出来处理,可以去tinypng 进行在线压缩。

使用lazyload和preloading

在Angular中,可以在路由中用loadChildren来实现lazyload,这样可以实现按需加载,加快加载速度。

{
      path: 'home',
      loadChildren: 'app/home/home.module#HomeModule',
    },

首页显示的模块不应该过大,我们项目中首页加载的模块虽然使用了lazyload,但是模块太大,以至于严重影响了加载速度,于是对模块进行了切割,分成2个模块,对于第二个模块进行了preloading,这样在首页加载完毕后,会对该模块进行预加载,加快了路由切换时的速度。关于preloading可以参考Angular官网的自定义预加载策略。

Nginx启用Gzip压缩

HTTP协议上的gzip编码是一种用来改进web应用程序性能的技术,web服务器和客户端(浏览器)必须共同支持gzip。目前主流的浏览器,Chrome,firefox,IE等都支持该协议。常见的服务器如Apache,Nginx,IIS同样支持gzip。

gzip压缩比率在3到10倍左右,可以大大节省服务器的网络带宽。而在实际应用中,并不是对所有文件进行压缩,通常只是压缩静态文件。

在Nginx中,启用gzip:

# 开启gzip
    gzip on;
    # 启用gzip压缩的最小文件,小于设置值的文件将不会压缩
    gzip_min_length 1k;
    # gzip 压缩级别,1-10,数字越大压缩的越好,也越占用CPU时间
    gzip_comp_level 5;
    # 进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。
    gzip_types 
        application/atom+xml
        application/javascript
        application/json
        application/ld+json
        application/manifest+json
        application/rss+xml
        application/vnd.geo+json
        application/vnd.ms-fontobject
        application/x-font-ttf
        application/x-web-app-manifest+json
        application/xhtml+xml
        application/xml
        font/opentype
        image/bmp
        image/svg+xml
        image/x-icon
        text/cache-manifest
        text/css
        text/plain
        text/vcard
        text/vnd.rim.location.xloc
        text/vtt
        text/x-component
        text/x-cross-domain-policy;
    # 是否在http header中添加Vary: Accept-Encoding,建议开启
    gzip_vary on;
    # 禁用IE 6 gzip
    gzip_disable "MSIE [1-6]\.";

不同gzip_comp_level的压缩率可以参考下图:

gzip对svg和x-icon的压缩效果比较明显,一般可以达到50%以上的压缩效果,但是对于压缩过的PNG、GIF格式图片启用Gzip,反而会因为添加标头、压缩字典,增大了图片的大小。

启用压缩后,首页请求的资源大小由原来的10M降低到2.8M,效果还是比较明显的。

启用http缓存

每次访问网页时80%的时间都会花在资源下载上,因此使用缓存可以大大提高网页访问时的响应速度。

参考H5BP配置目录下的expires.conf,作为Nginx服务器配置:

# Expire rules for static content
    # No default expire rule. This config mirrors that of apache as outlined in the
    # html5-boilerplate .htaccess file. However, nginx applies rules by location,
    # the apache rules are defined by type. A consequence of this difference is that
    # if you use no file extension in the url and serve html, with apache you get an
    # expire time of 0s, with nginx you'd get an expire header of one month in the
    # future (if the default expire rule is 1 month). Therefore, do not use a
    # default expire rule with nginx unless your site is completely static
    # cache.appcache, your document html and data
    location ~* \.(?:manifest|appcache|html?|xml|json)$ {
      add_header Cache-Control "max-age=0";
    }
    # Feed
    location ~* \.(?:rss|atom)$ {
      add_header Cache-Control "max-age=3600";
    }
    # Media: images, icons, video, audio, HTC
    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|mp4|ogg|ogv|webm|htc)$ {
      access_log off;
      add_header Cache-Control "max-age=2592000";
    }
    # Media: svgz files are already compressed.
    location ~* \.svgz$ {
      access_log off;
      gzip off;
      add_header Cache-Control "max-age=2592000";
    }
    # CSS and Javascript
    location ~* \.(?:css|js)$ {
      add_header Cache-Control "max-age=31536000";
      access_log off;
    }
    # WebFonts
    # If you are NOT using cross-domain-fonts.conf, uncomment the following directive
    # location ~* \.(?:ttf|ttc|otf|eot|woff|woff2)$ {
    #  add_header Cache-Control "max-age=2592000";
    #  access_log off;
    # }

上述配置禁用manifest,appcache,html,xml和json文件的缓存。 它将RSS和ATOM订阅文件缓存1小时,Javascript和CSS文件1年,以及其他静态文件(图像和媒体)1个月。

缓存全部设置为public,所以任何系统都可以缓存它们。 将它们设置为私有将限制它们被私有缓存(例如我们的浏览器)缓存。

关于缓存中资源的新鲜度控制可以看这篇文章HTTP缓存控制小结。

总结

这次只是很简单地对首屏加载进行了性能优化,减少了10个http请求,总资源大小从10.4MB降到2.8MB,首屏DOMContentLoaded时间从12秒左右降到2秒左右,load时间从22秒左右降到6秒左右,效果还是很明显的。

参考文章

Google Developers中performance系列文章

Front-End Performance Checklist 2018

前端那些事儿」② 极限性能优化

前端性能优化相关

HTTP缓存控制小结

Nginx缓存最佳实践

 

来自:http://www.iteye.com/news/32894

 

相关 [前端 性能优化] 推荐:

前端性能优化

- - JavaScript - Web前端 - ITeye博客
  在浏览器(客户端)和服务器发生通信时,就已经消耗了大量的时间,尤其是在网络情况比较糟糕的时候,这个问题尤其的突出.   一个正常HTTP请求的流程简述:如在浏览器中输入" www.xxxxxx.com"并按下回车,浏览器再与这个URL指向的服务器建立连接,然后浏览器才能向服务器发送请求信息,服务器在接受到请求的信息后再返回相应的信息,浏览器接收到来自服务器的应答信息后,对这些数据解释执行.

前端工程与性能优化

- - FEX 百度 Web 前端研发部
每个参与过开发企业级 web 应用的前端工程师或许都曾思考过前端性能优化方面的问题. 我们有雅虎 14 条性能优化原则,还有两本很经典的性能优化指导书:《高性能网站建设指南》、《高性能网站建设进阶指南》. 经验丰富的工程师对于前端性能优化方法耳濡目染,基本都能一一列举出来. 这些性能优化原则大概是在 7 年前提出的,对于 web 性能优化至今都有非常重要的指导意义.

web前端性能优化进阶路

- - 阿里巴巴(中国站)用户体验设计部博客
Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践. 可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化 黄金法则,以及大名鼎鼎的优化大师 Steve Souders. 本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站 搜索List页面持续两年多的前端性能优化实践的 思路总结.

前端性能优化最佳实践

- - Web前端 - ITeye博客
如今浏览器能够实现的特性越来越多,并且网络逐渐向移动设备转移,使我们的前端代码更加紧凑,如何优化,就变得越来越重要了. 开发人员普遍会将他们的代码习惯优先于用户体验. 但是很多很小的改变可以让用户体验有个飞跃提升,所以任何一点儿小小的优化都会提升你网站的性能. 前端给力的地方是可以有许多种简单的策略和代码习惯让我们可以保证最理想的前端性能.

前端性能优化指南

- - SegmentFault 最新的文章
XMLHttpRequest时,而URL长度不到. GET类型请求只需要发送一个. CSS等静态文件放在静态资源服务器上并配置单独域名,客户端请求静态文件的时候,减少. COOKIE反复传输时对主域名的影响. cloneNode在外部更新节点然后再通过. replace与原始节点互换. >多个节点插入操作,即使在外面设置节点的元素和风格再插入,由于多个节点还是会引发多次reflow.

前端性能优化小纪 -

- - IT瘾-geek
天下武功,无坚不破,唯快不破. 对前端而言,快意味着要求资源体量更小、数量更精简、内容更早呈现、交互更加人性化. 当项目做到一定程度,就应该考虑性能的问题,前端的性能优化有诸多有迹可循的理论和方法,比如 Yahoo. 性能军规、Google PageSpeed Insights Rules. 我们团队一个比较老的项目首屏加载大概需要20多秒,这严重影响了用户体验,于是进行了一次首屏加载的性能优化.

前端重构实践(一) —— 性能优化

- - 搜索研发部官方博客
       最近一直在做性能优化和模块化改造的工作,并完成了一次前端重构. 在这里总结出一些经验和得失来帮助大家思考. 共两篇文章,第一篇讨论性能优化,第二篇讨论模块化框架. 而之所以把这两个话题放到一起,是因为这两项工作都涉及到对前端代码进行不同程度的重构,而且模块化改造其实是我们在对性能优化做到一定程度之后发现必须要做的一件事情.

前端性能优化的14个规则

- - Web前端 - ITeye博客
作为一个半前端工程师,而且只会写点HTML5和CSS3的“假”前端工程师,为了能更好地理解一下前端的花花世界,最近拜读了《高性能网站建设指南》一书,对作者提出的前端性能优化的14个规则获益匪浅,为了让自己印象更深刻点,决定作此文,当做学习笔记也好,知识总结也罢,总归看过的东西要让自己很好地掌握很好地运用起来才是王道.

移动H5前端性能优化指南

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
移动H5前端性能优化指南[托尼托尼研究所]. PC优化手段在Mobile侧同样适用. 在Mobile侧我们提出三秒种渲染完成首屏指标. 基于第二点,首屏加载3秒完成或使用Loading. 基于联通3G网络平均338KB/s(2.71Mb/s),所以首屏资源不应超过1014KB. Mobile侧因手机配置原因,除加载外渲染速度也是优化重点.

前端性能优化不完全手册

- - SegmentFault 最新的文章
性能优化是一门大学问,本文仅对个人一些积累知识的阐述,欢迎下面补充. 抛出一个问题,从输入 url地址栏到所有内容显示到界面上做了哪些事. DNS 服务器请求解析该 URL 中的域名所对应的. 2.建立 TCP连接(三次握手);. 3.浏览器发出读取文件( URL 中域名后面部分对应的文件)的 HTTP 请求,该请求报文作为.