2018 前端性能优化清单(转载)

2018 前端性能优化清单 转载自 https://juejin.im/post/5a966bd16fb9a0635172a50a 前言:这篇文章我在掘金翻译计划中跟着一起翻译的文章(感谢掘金翻译),我翻译了第三部分,然后校对了第二部分,这篇文章对于前端性能优化的技术还是比较新颖和全面的,所以决定自己阅读一遍英文原文,然后又用思维导图整理了下重点,英文原文还是挺长的,所以

如果想要粗略的了解本文内容的可以直接查看我总结的思维导图 如果看完思维导图觉得本文对你有所帮助的,可以查看我自己翻译并根据其他人翻译整理后的文章 如果你英文阅读没有障碍,并且觉得我翻译不好的,可以直接阅读 英文原文 推荐大家时间充裕的话可以自己阅读英文原文,此文是根据掘金翻译的四篇文章 + 其他的翻译文章 + 自己翻译修改得出的。因为翻译大家懂得,会有一些错误的地方,欢迎大家指出,本人不保证翻译没有错误,但已经尽力去翻译了,所以欢迎大家直接阅读英文原文!!欢迎大家直接阅读英文原文!!欢迎大家直接阅读英文原文!!

2018 前端性能优化清单思维导图 我们都知道性能很重要,但是,我们是否真的一直都知道我们性能优化的瓶颈在哪?是代价昂贵的 JavaScript?是 web 字体很慢?还是比较大的图片?或者是渲染速度过于迟缓?tree-shaking(无用代码移除)、scope hoisting(作用域提升)、code-splitting(按需加载)、 intersection observer 以及 clients hints、CSS containment、HTTP/2 和 service workers 这些技术都是有利于性能优化的。并且,最重要的是,我们要从哪里开始提升我们的性能呢?并且要怎么建立长久有效的性能机制。

译者注:

tree-shaking:tree-shaking 是 Webpack 2 引入的新功能,tree-shaking 是无用代码移除(DCE, dead code elimination)的一个方法,但和传统的方法不太一样。tree-shaking 找到需要的代码,灌入最终的结果;传统 DCE 找到执行不到的代码,从 AST 里清除。—— 如何评价 Webpack 2 新引入的 Tree-shaking 代码优化技术? scope hoisting:scope hoisting 是 Webpack 3 的新功能,又译作“作用域提升”。Webpack 将所有模块都用函数包裹起来,然后自己实现了一套模块加载、执行与缓存的功能,使用这样的结构是为了更容易实现 Code Splitting(包括按需加载)、模块热替换等功能。—— Webpack 3 的新功能:Scope Hoisting code-splitting:对于大型的 web 应用而言,把所有的代码放到一个文件的做法效率很差,特别是在加载了一些只有在特定环境下才会使用到的阻塞的代码的时候。Webpack有个功能会把你的代码分离成Chunk,后者可以按需加载。这个功能就是code-splitting。—— 在Webpack中使用Code Splitting实现按需加载 intersection observer:可以自动"观察"元素是否可见,由于可见(visible)的本质是,目标元素与视口产生一个交叉区,所以这个 API 叫做"交叉观察器"。—— IntersectionObserver API 使用教程 clients hints:自动响应式图片 —— Automatic responsive images with Client Hints CSS containment:新的 CSS 属性 Containment 允许开发者限制浏览器样式、布局和 paint 工作的范围。—— CSS Containment in Chrome 52 service workers:实现离线页面 ——Service worker concepts and usage 在以前,性能优化经常是在项目完成才去考虑的,经常被推迟到项目的末期,这样优化的范围就会缩小,优化的内容通常是优化静态文件和调整一些服务器配置文件。但是现在,性能优化发生了很大的改变,这些是远远不够的。

