聊聊关于性能优化和其余(一)

聊聊关于性能优化(一)

隔了许久都没有更新博客,前一阵子是由于忙其余事去了,如今想写点什么,可是思前想后不知道该写些什么,这是这个系列的第一篇,这篇文章没有干货,只是聊聊关于前端优化,关于5G的到来,关于前端的将来。javascript

关于为何要优化

前端的大咖们在推进前端届蓬勃发展的同时,愈来愈多的人能抄起手上的工具( ReactVueAngular )加上各类 CLI 一键生成, 再加上自然的 UI 库( AntdElement-UIiViewBootstrap )就能快速构建写出一个用户界面,加上在这个性能过剩的年代,非大厂可以投入人力优化前端性能,大部分网页能加载出来功能没问题就告之大吉,只要不是太 过度 的代码编写,通常来讲,电脑端的网页加载也就差个 1~3 秒,更多的则是网络问题。html

这么一看,性能优化仿佛不是那么重要,可是因为前端圈的蓬勃发展,愈来愈多的功能实现放置在前端页面上,现代的网站拥有比以往多不少的功能,页面数量都是几倍的增加,甚至该网站是这个企业的核心业务,尤为是这几年移动设备的爆发式发展,若是这么多的功能放置在移动端时,轻微的性能问题可能只会致使轻微的延迟、等待,仅仅会给用户带来短暂的不便,可是严重的性能问题就会致使用户没法访问或者没法响应用户的动做之类,不少人意识到这个问题,惋惜的是,大部分网站都将这个缘由归结于网络条件很差或者用户设备太差,从而忽略真正的前端性能的优化。前端

对于通常网站来讲,用户进入浏览,关心的是本身的用户体验、网页浏览温馨度,他们很大一部分并不关心网络和设备问题,有不少数据代表,一个网站的温馨度决定了用户的去留。java

对不起,我真的不想等(优化和用户去留的关系)

咱们但愿咱们所构建的页面能和用户进行互动,而不是呆板的纯静态页面,一个可交互的页面能够留存不少的用户。node

若是咱们构建的是博客,咱们但愿用户能顺畅的读完博文,并给予点评。react

若是咱们构建的是商城系统,咱们但愿用户能快速精准的定位到须要购买的商品。git

若是咱们构建的是社交系统,咱们但愿用户能快速找到对应的人并进行彼此的互动。github

而这一切,差别化是一条出路,可是差别化很容易就被抄袭、模仿,企业更多的这是面对同质化的红海竞争,与此同时,性能扮演着相当重要的角色。web

有几组数据来代表性能优化与用户留存的关系:npm

根据 DoubleClick by Google 更多研究,若是一个网站加载时间越短,优点越大。

根据大量测试发现,同一个页面,加载时间 19 秒和加载时间 5 秒是两种大相径庭的结果,加载在 5 秒以内的网站,用户浏览率增加 70%,流失率降低 35%,广告可见率提高 25%。

你们可使用 Speed Scorecard 工具进行移动网站的加载速度测试,因为没有中国大陆节点,你们移步至香港节点进行测试。

如下是我对一些经常使用网站4G加载的测试:

高优化和收入的关系

从上一小节能够看出来,一个好的优化能够提高用户的转化率,反之流失率会大大增长。

下面一些小栗子显示了一些优化对收入的影响:

用户体验的哲学

关于加载速度

当用户在用移动设备访问某一个网站时,因为各类外在条件的因素(网速、设备硬件条件),打开同一网站的效果可能大相径庭(某锤官网):

  • Fast 3G 状况下大概使用了 34 秒所有加载完毕:

  • 模拟 4G(5MB/s) 的速度下大概使用了 11 秒所有加载完毕:

然而,实际状况下,因为地理位置、人流量等环境因素,不多有移动设备能满速 5MB 的下载。

而用户体验的基础是在于已经看到显示的内容,在此以前就谈不上用户体验,若是网络较快可能还好点,若是网速很差,用户就不得不等待,还可能会遇到各类各样的问题,例如,JS 加载不完整致使点击事件无效等。
所有加载完毕以后的某锤网站使用感受还能够,咱们来看一下这次加载了多少 JS 资源:

竟然有一个 JS 文件达到了 2.3MB,这显然是不合理的,纵使网站优化再好,加载很慢就会致使用户的不耐烦。

