像工具 Webpack Bundle Analyzer, Source Map Explorer 和 Bundle Buddy 允许你审核你的包用以减少包的数量。
这些工具可视化了JavaScript包的内容:它们突出显示您可能不需要的大型库,重复代码和依赖项等。
来自Benedikt Rötsch的 “放下你的Webpack包,节制使用”
打包审计通常会突出显示重要的依赖项(如Moment.js及其语言环境)的机会,以获得更轻的替代方案(例如 date-fns)。
如果你使用 webpack, 您可能会发现我们打的包中通用库问题在打包中很有用。
如果你不确定你对JavaScript性能方面是否有什么问题,请查看Lighthouse:
你可能没有注意到,Lighthouse最近添加了大量有用的新的性能审计功能。
Lighthouse是一个嵌入到Chrome开发工具的工具。它也可以作为Chrome扩展使用。它给你一个深入的性能分析来凸显提高性能的机会。
我们最近已经在Lighthouse添加了对高“JavaScript启动时间”标记的支持。这个审计工具突出显示那些可能花大量时间来解析/编译的脚本,这些脚本延迟了交互。你可以将这个审计工具看做一个机会,不是拆分脚本,就是在这里做更少的工作。
你还可以做的另外一件事就是确定你不会为你的用户加载无用代码:
使用Chrome开发工具中的覆盖率标记来找到无用的CSS和JS代码。
代码覆盖率是开发工具中的一个特性,它可以让你发现页面中的无用JavaScript(以及CSS)。在开发工具中加载页面后,覆盖标记会显示执行了多少代码vs.加载了多少代码。你可以通过只加载一个用户需要的代码来提高页面性能。
注:通过覆盖率记录,你可以与应用交互,然后开发工具会刷新用到了哪些包。
对于找机会来拆分脚本以及在需要的时候延迟加载非必要代码,这是有价值的。
如果你正在寻找有效地为用户提供JavaScript的模式,请查看PRPL模式。
PRPL是高效加载的性能模式。它代表着:将关键资源推送(Push)到初始路由上,渲染(Render)初始路由,预缓存(Pre-cache)其他路由,延迟加载(Lazy-load)并按需创建剩余路由
PRPL (Push, Render, Precache and Lazy-Load) 是一种模式,用于为每条路径快速划分代码,然后利用服务工作者预先缓存未来要访问的路由所需的JavaScript和逻辑,并根据需要延迟加载它。
这意味着当用户导航到体验中的其他视图时,它很可能已经存在于浏览器缓存中,因此他们在启动脚本和获取交互方面的开销降低了很多。
如果你关心性能,或者你曾经为你的网站做过性能补丁,那么你知道有时你可能最终会遇到这样一类问题修正,几周之后回来才发现团队中的某个人正在处理的功能和无意中破坏了这类体验。它有点像这样:
值得庆幸的是,我们可以尝试解决这个问题,一种方法是制定性能预算。
性能预算至关重要,因为他让每个人都在页面上。他们创造了分享热情的文化,不断改善用户体验和团队责任感。
预算通过定义可计算的约束来允许团队达到他们的性能目标。正因为你不得不生活在预算的约束之中,所以每一个步骤都需要考虑到性能,而不能事后再考虑。
基于Tim Kadlec的工作,性能预算的指标可包括:
里程碑时间 — 基于加载页面的用户体验的计时(例如 Time-to-Interactive)。在页面加载时,您通常需要匹配多个里程碑时间来准确的呈现完整的故事。
基于质量的测量— 基于初始值(例如 JavaScript的weight,HTTP请求的number)。这些都专注于浏览器体验。
基于规则的测量— 由例如Lighthouse或者WebPageRest这样的工具生成分数。通常情况下,单个数字或者一些列的数据来评价您的网站。
Alex Russell发表了一片关于预算性能的tweet-storm文章,其中有几点值得关注:
“领导的支持很重要. 为了保持整体用户体验的良好性,领导愿意将特征工作保持在对技术产品的深思熟虑的管理中。”
“性能是有关工具支持的文化。浏览器尽可能的优化了HTML+CSS。将您的工作更多的投入到JS中会为您的团队和所用的工具带来负担。”
“预算不会让你伤心。他们的存在使得组织能够自我纠正。团队需要预算来约束决策空间并帮助打击他们。”
影响网站用户体验每个人都与网站的性能有关。
将性能作为讨论的一部分。
在规划会议和其它集会时讨论性能。询问商业项目关系人他们期望的性能是什么。他们是否明白性能是如何影响他们所关心的业务指标的?问开发团队他们如何规划定位性能瓶颈。当得不到满意答复的时候,他们开始讨论。
“通过展示性能是如何影响项目关系人所关心的性能指标,来使性能与他们的目标相关联。若没有性能文化,性能将无法保证。”——Allison McKnight
性能行动规划如下:
-创建性能视图。这是商业项目关系人和开发者达成共识的“良好性能”的协议。
-设置性能预算。从视图中挑出关键性能指标(KPIs),并从中设置合理的,可计量的目标。例如:“5秒内加载并获取交互”。大小预算可能会从而消失。例如“将JS限制在简化/压缩后170KB的大小”。
-建立关于KPIs的定期报告。这可以是一份定期发送给业务部门的报告,强调进展和成就。
Andy Still的《网络性能勇士》(Web Performance Warrior)和Lara Hogan的《为性能而设计》(design for Performance)都是很好的书,讨论了如何思考建立性能文化。
性能预算的工具怎样?你可以用Lighthouse CI项目持续集成设置Lighthouse评分预算:
如果您的性能分数低于Lighthouse CI的规定值,可以拒绝那些合并的拉取请求。Lighthouse阈值是另一种基于配置的方法来设置性能预算。
许多性能监控服务支持设置性能预算和预算报警,包括Calibre、Treo、Webdash和SpeedCurve:
我网站teejungle.net的JavaScript性能预算使用SpeedCurve,它支持一些列的预算指标。
接受性能预算可以鼓励团队来认真思考他们从设计阶段的早期到里程碑结束的任何决策的后果。
寻找进一步参考?美国数字服务部门通过为时间到交互等指标设定目标和预算,用Lighthouse记录他们跟踪性能的方法。
下一步..
每个站点都应该可以访问实验室和现场性能数据。
要跟踪JavaScript可能对RUM(真实用户监控)设置中的用户体验产生的影响,网络上有两件事情我建议您检查一下。
现场数据(或RUM - 真实用户监控)是从用户在野外经历的实际页面加载中收集的性能数据。拥有大量JavaScript负载的站点将受益于通过长任务和第一输入延迟测量此工作的主线程。
第一个是长任务 - 一个API,使您能够收集任务(及其属性脚本)的真实世界遥测,持续时间超过50毫秒,可能会阻止主线程。您可以记录这些任务并将其记录回分析。
第一输入延迟(FID)是衡量用户首次与您的站点交互时(即,当他们点击按钮时)到浏览器实际能够响应该交互的时间的度量。FID仍然是一个早期指标,但我们今天有一个可用的折叠,您可以查看。
在这两者之间,您应该能够从真实用户那里获得足够的遥测,以查看他们遇到的JavaScript性能问题。
马塞尔·弗赖比希勒(Marcel Freinbichler)发布了一则面向欧盟用户的关于“今日美国”(USA Today)的病毒推文,用它比正常页面加载快42秒。
众所周知,第三方JavaScript可能会对页面加载性能产生严重影响。虽然这仍然是正确的,但重要的是要承认,今天的许多经验也带来了很多自己的第一方JavaScript。如果我们要快速加载,我们需要消除这个问题的双方可能对用户体验产生的影响。
我们在这里看到了几个常见的漏洞,包括团队在文档头部使用阻止JavaScript来决定向用户显示的A / B测试。或者,将所有A / B测试变体的JS运送下来,即使实际上只使用了一个。
如果这是您目前遇到的主要瓶颈,我们会另外提供有关加载第三方JavaScript的指南。
没有最快,只有更快
性能就像一段旅程,经过了许多小的变更的积累,最终获得大的性能提升。
让你的用户可以尽可能平滑的与你的网站进行交互,运行最少的JavaScript脚本来传递数据。你可以通过逐步递进的方法来慢慢实现这些。最终,你会得到用户的认可。
参考:
非常感谢Thomas Steiner, Alex Russell, Jeremy Wagner, Patrick Hulce, Tom Ankers 和 Houssein Djirdeh 对文章的贡献,也非常感谢 Pat Meenan 在WebPageTest上的努力, 这里有一篇文章是关于WebPageTest的,有兴趣的话可以看一看,你也可以在Twitter上关注我。
评论删除后,数据将无法恢复
评论(6)
引用来自“开源中国-首席村长”的评论
JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行引用来自“半世为仙”的评论
js有可能动态生成dom,改写当前dom,更新当前dom。如果先渲染dom,再加之js,那么用户所见有可能并不是所得。引用来自“喻恒春”的评论
到目前为止, js 和 DOM 的主流关系依然是 动态和静态强耦合关系.开发者难以做到彻底解耦, 为了快速开发大量使用"成品"库, 致使开发基于 "业务表现", 而不是剥离出的 "业务数据逻辑".
不深挖"数据逻辑", 还要快速开发, 还想降 JS 尺寸, 这世界哪里有这么好的事儿.
想降低尺寸很简单: 所有代码根据业务逻辑定制, 不被执行的代码通通剔除.
可有多少人会这么干呢?
有句话说的很有道: 解决了 10 个 BUG, 又创造了 11 个新 BUG
引用来自“开源中国-首席村长”的评论
JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行引用来自“半世为仙”的评论
js有可能动态生成dom,改写当前dom,更新当前dom。如果先渲染dom,再加之js,那么用户所见有可能并不是所得。开发者难以做到彻底解耦, 为了快速开发大量使用"成品"库, 致使开发基于 "业务表现", 而不是剥离出的 "业务数据逻辑".
不深挖"数据逻辑", 还要快速开发, 还想降 JS 尺寸, 这世界哪里有这么好的事儿.
想降低尺寸很简单: 所有代码根据业务逻辑定制, 不被执行的代码通通剔除.
可有多少人会这么干呢?
有句话说的很有道: 解决了 10 个 BUG, 又创造了 11 个新 BUG
引用来自“开源中国-首席村长”的评论
JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行引用来自“开源中国-首席村长”的评论
JS脚本为什么不能延迟加载/执行呢?也就是先加载渲染DOM元素,完成后再在后台下载js脚本文件再执行