性能不仅仅是一个技术问题:重要的是,当将它放入工作流中的时候,做出的设计决策必须受性能的提示。性能必须被测量、监测和完善,而网络日益增长的复杂性也使得跟踪性能的度量原来越难,因为度量会根据设备、浏览器、协议、网络类型和延迟而显着变化(CDN,ISP,缓存,代理,防火墙,负载均衡器和服务器都在性能上发挥作用)。

所以,我们就必须时刻记住性能优化 —— 从项目开始的时候直到网站最后发布。所以我们就创建了一个性能优化列表。(希望是公正的和客观的)2018 前端性能检查表 —— 可以帮助你解决你网站的优化问题,例如,响应时间如何更快,流畅的用户交互和不会流失用户的带宽。

(你也可以仅下载 2018 前端性能优化清单 的 PDF 版本(0.129 MB)或者下载 Apple Pages 版本(0.236 MB))

准备就绪:计划和度量 微小的优化对于保持性能也是十分重要的,但是时刻记着我们必须要有一个明确的目标,可度量的目标将影响整个过程中的任何决策。这里有几种不同的模式,并且下面的方法都是从自身角度出发,所以你要尽早确认你自己优化的优先级。

树立性能优化意识 在很多团队中,前端开发者确切的知道常见的潜在问题是什么,应该用什么样的加载模块来修复。然而,只要开发或者设计那边有一方跟市场的意见不合,性能就不会长时间持续下去。所以,研究用户常见的抱怨的地方,看看提高性能如何帮助解决这些常见问题。

无论是在移动设备上还是在桌面上都需要运行性能实验并测量结果。 它会建立一个用真实数据为你们公司量身定制的案例研究。此外,要善于使用 WPO Stats 上发布的案例研究和实验中的数据,可以帮助提高你对性能和业务之前潜在关系的认识,以及性能对用户体验和业务度量的影响。仅仅说明绩效是不够的 - 你还需要建立一些可衡量和可追踪的目标来观察性能。

目标:至少要比你最快的竞争对手还快 20% 根据 心理学研究,如果你想要用户感觉你的网站比你竞争者的网站快,那么你至少需要比它们快 20%。研究你的主要竞争者,收集他们在手机和桌面上的性能,并且设置一个你能超过他们的临界值。要获取准确的结果和目标,首先要研究你的分析结果,看看你的用户都在做什么。你可以模拟第百分之九十的用户经验进行测试,收集数据,然后建立一个 表格,然后再减去 20% 就是你的目标(即 性能预算)。现在你在测试之前就有了一些可度量的数据。

如果你比较在意预算并尝试去用最小的脚本来获得最快的交互时间,那么你就开始了你的“前端优化之旅”。Lara Hogan 关于如何使用性能预算来处理设计的 指南 可以为设计人员提供有用的指引,而 性能预算计算器 和 Browser Calories 里都可以帮助创建预算(感谢 Karolina Szczur 提供)。

Brad Frost 构建的性能预算 除了性能外,还要考虑对你业务最有利的客户的行为。 设置和讨论关键行动的可接受时间阈值,并设置一个整个团队已经达成一致的 “UX ready”用户时间标记。 大部分情况下,用户的行为涉及许多不同部门,因此,按照设置的可接受的时间安排会避免很多问题。确保额外的资源和功能的额外成本其他成员都是可见和知晓的。

此外,正如 Patrick Meenan 所建议的那样,最好在设计的过程中设置一个加载队列并且要知道这些顺序会存在哪些利弊。你需要优先处理更重要的优先级,并且定义一个它们优先级的顺序,你也应该清楚哪些是可以推迟的。理想的情况,该队列也应该反映出 JS 和 CSS 的加载顺序,只要设计好了,那么在构建过程中处理它们就会很简单了。另外,还需要考虑的是在页面还在加载时页面的“中间状态”(例如,当 web 字体没有加载完时)。

计划计划计划,重要的事情说三遍!如果早期进行优化那么会很容易实现目标,但是没有计划或者没有制定切合实际的、为公司量身定制的业绩目标那么就很难保持性能。