关于代码优化

得益于如今移动端 CPU 的高速发展,甚至有些媲美桌面端处理器,可是用户不可能一直手持最新设备,全部如今不要高估了移动端的处理器,其计算能力和内存大小依旧有限。

一些未经优化的代码,咱们在 Chrome 下调试可能没以为有差,可是到移动设备上时,就会出现各类各样的问题,当问题多到必定程度时,用户必然忍受不了,将其抛弃。

利用 Google 提供的 Lighthouse 插件,咱们能够直观的分析一个网站的优劣,以及优化点,让咱们有方向的去改进:

嗯,再看看咱们的掘金(仍是挺不错滴):

优化关乎用户成本

这是一个最好的时代,全部的一切都在迅速发展;这是一个最坏的时代,渐渐地愈来愈多的人们跟不上时代的步伐(好比咱们的父母,哎)。

将来必定是移动的世界。

根据 statcounter 统计,全球范围内,移动端设备占据了较大比例,这一比例在中国更大,甚至占到了 70%-80%,咱们要记住,绝大多数用户都是经过 LTE、4G、3G 访问网络,在 2017 年,Ben Schwarz作出真实网络与优化的调查:Beyond the Bubble: Real world performance 显示,越发成熟的网络建设背后,用户数据流量的成本正在逐渐下滑,到了 5G 时代又是另外一番景象,这个咱们下面再讨论。这一现象代表,几乎任何用户均可以廉价的访问网络,在这个互通互联的时代,网络几乎成为咱们生活的必需品。

另外一研究代表,从 2011 年起,网站页面数量就开始稳步增加,其中移动端的 URL 总数甚至超过了桌面端,更多统计数据点击 这里 查看:

上图统计发现,2011 年起,网站页面数量就开始稳步增加,尤为是近几年,得益于移动端的爆发式增加,桌面端也配套了对应的页面,可是增速仍然低于移动端。

这一趋势发展下去,意味着咱们须要花费更多的流量(貌似如今已是这样了)。

关于如何优化

性能优化并非一件很可贵事,但也绝对不轻松,作到如下几点便提高性能,此次没有具体的实施细节,只有一些建议。

关于资源的加载

构建一个高性能高效的 WEBAPP 最为有效的一个注意点就是,检查用户在进入页面时,到底加载了多少有效的资源,又加载了多少无效的资源。尽管咱们能够从 Chrome DevToolsNetwork 面板查看全部已加载的资源,可是若是开发者从未关注过,不知该如何下手,能够看看如下几个意见:

  • 若是使用网上开源的 UI 库,例如:BootstrapAntd 来构建本身的界面,在作以前询问本身是否是必定要用,结合自身的项目需求,但至少应作到按需引入而不是在 app.js 里所有引入这些样式和组件。另外,若使用 link 标签来引入资源,这些资源在网站资源加载以前加载,可能会有些阻碍。
  • 多使用 FlexGrid 来进行布局,这两种布局方式可使用较少的代码来实现简单或复杂的布局。
  • CSS 加载是一种阻塞浏览器渲染的资源(之后会聊到),使用 CSS 框架的消耗某些状况下会致使渲染延迟严重,最好视状况引用资源,加速渲染。
  • JavaScript 库十分方便,可是不必定是必须的。例如 JQuery,现代浏览器都支持了 querySelectorquerySelectorAll 等,可以快捷的选择元素。addEventListener 能够轻松的绑定事件。classListsetAttributegetAttribute 提供了类和元素属性的简便方法。若是不得已必定要使用库,请选择合适而且占用空间较小的替代产品,例如使用 dayjs 来代替 moment.jsZepto 代替 JQueryPreact 代替 React 等。
  • 得益于网络条件日益变好和 WEBAPP 的迅猛发展,如今不少一部分企业选择 SPA 做为首选,此类应用一般须要加载大量的JavaScript,例如上面的某锤科技。根据 Addy Osmani 发布的文章 The Cost Of JavaScript 分析发现,此类资源必须通过下载、解析、编译和执行这一过程,浏览器会花费很长时间解析/编译代码,严重时会严重延迟用户与网站交互的时间。所以网站发送的 JavaScript 越多,网站进行交互以前解析和编译它所需的时间就越长。可是这并非说 SPA 不可取,合理使用 HTTP 缓存或者 Service Worker,相比传统的多页面网站,通过优化的 SPA 网站每每能提供更好的用户体验。

