未加星标

JavaScript 的代价(2018 版)

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

关于作者: Addy Osmani , 英国。谷歌的经理,在 Chrome Passionate 负责改善网页速度。

建立 交互式 网站 包括向用户发送 javascript 。通常,太多了。你是否经历过在一个手机页面上,它看起来已经加载好了,但是点击一个链接或者试图滚动页面的时候,什么也没发生?

一字节又一字节,JavaScript 仍然是我们发送给手机的代价最大的资源,因为它会很大程度上延迟交互。


JavaScript 的代价(2018 版)

由 WebPageTest(src) 评测的 CNN.com 的 JavaScript 处理时间。高端手机(iPhone8)在约4s的时间处理脚本。相比较而言,普通手机(Moto G4)是约13s的时间,以及2018年低端手机(Alcatel 1X)是约36s。

现在我们讨论一些策略,可以让你高效地传送 JavaScript ,同时给用户提供一个有价值的体验。

概括:

要保持快速,则只加载当前页面必要的 JavaScript 。优先考虑用户需要的内容,然后使用 代码拆分 延迟加载剩下来的内容。这是快速加载和交互的最好的机会。默认情况下,基于路由的代码拆分堆栈是一个转折。

接受性能预算,学会在预算中生活。对于手机来说, JS的预算目标为简化/压缩后小于170KB 。未压缩时代码约为0.7MB。预算对成功至关重要,然而,他们单独不能神奇地修正 perf 数值。 团队文化,结构和强制措施 。没有预算的项目建立会导致性能退化并导致失败。

学习如何 审计 并裁剪 JavaScript 捆绑库。 当你 只需要一小部分却搭载了整个库 ,浏览器不需要的填充字符,或者重复代码,这些很容易发生。

每个交互都是一个新的“交互时间”的开始;考虑在这种情况下进行优化。传送数据的大小对低端手机网络至关重要,而且 JavaScript 解析时间受设备 CPU 限制。

如果客户端 JavaScript 对用户体验没有好处,问问自己是否真的有必要。也许服务端渲染 HTML 会更快一些。考虑将客户端框架限制到绝对需要它们页面上的使用。如果做的不好,服务器渲染和客户端渲染都会是灾难。