选择正确的度量 不是所有的度量都一样重要。 研究哪些度量对于你的应用程序最重要:通常,这与你能够以多快的速度开始渲染最重要的像素(以及它们的效果)以及如何为这些渲染像素提供输入最快的响应速度有关。 这可以帮助你为后续的工作提供最佳的优化结果。 不管怎样,不要专注于整个页面加载时间(例如 onLoad 和 DOMContentLoaded 时间),而是要优先按照用户可以感知到的页面加载。 也就是说要关注一组稍微不同的度量。

首次有内容渲染,视觉完整和可交互时间之间的区别。来自于:@denar90

你可以参考下面这样度量:

首次有效渲染(FMP,是指主要内容出现在页面上所需的时间), 重要渲染时间(页面最重要部分渲染完成所需的时间), 可交互时间(TTI,是指页面布局已经稳定,关键的页面字体已经可见,主进程可以足够的处理用户的输入 —— 基本的时间标记是,用户可以在 UI 上进行点击和交互), 输入响应,接口响应用户操作所需的时间, Speed Index,测量填充页面内容的速度。 分数越低越好, 自定义度量,由你的业务需求和用户体验来决定。 Steve Souders 对 每个度量都进行了详细的解释。在许多情况下,根据你的应用程序的使用场景,可交互时间和输入响应 会是最关键的。但这些度量可能会不同:例如,对于 Netflix 电视的用户界面来说,关键输入响应、内存使用和可交互时间更为重要。

从具有代表性的用户使用的设备收集数据 为了收集准确的数据,我们需要尽可能全的选择要测试的设备。最好是 Moto G4,或者一款中档的三星设备又或者是一个 Nexus 5X 这样的普通的设备。如果你手边没有设备,可以使用节流 CPU(5× 减速)来限制网速(例如,150 ms 的往返时延,1.5 Mbps 以下和0.7 Mbps 以上)实现在桌面设备上模拟移动设备的体验。最终,切换到常规的 3G,4G 和 Wi-Fi。为了使性能体验的影响更明显,你甚至可以使用 2G 或 一个节流的 3G 网络,以便进行更快的测试。

因为周二是一周中最慢的一天。Facebook推出了2G Tuesdays,以提高对低速连接的能见度和灵敏度。(图片来源) 幸运的是,有很多优秀的选项可以帮助你自动收集数据,并根据这些度量衡量你的网站在一段时间内的性能。 请记住,良好的性能度量是需要被动和主动监控工具的组合:

被动监测工具,可以根据请求来模拟用户交互(综合测试,如Lighthouse,WebPageTest) 主动监测工具, 是那些不断记录和评价用户交互行为的(真正的用户监控,如 SpeedCurve,New Relic —— 这两种工具也提供综合测试) 前者在开发过程中特别有用,因为它可以在使用产品时持续跟踪。 后者在长期维护非常有用,因为它可以帮助你了解在实际访问站点时发生的性能瓶颈。通过使用导航定时、资源定时、绘图定时、长时间任务等内置的 RUM API,被动和主动性能监视工具一起提供应用程序性能的完整画面。 例如,你可以使用PWMetrics,Calibre,SpeedCurve,mPulse,Boomerang 和 Sitespeed.io,这些都是性能监测工具的绝佳选择。

注意:选择浏览器外部的网络级别的限制器总是比较安全的,例如 DevTools 由于实现的方式而存在与 HTTP/2 推送交互的问题(感谢Yoav!)。

Lighthouse一个集成在 DevTools 的性能检测工具。 与你的同事分享性能清单 为了避免误解,要确保你团队里的每个同事都对清单很熟悉。每个决策都对性能有影响。项目将极大地受益于前端开发人员正确地将性能价值传达给整个团队。从而使每个人都对它负责,而不仅仅是前端开发人员。根据绩效预算和清单中定义的优先顺序来设计决策。

