图片 5

快速提升前端性能,大型单页面应用的进阶挑战

快速提升前端性能

2015/09/26 · HTML5,
JavaScript · 1
评论 ·
性能

本文由 伯乐在线 –
cucr
翻译,唐尤华
校稿。未经许可,禁止转载!
英文出处:Jonathan
Suh。欢迎加入翻译组。

去年,我写了一篇文章Need for
Speed,分享了在开发我的网站中使用的工作流程和技术(包含工具)。从那时起,我的网站又经过了一次重构,完成了很多工作流程和服务器端改进,同时我对前端性能也给与了额外关注。以下就是我做的工作,为什么我要这么做,以及我在网站上用来优化前端性能的工具。

canvas api

2016/01/11 · HTML5 ·
Canvas

原文出处: 韩子迟   

大型单页面应用的进阶挑战

2015/09/30 · HTML5,
JavaScript ·
单页应用

原文出处: 林子杰(@Zack__lin)   

阅读须知:这里的大型单页面应用(SPA Web
App)是指页面和功能组件在一个某个量级以上,举个栗子,比如
30+个页面100+个组件,同时伴随着大量的数据交互操作和多个页面的数据同步操作。并且这里提到的页面,均属于
hash 页面,而多页面概念的页面,是一个独立的 html
文档。基于这个前提,我们再来讨论,否则我怕我们 Get 不到同一个 G 点上去。

最小化请求

所有在你的网站加载时用来渲染页面(外部CSS或JS文件、web字体、图片等等)的资源,都是不同的HTTP请求。一般的网站平均有 93个请求!

我的目标是减少HTTP请求。一种方法是分别编译或连接(组合、合并)CSS和javascript到一个文件中。让这个过程自动化(例如使用构建工具 Grunt 或 Gulp)是理想的效果,但至少也应该在生产环境下手动完成。

第三方脚本是增加额外请求最常见的罪魁祸首,很多获取额外的文件如脚本、图像或CSS的请求都不止1个。浏览器内置的开发者工具可以帮助你发现这些元凶。

图片 1
Google Chrome开发者工具的网络选项卡

例如,Facebook的脚本发起3次请求。测试环境中使用一些来自著名社交网站的社交分享脚本,可以看到他们快速增加:

站点 文件 大小
Google+ 1 15.1KB
Facebook 3 73.3KB
LinkedIn 2 47.7KB
Pinterest 3 12.9KB
Tumblr 1 1.5KB
Twitter 4 52.7KB
Total 14 203.2KB

来源:更有效的社会分享链接

这有额外的14个HTTP请求,共203.2KB。相反,我看看 “share-intent” 这个url,它基本上是通过传递和构建数据来生成一个共享,可以只使用HTML来创建社交共享链接。它让我丢掉用于共享的第三方脚本,这些脚本需要7次请求。我在Responsible
Social Share
Links这篇文章有更多的阐述。

评估每一个第三方脚本并确定其重要性。也许存在一种不依赖第三方的方法来完成它。你可能会失去一些功能(例如like、tweet、分享数量),但是请问一下自己:“像数量统计就那么重要吗?”

基本骨骼


 

<canvas id=”canvas” width=1000 height=1000 style=”border: 1px black
dotted”></canvas> <script> var ctx =
document.getElementById(‘canvas’).getContext(‘2d’); </script>

1
2
3
4
5
<canvas id="canvas" width=1000 height=1000 style="border: 1px black dotted"></canvas>
 
<script>
  var ctx = document.getElementById(‘canvas’).getContext(‘2d’);
</script>

挑战一:前端组件化

基于我们所说的前提,第一个面对的挑战是组件化。这里还是要强调的是组件化根本目的不是为了复用,很多人根本没想明白这点,总是觉得造的轮子别的业务可以用,说不定以后也可以用。

其实前端发展迭代这么快,交互变化也快,各种适配更新层出不穷。今天造的轮子,过阵子别人造了个高级轮子,大家都会选更高档的轮子,所以现在前端界有一个现象就是为了让别人用自己的轮子,自己使劲不停地造。

在前端工业化生产趋势下,如果要提高生产效率,就必须让组件规范化标准化,达到怎样的程度呢?一辆车除了底盘和车身框架需要自己设计打造之外,其他标准化零件都可以采购组装(专业学得差,有啥谬误请指正)。也就是说,除了
UI
和前端架构需要自己解决之外,其他的组件都是可以奉行拿来主义的,如果打算让车子跑得更稳更安全,可以对组件进行打磨优化完善。