关于资源的传输

  • 迁移至 HTTP2,相比HTTP1.1HTTP2 可以提高至少 50% 资源的获取速度,并解决 HTTP1.1 固有的性能问题,例如并发请求数的限制、缺少标头压缩。
  • 在上面用户成本那里统计图能够看出来,现代网站的大小也在逐渐增长,在 HTTP1 中, 因为并发请求数量的限制(浏览器一般是 6 个),常见的作法是将 CSSJavaScript 捆绑打包成较大的 bundle,可是这么作及其影响资源的加载,对性能形成不利的影响。而在 HTTP2 以后不须要考虑此问题,由于 HTTP2 采用流传输,能够一次请求多个文件,极大的提高了性能,赶忙让后端小伙伴支持 HTTP2 吧!
  • 采用 Webpack 代码拆分技术,仅下载目前须要用到的脚本,合理的拆分模块而且合理利用 HTTP1.1 协议传输,一样可以大幅提高加载速度。

关于资源的大小

  • 压缩 HTMLCSSJS,充分利用 Webpack 的能力,将各类资源打包压缩,这会大大减小资源的大小,并且不会影响功能。
  • 利用 UglifyJSJS 的内容丑化(变量名压缩),它会经过缩短变量名和函数名来节省空间。
  • 利用 SVGO 优化 SVG 文件。
  • 利用 GZIP 方式进行资源再次压缩。可是请记住,压缩能只能加快资源加载速度,并非解决性能问题的万能方法。
  • 若是有充足的时间,能够利用 WebP 格式代替 JPEG 或者 PNG,它能使用及其少许的数据保持和传统图片格式同样的高质量水平。
  • 使用 自适应图片。最简单的,使用 <img> 标签中的 srcset 属性,以指定浏览器能够选择的一组图像。
  • 使用视频而不是 GIF。同等画质下,视频大小会比 GIF 小 80% 左右。

关于 5G 的到来

什么是 5G ?

写下这篇文章的时候,第一批支持 5G 的手机已经发布了。

在实验室测试结果上看,5G 的速度是 4G 的 65000 倍,可以直接实时传输 4K 流媒体,同时,5G 网络将具备接近零延迟。4G 的平均延迟 50 毫秒,当切割到 5G 后,只有 1 毫秒,这是 GSMA 设定的基准。

5G 的来临能改变不少行业,例如,视频直播互动,云,虚拟现实、加强现实,前端等行业,同时同等流量下的资费确定愈发变低,带宽问题也可能再也不是问题了。

随着技术的升级,HTTP2 也必定会愈来愈广泛,文件大小和数量可能再也不是问题,之后优化的重点可能就是对应于浏览器(客户端)的优化,如何提高用户的使用体验多是那个时候最重要的吧。

因为传输技术的巨大升级,一些很酷的客户端技术将来将可能在前端实现,随用随访问,好比 CAD 制图,power bi 等。

浏览器的地位将愈来愈重要。

目前来讲,4G 的带宽已经足够,5G 的到来也只是加快了资源加载速度,最终阻碍 WebApp 的仍是用户体验的问题,是有限的显示效果,不流畅的滑动,Native 硬件支持不完善,底下的性能等等,才是最重要的缘由。

关于前端的将来

这几年前端层出不穷的框架技术让人有一种学不动的感受,可是这大可能是都是围绕着浏览器而进行的。

在我看来,其实就分两个端,客户端和服务端。一个和用户打交道,一个和服务器打交道而已。

真正让人兴奋不已的技术革新,FlutterRNWebAssemblyPWA 等技术让人眼前一亮; nodeJS 包揽后端一部分功能,让人心花盛开; 小程序 这种于 APP 以内的微小应用即用即开的能力。

将来

  • Rxjs 能够应对低延迟和万物互联的复杂异步
  • Web Worker 不阻塞主线程,高刷新率的渲染页面
  • 5G 的低延迟意味着渲染交给服务器没有问题,打开网页玩大型主机游戏也不是梦想
  • 随着浏览器的更新,WebGL/OpenGL/Canvas 的能力被彻底挖掘出来,Web 3DWeb VR可视化将变成主流,图像和动画交互将是个长期热点

总之,前端的路是光明的。

相关文章
相关标签/搜索