RAIL,以用户为中心的性能模型。 制定现实的目标 控制响应时间在 100ms 内,控制帧速在 60 帧/秒 为了让交互感觉起来很顺畅,接口有 100ms 来响应用户的输入。任何比它长的时间,用户都会认为该应用程序很慢。RAIL,一个以用户为中心的性能模型会为你提供健壮的目标。为了让页面达到小于 100ms 的响应,页面必须要在小于 50ms 前最迟将控制权返回给主线程。预计输入延迟时间 告诉我们,如果我们能达到这个门槛,在理想情况下,它应该低于 50ms。对于像动画这样性能消耗比较大的地方,最好的做法是,在能够优化的地方,尽量优化到极致;在不能优化的地方,让性能开销降至最低。

同时,每一帧动画应该要在 16 毫秒内完成,从而达到 60 帧每秒(1秒 ÷ 60 = 16.6 毫秒) —— 最好可以在 10 毫秒完成。因为浏览器需要时间将新框架绘制到屏幕上,你的代码应该在触发 16.6 毫秒以内完成。保持乐观和明智地利用空闲时间。显然,这些目标适用于运行时的性能,而不是加载性能。

速度指标(SpeedIndex) < 1250,3G 上交互时间 < 5s,关键文件大小 < 170Kb(SpeedIndex < 1250, TTI < 5s on 3G, Critical file size budget < 170Kb) 虽然这可能很难实现,一个好的最终目标是首次有效渲染低于 1 秒并且速度指标的值低于 1250。因为我们是以 200 美金为基准的 Android 手机(如 Moto G4)和一个缓慢的 3G 网络上,模拟 400ms 的往返延时和 400kb 的传输速度,所以我们的目标是可交互时间低于 5s,并且再次访问的时间低于 2s。

请注意,当谈到可交互时间时,最好来区分一下首次交互和连续交互以避免对它们之间的误解。前者是在主要内容已经渲染出来后最早出现的点(窗口至少需要 5s,页面才开始响应)。后者是期望页面可以一直进行输入响应的点。

HTML 的前 14~15kb 加载是是最关键的有效载荷块 —— 也是第一次往返(这是在400 ms 往返延时下 1 秒内所得到的)预算中唯一可以交付的部分。一般来说,为了实现上述目标,我们必须在关键的文件大小内进行操作。最高预算压缩之后 170 Kb(0.8-1MB解压缩),它已经占用多达 1s (取决于资源类型)来解析和编译。稍微高于这个值是可以的,但是要尽可能地降低这些值。

尽管如此,还是可以提高绑定的规模预算。例如,你可以在浏览器主线程的活动中设置性能预算,例如,在开始渲染前的绘制时间或者跟踪前端 CPU 。像 Calibre,SpeedCurve 和 Bundlesize 这些工具可以帮助你保持你的预算控制,并集成到你的构建过程。

本来就很快的:现代化加载的最佳实践 来自 Addy Osmani(幻灯片 19) 定义环境 做好构建工具的选型以及搭建好(适合自己的)构建工具 现如今不要太在意那些很酷的技术栈。根据你的项目使用你的构建工具,无论是 Grunt,Gulp,Webpack,Parcel,还是工具间的组合。只要你能快速的得到结果,并且保证你的构建过程没问题。那么,你就可以选择该构建工具。

渐进式增强 安全的选择是将 渐进式增强 作为前端架构和项目部署的指导原则。首先设计和构建核心体验,然后为有能力的浏览器使用高级特性增强体验,创造 弹性 体验。如果你的网站是在一个网络不佳的并且有个糟糕的显示屏上糟糕的浏览器上运行,速度还很快的话,那么,当它运行在一个快速网络下快速的浏览器的机器上,它只会运行得更快。