说了这么说,倒不如看看徐飞的文章《2015前端组件化框架之路》 里面写的内容都是经过一定实践得出的想法,所以大部分内容我是赞成而且深有体会的。

压缩、优化

现在我找到了减少请求的方法,我开始寻找各种方法来减重。文件越小,加载速度越快。通常平均的页面大小为1950KB。按照内容分类:

图片:1249KB HTML:58KB CSS:60KB JS:303KB 字体:87KB Flash:67KB
其它:126KB

我使用这些数据作为参考和比较的起点,同时找到我可以用来为网站减负的方法。 我的网站耗费的流量有多少?是一个由Tim
Kadlec编写的很棒的工具,可以用来帮助你测试和可视化,来自世界各地的访问在你的网站上消耗的流量。

矩形


实心:

// 填充色 (默认为黑色) ctx.fillStyle = ‘darkSlateBlue’; //
规定画布左上角坐标为 (0, 0) // 矩形左上角坐标 (0, 0) // 矩形大小
100*100 ctx.fillRect(0, 0, 100, 100);

1
2
3
4
5
6
7
// 填充色 (默认为黑色)
ctx.fillStyle = ‘darkSlateBlue’;
 
// 规定画布左上角坐标为 (0, 0)
// 矩形左上角坐标 (0, 0)
// 矩形大小 100*100
ctx.fillRect(0, 0, 100, 100);

空心:

// 边框颜色 (默认黑色) ctx.strokeStyle = ‘darkSlateBlue’; //
规定画布左上角坐标为 (0, 0) // 矩形左上角坐标 (0, 0) // 矩形大小
100*100 ctx.strokeRect(0, 0, 100, 100);

1
2
3
4
5
6
7
// 边框颜色 (默认黑色)
ctx.strokeStyle = ‘darkSlateBlue’;
 
// 规定画布左上角坐标为 (0, 0)
// 矩形左上角坐标 (0, 0)
// 矩形大小 100*100
ctx.strokeRect(0, 0, 100, 100);

挑战二:路由去中心化

基于我们所说的前提,中心化的路由维护起来很坑爹(如果做一两个页面 DEMO
的就没必要出来现眼了)。MV*
架构就是存在这么个坑爹的问题,需要声明中心化 route(angular 和 react
等都需要先声明页面路由结构),针对不同的路由加载哪些组件模块。一旦页面多起来,甚至假如有人偷懒直接在某个路由写了一些业务耦合的逻辑,这个
route 的可维护性就变得有些糟糕了。而且用户访问的第一个页面,都需要加载
route,即使其他路由的代码跟当前页面无关。

我们再回过头来思考静态页面简单的加载方式。我们只要把 nginx 搭起来,把
html 页面放在对应的静态资源目录下,启动 nginx 服务后,在浏览器地址栏输入
127.0.0.1:8888/index.html
就可以访问到这个页面。再复杂一点,我们把目录整成下面的形式:

/post/201509151800.html /post/201509151905.html /post/201509152001.html
/category/js_base_knowledge.html /category/css_junior_use.html
/category/life_is_beautiful.html

1
2
3
4
5
6
/post/201509151800.html
/post/201509151905.html
/post/201509152001.html
/category/js_base_knowledge.html
/category/css_junior_use.html
/category/life_is_beautiful.html

这种目录结构很熟吧,对 SEO
很友好吧,当然这是后话了,跟我们今天说的不是一回事。这种目录结果,不用我们去给
Web Server 定义一堆路由规则,页面存在即返回,否则返回
404,完全不需要多余的声明逻辑。

基于这种目录结构,我们可以抽象成这样子:

/{page_type}/{page_name}.html

1
/{page_type}/{page_name}.html

其实还可以更简单:

/p/{name}.html

1
/p/{name}.html

从组件化的角度出发,还可以这样子:

/p/{name}/name.js /p/{name}/name.tpl /p/{name}/name.css

1
2
3
/p/{name}/name.js
/p/{name}/name.tpl
/p/{name}/name.css

所以,按照我们简化后的逻辑,我们只需要一个 page.js
这样一个路由加载器,按照我们约定的资源目录结构去加载相应的页面,我们就不需要去干声明路由并且中心化路由这种蠢事了。具体来看代码。咱也懒得去解析了,里面有注释。

CSS和JavaScript

压缩样式表和JavaScript文件可以明显减少文件大小,我仅在压缩上就从一个文件上节省了56%的空间。

压缩前 压缩后 节省比例
CSS 135KB 104KB 23.0%
JS 16KB 7KB 56.3%