(本文基于我最近的“JavaScript 的代价”的演讲: https://youtu.be/63I-mEuSvGA )

网站因用户“体验”而膨胀

当用户访问网站,你可能正在下载大量文件,其中很多都是脚本。从给一个web浏览器的角度来看有点像这个:


JavaScript 的代价(2018 版)
扔给你一大堆文件

虽然我很喜欢JavaScript,但它总是网站中消耗最大的东西。我想解释一下为什么这是一个主要问题。


JavaScript 的代价(2018 版)

现在中等的web页面搭载了大概 350KB的简化或压缩后的JavaScript脚本 。浏览器需要处理的未压缩的脚本膨胀到了超过1MB。

注:不确定你的JavaScript包是否延迟了用户与网站交互速度?查看 Lighthouse 。


JavaScript 的代价(2018 版)

2018年7月的 HTTP压缩状态的JavaScript报告 中的统计突出显示了中等web页面搭载了约350KB的简化或压缩后的脚本。这些页面要花15s才能交互。

在移动设备上,搭载这么多的JavaScript脚本从经验来看要花费超过 14+秒才能加载并交互 。

其中的一个很大的因素是在移动网络中下载代码,然后再移动设备CPU上处理它,这个过程所花费的时间。

我们来看移动网络。


JavaScript 的代价(2018 版)

在某一指标上表现较好的国家,颜色较深。不包括在内的国家是灰色的。 还有 值得注意的是,即使在美国,农村的宽带速度要比城市慢20%。

这个 来自OpenSignal的图表 展示了全球4G网络的稳定性,以及每个国家的用户体验到的平均连接速度。正如我们看到的,很多国家的连接速度仍比我们想象中要慢。

不仅中型网站的350KB的脚本要花上一段时间才能下载,事实上,如果我们浏览热门网站,实际上会加载比这更多的脚本:


JavaScript 的代价(2018 版)
“ Facebook.com和其他网址相关数据 ”中的未压缩的JS包大小数据。像谷歌表格这样的网站被突出显示为最多加载5.8MB的脚本(在解压缩后)。

我们在桌面和移动web上都遇到了这个瓶颈,这些网站有时会加载几兆字节的代码,然后浏览器需要处理这些代码。问题是, 你能负担得起这么多JavaScript脚本吗 ?

JavaScript有代价
JavaScript 的代价(2018 版)

“含有这么多脚本的网站根本不能送达全球的诸多用户;统计表示,用户不会(以后也不会)等待它们加载” ― AlexRussell

注:如果你使用了大量的脚本,应该考虑使用 code-splitting 对其进行分解,或者 使用 tree-shaking技术减少JavaScript 的加载量 。

现代网站通常会通过 JS包发送下面这些东西:

客户端框架或UI库

状态管理(比如Redux)

Polyfills(一般现代浏览器不需要他们)

完整的库或仅用到的部分(比如 lodash完整库、Moment +其本地库)

一套UI组件(按钮、顶部、侧边栏等)

累积起来的代码越来越多,页面加载的时候也就越来越长。

加载网页就像电影胶片一样,有三个关键时刻。 即:是否发生?是否有用?是否可用?
JavaScript 的代价(2018 版)

加载是一个过程。我们正逐渐开始关心用户的良好体验。我们不再盯着 onload和 domContentLoaded,而是会问“用户什么时候才能正常使用页面?”如果用户点击用户界面中L的o某个地方,是否有所反馈?

是否正在发生 是指屏幕上开始显示某些内容。(导航开始了吗?服务器在响应吗?)

是否有用 指文本或内容显现之后,用户是否通过体验或参与感受到价值。

还有 是否可用 是指用户可以根据经验开始交互并发生一些事情。

我之前也提到过这个术语:“交互”,它到底是什么 意思 呢?


JavaScript 的代价(2018 版)

交互时间的可视化强调,不好的体验会让用户认为他们能达到某个目标,但实际上页面还没有加载完要达到这个目标所需要的代码。感谢 Kevin Schaaf 的关于交互的动画

对于要交互的页面,它必须能够快速响应用户输入。较小的JavaScript可以保证快速响应。

无论用户点击链接还是滚动页面,他们都需要看到有反馈他们动画的事情发生。如果做不到这样的体验,用户就会感沮丧。


JavaScript 的代价(2018 版)

灯塔有一系列以用户为中心的性能指标,比如在实验设置中的交互时间。

通常发生的地方是当服务端在渲染的过程中,下载一堆“溶入”界面的JavaScript(添加事件处理函数和其它行为)。

浏览器可能会在处理用户输入的线程上运行许多可能需要处理的事件。这个线程称为主线程。

在主线程上加载太多JavaScript(通过 <script>等)会是个问题。把脚本加载到 Web Worker 或者由 Service Worker 处理脚本会减轻这些与交互时间相关的负责影响。

(这里有一个用户点击 UI 的例子。通常,用户勾选复选框,或者点击链接,一切都很美好。但如果我,们模拟阻塞主线程,就什么事都不会发生了。用户无法勾选复选框,也不能点击连接,因为主H线程被阻塞了: https://youtu.be/N5vFvJUBS28 )

应该尽可能地避免阻塞主线程。 了解更多内容,请看 “ 为什么Web开发者需要关心交互性 ”

我们看到我们合作的团队遭受JavaScript影响了许多类型网站的交互性。
JavaScript 的代价(2018 版)

JavaScript可以延迟可见元素的交互性。可视化是Google搜索中的一些UI元素

太多(主线程)JavaScript可以延迟可见元素的交互性。这对许多公司来说都是一个挑战。 以上是Google搜索中的一些示例,您可以在这些示例中开始使用UI,但如果某个网站运行过多的JavaScript,则可能会在实际发生某些事情之前出现延迟。这会让

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

tags: JavaScript,用户,加载,交互,页面,脚本,网站,UI,浏览器,代码,压缩,体验,web,点击
分页:12
转载请注明
本文标题:JavaScript 的代价(2018 版)
本站链接:https://www.codesec.net/view/588621.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(17)