选择一个强大的性能基准 有这么多未知因素影响加载 —— 网络、热保护、缓存回收、第三方脚本、解析器阻塞模式、磁盘的读写、IPC jank、插件安装、CPU、硬件和内存限制、L2/L3缓存、RTTS、图像、Web字体加载行为的差异 —— JavaScript 的代价是最大的,web 字体阻塞默认渲染和图片的加载消耗了大量的内存。随着性能瓶颈从 服务器端转移到客户端,作为开发人员,我们必须更仔细地考虑所有这些未知因素。

在 170kb 的预算中,已经包括了关键路径的 HTML / CSS / JavaScript、路由器、状态管理、实用程序、框架和应用程序逻辑,我们必须彻底检查网络传输成本,解析/编译时间和运行时间来选择我们的框架。

现代化加载的最佳实践来自 Addy Osmani(幻灯片18、19)。 正如 Seb Markbage 所 指出的,测量框架的启动成本的好方法是首先渲染视图,再删除它,然后再渲染,因为它可以告诉你框架是如何扩展的。

第一次渲染倾向于预热一堆编译迟缓的代码,当它扩展时,更大的分支可以从中受益。第二次渲染基本上是仿效页面上的代码重用是如何随着页面复杂度的增长来影响性能特征。

并不是每个项目都需要框架。事实上,某些项目 可以完全移除某些框架并从中受益。一旦选择了一个框架,你最少会使用好几年。所以,如果你需要使用它,确保你的选择是经过深思熟虑的 并且 对其完全了解。在进行选择前,至少要考虑总大小的成本 + 初始解析时间:轻量级的选项像 Preact,Inferno,Vue,Svelte 或者 Polymer 都做得很好。框架的大小基线将为你的应用程序代码定义约束条件。。

JavaScript 解析成本可能有很大差异。现代化加载的最佳实践 来自Addy Osmani (幻灯片 10)。 请记住,在移动设备上,与台式计算机相比,预计速度会有 4-5 倍的下降。因为移动设备的 GPU、CPU、内存及电池特性都不同。在手机上的解析时间比桌面设备的要高 36%。所以总在一个最能代表普遍用户的平均的设备上测试。

不同的框架将会对性能产生不同的影响,并且需要不同的优化策略。因此,你必须清楚地了解你所依赖的框架的所有细节。当创建一个 web 应用的时候,参考 PRPL 模式 和 应用程序 shell 体系结构。这个想法很简单: 用最少的代码来将初始路由的交互快速呈现,然后使用 service worker 进行缓存和预缓存资源,然后使用懒加载异步加载所需的路由。

PRPL Pattern in the application shell architecture PRPL 代表的是保持推送关键资源,渲染初始路由,预缓存剩余路由和延迟加载必要的剩余路由。

Application shell architecture 应用程序 shell 是最小的 HTML、CSS 和 JavaScript 驱动的用户界面。

你的项目需要使用 AMP 和 Instant Articles 么? 译者注:AMP 即加速移动页面,是一种制作可快速加载的轻量型网页的方法,特别适合于移动设备。

依赖于你的组织优先级和战略,你可以考虑使用谷歌的 AMP 和 Facebook 的 Instant Articles 或者苹果的 Apple News。如果不使用它们,你也可以实现很好的性能,但是 AMP 确实提供了一个免费的内容分发网络(CDN)的性能框架,而 Instant Articles 将提高你在 Facebook 上的知名度和表现。

对于用户而言,这些技术主要的优势是确保性能,所以有时他们更喜欢 AMP-/Apple News/Instant Pages 链接,而不是“常规”和潜在的臃肿页面。对于那些以内容为主的网站,主要处理很多第三方法内容,这些选择极大地加速渲染的时间。

对于站长而言,这些样式在各个平台可发现性并且 增强在搜索引擎中的可见性。你也可以重新使用 AMP 作为你的 PWA 数据源来构建渐进的 Web AMPs。有什么缺点呢?显然,在一个有围墙的区域里,开发者可以创造并维持与内容分离的单独版本,防止 Instant Articles 和 Apple News 没有实际的URLs。(谢谢,Addy,Jeremy)