我使用 BEM (代码、元素、修饰符)
方法论编写CSS,这将导致冗长的类名。重构我的一些代码变得更简短(“navigation”为
“nav”, “introduction” 为
“intro”),这让我节省了一些空间,但和我期望的后期压缩相比并不是那么明显。

冗长的类 精简后 节省比例
104KB 97KB 6.7%

我也重新评估了使用jQuery的必要性。对于压缩的135KB的JavaScript,大约96KB是jQuery库——71%之多!这里并没有很多需要依赖于jQuery,所以我花时间重构了代码。我通过剥离jQuery和在Vanilla重写它,去除了122KB,最终压缩后的文件大小减少到13KB。

jQuery Vanilla JS 节省比例
135KB 13KB 122KB (90%)

从那时起,我设法去掉更多空间(压缩后7KB),最后脚本在压缩和gzipped后只有0.365KB。

圆形


实心:

ctx.fillStyle = ‘darkSlateBlue’; ctx.beginPath(); ctx.arc(100, 100, 50,
0, Math.PI * 2, true); ctx.closePath(); ctx.fill();

1
2
3
4
5
6
ctx.fillStyle = ‘darkSlateBlue’;
 
ctx.beginPath();
ctx.arc(100, 100, 50, 0, Math.PI * 2, true);
ctx.closePath();
ctx.fill();

空心:

ctx.strokeStyle = ‘darkSlateBlue’; ctx.beginPath(); ctx.arc(100, 100,
50, 0, Math.PI * 2, true); ctx.closePath(); ctx.stroke();

1
2
3
4
5
6
ctx.strokeStyle = ‘darkSlateBlue’;
 
ctx.beginPath();
ctx.arc(100, 100, 50, 0, Math.PI * 2, true);
ctx.closePath();
ctx.stroke();

挑战三:领域数据中心化

对于单向数据流循环和数据双向绑定谁优谁劣是永远也讨论没结果的问题,要看是什么业务场景什么业务逻辑,如果这个前提没统一好说啥都是白搭。当然,这个挑战的前提是非后台的单页面应用,后台的前端根本就不需要考虑前端内存缓存数据的处理,直接跟接口数据库交互就行了。明确了这个前提,我们接着讨论什么叫领域数据中心化。

前面讨论到两种数据绑定的方式,但是如果频繁跟接口交互:

  • 内存数据销毁了,重新请求数据耗时浪费流量
  • 如果两个接口字段部分不一样但是使用场景一样
  • 多个页面直接有部分的数据相同,但是先来后到导致某些计数字段不一致
  • 多个页面的数据相同,其中某些数据发生用户操作行为导致数据发生变动

因此,我们需要在业务视图逻辑层和数据接口层中间增加一个
store(领域模型),而这个 store 需要有一个统一的 内存缓存 cache,这个
cache 就是中心化的数据缓存。那这个 store 究竟是用来弄啥勒?

图片 2

Store 具有多形态,每个 store
好比某一类物品的仓储(领域,换个词容易理解),如蔬果店 fruit-store,
服装店
clothes-store,蔬果店可以放苹果香蕉黑木耳,服装店可以放背心底裤人字拖。如果品种过于繁多,我们可以把蔬果店精细化运营变成香蕉专卖店,苹果专卖店(!==
appstore),甚至是黑木耳专卖店…( _
_)ノ|,蔬果种类不一样,但是也都是称重按斤卖嘛。

var bannerStore = new fruitStore();

var appleStore = new fruitStore();

有了这些仓储之后,我们可以放心的把数据丢给视图逻辑层大胆去用。想修改数据?直接让
store 去改就行了,其他页面的 DOM
文本内容也得修改吧?那是其他页面的业务逻辑做的事,我们把事件抛出去就好了,他们处不处理那是他们的事,咱别瞎操心(业务隔离)。

那么 store 具体弄啥勒?

图片 3

  • 32
    个赞位置可点赞或者取消,三个页面的赞数需要同步,按钮点赞与取消的状态也要同步。
  • 条目是否已收藏,取消收藏后 Page B 需要删除数据,Page A+C
    需要同步状态,如果在 Page C 又有收藏操作,Page B
    需要相应增减数据,Page A 状态需要同步。
  • 发评论,Page C 需要更新评论列表和评论数,Page A+B
    需要更新评论数。如果 Page B 没有被加载过,这时候 Page B
    拿到的数据应该是最新的,需要同步给 A+C 页面对应的数据进行更新。