合理使用 CDN 根据你拥有的动态数据量,你可以将部分内容外包给静态站点生成工具 如 Jekyll、Hexo 生成的静态文件,接着把静态文件推到 CDN 中,最后 CDN 只是提供静态文件的静态版本。所以这样就可以避免发起对数据库的读写请求。你甚至可以选择一个基于 CDN 的静态主机平台,(这样就可以)通过给页面添加可交互组件的方式来丰富你的页面,并以此作为性能提升的标志 (JAMStack)。

请注意,CDN 也是可以托管并卸载(offload)动态内容的,所以咱们没有必要把 CDN 的服务范围限定在静态资源。(另外需要你记住的是),不管你的 CDN 是否执行内容压缩(GZip)、内容转换、HTTP/2 传输以及 ESI(一种标记语言,可以用它把网页划分为单独的可缓存的实体)等操作,我们还是需要复核上述操作的,这是因为上述操作不仅会在 CDN 的 edge 处(服务器最接近用户的地方)聚合页面中的静态以及动态内容,也还会执行其它任务。

构建优化 分清轻重缓急 你应该知道优先处理什么。运行你所有静态资源(JavaScript、图片、字体、第三方脚本和页面中“昂贵的”模块,比如:轮播图、复杂的图表和多媒体内容),并将它们划分成组。

先搞清楚资源(assets)可以分为几类,大致可以分为:

针对传统的浏览器,定义基本的核心功能(比如:完全可访问的核心内容) 针对多功能浏览器提升功能(比如:丰富多彩的,完美的体验) 其他资源(不是绝对需要而且可以被延迟加载的资源,如 Web 字体、不必要的样式、旋转木马脚本、视频播放器、社交媒体按钮、大型图像) 我们在“Improving Smashing Magazine's Performance”上发布了一篇文章,上面详细描述了该方法。

考虑使用“cutting-the-mustard”模式 虽然这个技术已经很老了,但我们仍然可以使用 cutting-the-mustard 技术 使传统浏览器使用核心功能并增强对现代浏览器的体验。严格限制加载的资源:优先加载核心功能,然后是提升的,最后是其他的。注意:该技术可以从浏览器版本中推断出设备功能,而现在我们已经不再这样做了。

例如:在发展中国家,廉价的安卓手机主要运行 Chrome,他们的内存和 CPU 有限。PRPL 模式 就是一个好的选择。最终,使用 Device Memory Client Hints Header,我们就能够更可靠地识别出低端设备。现在,只有在 Blink 中才支持 header (Blink 支持client hints)。因为设备存储也有一个在 Chrome 中可以调用的 JavaScript API,一种选择是基于 API 的特性检测,只在不支持的情况下回退到“符合标准”技术(谢谢,Yoav!)。

减少解析JavaScript 的成本 当我们处理单页面应用时,在你的页面渲染之前你需要初始化应用。寻找模块和技术加快初始化渲染时间(例如:如何调试 React 性能,以及如何提高 Angular 性能),因为大多数性能问题来自于启动应用程序的初始解析时间。

JavaScript 有成本,但不一定是文件大小影响性能。解析和执行时间的不同很大程度依赖设备的硬件。在一个普通的手机上(Moto G4),仅解析 1MB (未压缩的)的 JavaScript 大概需要 1.3-1.4 秒,会有 15 - 20% 的时间耗费在手机的解析上。在执行编译过程中,只是用在 JavaScript 准备平均需要 4 秒,在手机上页面展示其主要内容所需的时间(First Meaningful Paint)需要 11 秒。解释:在低端移动设备上,解析和执行时间可以轻松提高 2 至 5 倍。

Ember 最近做了一个实验,使用二进制模板(binary templates )巧妙的避免解析开销的方式。这些模板不需要解析。(感谢,Leonardo!)