所以,store
干的活就是数据状态读写和同步,如果把数据状态的操作放到各个页面自己去处理,页面一旦多了或者复杂起来,就会产生各个页面数据和状态可能不一致,页面之前双向引用(业务耦合严重)。store
还有另一个作用就是数据的输入输出格式化,简单举个栗子:图片 4

  • 任何接口 API 返回的数据,都需要经过 input format
    进行统一格式化,然后再写入
    cache,因为读取的数据已按照我们约定的规范进行的处理,所以我们使用的时候也不需要理会接口是返回怎样的数据类型。
  • 某些组件需要的数据字段格式可能不同,如果把数据处理放在模板进行处理,会导致模板无法更加简洁通用(业务耦合),所以需要
    output format 进行处理。

所以,store
就是扮演着这样的角色——是数据状态读写和同步,以及数据输入输出的格式化处理。

图片

图片通常占到一个网站的大头。通常网站平均有1249
KB的图片。

我抛弃了图标字体,取而代之的是内联SVG。此外,任何可以矢量化的图片都使用内联SVG替换。我的网站先前版本的一个页面仅仅图标web字体就加载了145KB,同时对于几百个web字体,我只使用了一小部分。相比之下,当前网站的一个页面只加载10KB内联SVG,这可是93%的差异。

SVG
sprites看起来很有趣,它可能是我在整个网站使用普通内联SVG图标的一个可行的替代解决方案。

在可能的情况下使用CSS代替图片,现在的CSS能做的已经很多了。然而,浏览器兼容性可能是现代CSS使用的一个问题;因此,充分利用 caniuse.com 和逐步改进。

你也可以通过优化图片来压缩字节。有两种方法来优化图片:

  1. 有损压缩:降低图像的质量
  2. 无损压缩:不影响质量

要同时使用两种方法取得最好的效果,顺序是很重要的。首先使用有损图像压缩方法,比如在不超过必要大小的情况下调整图像大小然后在略低质量且不压缩太多的情况下导出如我通常在82
– 92%下导出JPG图片

图片 5

ImageOptim是OS X下的一个图像优化工具

接下来,使用无损图像优化工具比如 ImageOptim进行处理,从而通过删除不必要的信息,如元数据或颜色配置文件来进一步减少图像文件大小。

线段


ctx.strokeStyle = ‘darkSlateBlue’; ctx.beginPath(); ctx.moveTo(100,
100); // 起点 ctx.lineTo(200, 200); ctx.lineTo(300, 100); //
ctx.closePath(); ctx.stroke();

1
2
3
4
5
6
7
8
ctx.strokeStyle = ‘darkSlateBlue’;
 
ctx.beginPath();
ctx.moveTo(100, 100); // 起点
ctx.lineTo(200, 200);
ctx.lineTo(300, 100);
// ctx.closePath();
ctx.stroke();

挑战四:Hybrid App 化

现在 Hybrid App 架构应用很火啊 _
(:3」∠)_,不搞一下都不好意思说自己是做 H5的。这里所说的 Hybrid App
可不是那种内置打包的 html 源码那种,而是直接去服务端请求 html
文档那种,可能会使用离线缓存。有的人以为如果要使用 Hybrid
架构,就不能使用 SPA 的方式,其实 Hybrid 架构更应该使用 SPA。

遇到的几个问题,我简单列举一下:

  • 客户端通过 url 传参

    如果通过 http get 请求的 query 参数进行传参,会导致命中不到 html
    文档缓存,所以通过 SPA 的 hash query 传参,可以规避这个问题。

  • 与其他 html 页面进行跳转

    这种场景下,进入新页面和返回旧页面导致 webview 会重新加载本地的
    html 文档缓存,视觉体验很不爽,即使页面使用了离线缓存,而 SPA
    可以规避这个问题。

  • 使用了离线缓存的页面需要支持代码多版本化

    由于采用了非覆盖性资源发布方式,所以需要仍然保留旧的代码一段时间,以防止用户使用旧的
    html
    文档访问某些按需加载功能或清除了本地缓存数据而拿不到旧版本代码。

  • js 和 css 资源 离线化

    由于离线缓存的资源需要先在 manifest
    文件声明,你也不可能总是手动去维护需要引用的 js 和 css
    资源,并且那些按需加载的功能也会因此失去按需加载的意义。所以需要将
    js 和 css 缓存到
    localstorage,直接省去这一步维护操作。至于用户清除
    localstorage,参考第三点解决方案。

  • 图标资源离线化

    将图标文件进行 base64 编码后存入 css 文件,方便离线使用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

标签:,
网站地图xml地图