这就是检查每个 JavaScript 依赖性的关键,像 webpack-bundle-analyzer、Source Map Explorer 和 Bundle Buddy 这样的工具可以帮助你完成这些。度量 JavaScript 解析和编译时间。Etsy 的 DeviceTiming,一个小工具可以让你的 JavaScript 测量任何设备或浏览器上的解析和执行时间。重要的是,虽然文件的大小重要,但它不是最重要的。解析和编译时间并不是随着脚本大小增加而线性增加。

Webpack Bundle Analyzer visualizes JavaScript dependencies.

你使用 ahead-of-time 编译器么? 使用 ahead-of-time 编译器 来 减轻从客户端 到 服务端的渲染 的开销,因此快速输出有用的结果。最后,考虑使用 Optimize.js 通过包装可快速调用的函数来实现(在app初始时能够)快速载入(尽管,它可能不需要)。

你使用 tree-shaking、scope hoisting、code-splitting 么 Tree-shaking 是一种清理构建过程的方法通过只加载生产中实际使用的代码并清除 在 Webpack 中 未使用的 import。使用 Webpack 3 和 Rollup,我们还可以使用 scope hoisting(作用域提升),scope hoisting 允许工具检测哪些 import 可以被提升或者可以转换成一个内联函数。有了 Webpack 4,你现在可以使用 JSON Tree Shaking。UnCSS 或者 Helium 可以帮助你去删除未使用 CSS 样式。

而且,你需要考虑 如何编写有效的 CSS 选择器 以及 如何避免编写臃肿和开销浪费的样式。你也可以使用 Webpack 缩短类名和在编译时使用独立作用域来 动态地重命名 CSS 类

Code-splitting 是 Webpack 的另一个特性,可将你的代码分解为按需加载的“块”。并不是所有的 JavaScript 都是必须下载、解析和编译的。一旦你在代码中确定了分割点,Webpack 会处理这些依赖关系和输出文件。在应用发送请求的时候,这样基本上确保初始的下载足够小并且实现按需加载。另外,考虑使用 preload-webpack-plugin 获取代码拆分的路径,然后使用 or 提示浏览器预加载它们。

在哪里定义分离点?通过追踪哪些 CSS/JavaScript 块被使用和哪些没有被使用。Umar Hansa 解释了你如何使用 Devtools 的 Code Coverage 来实现。

如果你没有使用 Webpack,那么相比于 Browserify 的输出结果, Rollup 的输出更好一些。当使用 Rollup 时,推荐你了解下 Rollupify,它可以将 ECMAScript 2015 modules 转化为一个大的 CommonJS module —— 因为小的模块会有令人惊讶的高性能开销(取决于打包工具和模块加载系统的选择)。

Addy Osmani 的“默认快速:现代化加载的最佳实践” Addy Osmani 的从快速默认:现代加载的最佳实践。幻灯片76。

最后,随着现代浏览器对 ES2015 支持越来越好,考虑 使用babel-preset-env 只转换现代浏览器不支持的 ES2015+ 的特性。然后设置两个构建,一个为 ES6 一个为 ES5。我们可以 使用script type="module" 让具有 ES 模块浏览器支持加载文件,而老的浏览器可以加载传统的 script nomodule。

对于 loadsh,使用 babel-plugin-lodash 将只加载你仅在源码中使用的模块。这可能会为你节省相当多的 JavaScript 负载。

利用你使用的 JavaScript 引擎对其进行优化 研究 JavaScript 引擎在用户基础中占的比例,然后探索优化它们的方法。例如,当优化的 V8 引擎是用在 Blink 浏览器,Node.js 运行和 Electron 的时候,对每个脚本使用脚本流。一旦下载开始,它允许 async 或 defer scripts 在一个单独的后台线程进行解析,因此在某些情况下,提高 10% 的页面加载时间。实际上,在 中 使用

你可能感兴趣的:(2018 前端性能优化清单(转载))