原文地址：https://www.smashingmagazine.com/2018/01/front-end-performance-checklist-2018-pdf-pages/javascript
性能很重要——咱们都知道。可是，咱们是否真的老是知道咱们的性能瓶颈到底是什么？是昂贵的JavaScript，慢Web字体传递，沉重的图像，或缓慢渲染？是否值得借助交叉口观察员，客户提示，css遏制，HTTP / 2和service worker探索摇树优化，范围提高，代码分割以及全部的花式加载模式？最重要的是，咱们从哪里开始提升绩效，如何创建一个长期的绩效文化？css
早些时候，性能每每只是过后才想到的。一般推迟到项目的最后，这将归结为缩小，串联，资产优化和可能在服务器的配置文件上的一些细微的调整。如今回头看，事情彷佛已经发生了至关大的变化。html
性能不只仅是一个技术问题：它很重要，并且在将其引入到工做流程中时，必须经过性能影响来告知设计决策。性能必须不断测量，监控和改进，网络日益复杂的挑战使得很难跟踪指标，由于指标会因设备，浏览器，协议，网络类型和延迟而显着变化（cdns，isps，缓存，代理，防火墙，负载均衡器和服务器都在性能中发挥做用）。前端
因此，若是咱们在提升性能的时候建立了全部事情的概述，从流程的开始到网站的最终发布，这个列表会是什么样的？下面你会发现2018年的一个（但愿是公正的，客观的）前端性能检查清单——你可能须要考虑的问题的概述，以确保你的响应时间快，用户交互顺畅，你的网站不流失用户的带宽。vue
微观优化对于保持业绩的顺利进行是很是重要的，可是要明肯定义目标是相当重要的——可衡量的目标会影响整个过程当中作出的任何决策。有几种不一样的模型，下面讨论的模型都是颇有见地的——只要确保尽早设置本身的优先级。html5
在许多组织中，前端开发人员确切知道哪些常见的底层问题以及应该使用何种加载模式来修复这些问题。可是，只要开发/设计和营销团队之间没有一致，绩效就不会长期持续下去。研究客户服务中常见的抱怨，看看提升性能如何帮助解决这些常见问题。java
运行性能实验并测量结果 -不管是在移动设备上仍是在桌面上。它将帮助您创建一个公司量身定制的案例研究与真实的数据。此外，使用来自wpo统计信息发布的案例研究和实验的数据能够帮助提升业务对于性能相当重要的敏感性，以及它对用户体验和业务指标的影响。说虽然单靠表演是不够的，你还须要创建一些可衡量和可追踪的目标并观察它们。node
根据心理学研究，若是你但愿用户以为你的网站比竞争对手的网站快，你至少要快20％。研究你的主要竞争对手，收集他们如何在移动和桌面上执行的指标，并设置阈值，将帮助你超越他们。为了得到准确的结果和目标，首先要研究你的分析，看看你的用户在哪里。那么你能够模仿第90百分位的测试经验。收集数据，创建电子表格，削减20％，并以这种方式设定你的目标（即绩效预算）。如今你有一些能够测试的东西。react
若是你在考虑预算的状况下，尽可能减小最小的脚本以便快速交互，那么你就处于一个合理的路径上。lara hogan关于如何用性能预算来处理设计的指南能够为设计人员提供有用的指针，而性能预算计算器和浏览器卡路里均可以帮助建立预算。android
超出绩效预算，考虑对您的业务最有利的关键客户任务。设定和讨论关键行动的可接受的时间阈值，并创建整个组织已经赞成的“准备就绪”的用户时间标记。在许多状况下，用户旅程将涉及许多不一样部门的工做，所以，按照可接受的时间安排将有助于支持或阻止下一步的业绩讨论。确保额外的资源和功能的额外成本可见和理解。
另外，正如帕特里克·梅南（patrick meenan）所建议的那样，在设计过程当中计划一个装载顺序和权衡是值得的。若是您尽早优先考虑哪些部分更为重要，并肯定它们应该出现的顺序，您也将知道什么能够推迟。理想状况下，该顺序也将反映您的CSS和JavaScript导入的顺序，因此在构建过程当中处理它们将更容易。当页面被加载时（例如当网页字体没有被加载时），考虑“中间”状态下的视觉体验应该是什么。
计划，计划，计划。可能很早就进入快速优化的阶段，而且最终可能成为快速获胜的一个好策略 -可是若是没有规划和现实的公司规划，量身定制的表现目标。
不是全部的指标都一样重要。研究哪些指标对于您的应用程序最为重要：一般，这与您可以以多快的速度开始渲染最重要的像素（以及它们是什么）有关，以及为这些渲染的像素提供输入响应速度的速度。这些知识将为您持续努力提供最佳的优化目标。这样或者那样，而不是专一于整个页面加载时间（例如经过onload和domcontentloaded计时），优先考虑您的客户感知的页面加载。这意味着要关注一组稍微不一样的指标。实际上，选择正确的指标是一个没有明显优点的过程。
如下是一些值得考虑的指标：
l 第一个有意义的油漆（fmp，当主要内容出如今页面上），
l 英雄渲染时间（当页面的重要内容完成渲染时），
l 交互的时间（tti，布局已经稳定的点，关键字体是可见的，而且主线程足以处理用户输入-基本上是用户能够点击ui并与之交互的时间标记），
l 输入响应性（界面响应用户操做须要多少时间），
l 知觉速度指数（测量页面内容的可视化速度有多快;得分越低越好），
l 您的自定义指标，由您的业务需求和客户体验所定义。
steve souders有每一个指标的详细解释。而在许多状况下，tti和输入响应将是最关键的，这取决于您的应用程序的上下文，这些度量可能有所不一样：例如，对于netflix电视用户来讲，键盘输入响应能力，内存使用状况和tti更为重要。
为了收集准确的数据，咱们须要完全选择要测试的设备。选择一个motog4，一个中档的三星设备和一个像nexus 5x这样的好的中间设备，或许在一个开放的设备实验室里是个不错的选择。若是您手边没有设备，则能够经过在节流网络（例如150ms rtt，1.5 mbps向下，0.7 mbps向上）上进行测试来模拟桌面上的移动体验（速度为5倍速度减速）。最终切换到常规3G，4G和WiFi。为了使性能影响更加明显，您甚至能够在办公室中引入2g星期二或者在您的办公室中设置一个节流3g网络，以便进行更快的测试。
幸运的是，有不少很棒的选项能够帮助您自动收集数据，并根据这些指标衡量您的网站在一段时间内的表现。请记住，良好的性能指标是被动和主动监控工具的组合：
l 被动监视工具，能够根据请求模拟用户交互（综合测试，例如灯塔，网页测试）
l 主动监控工具，不断记录和评估用户的交互（真实的用户监控，例如speedcurve，新的文物-这两个工具也提供综合测试）。
前者在开发过程当中特别有用，由于它能够帮助您在使用产品时保持正轨。后者对于长期维护很是有用，由于它能够帮助您了解当用户实际访问站点时发生的性能瓶颈。经过使用导航时间，资源定时，绘图时间，长时间任务等内置朗姆酒API，无源和有源性能监测工具一块儿提供应用程序性能的完整画面。例如，您能够使用pwmetrics，calibre，speedcurve，mpulse和boomerang，sitespeed.io，这些都是性能监控的绝佳选择。
注意：在浏览器外部选择网络级别的通道老是比较安全的，例如devtools因为实现的方式，而与http / 2 push有交互问题。
确保清单对您的团队中的每一个成员都很熟悉，以免误解。每一个决策都有性能影响，项目将从前端开发人员得到巨大收益，将整个团队的绩效价值正确地传达给每一个人，这样每一个人都会为此感到责任，而不只仅是前端开发人员。根据绩效预算和清单中定义的优先顺序制定设计决策。
为了使交互感受平滑，界面有100ms响应用户的输入。任何更长的时间，用户以为应用程序laggy。轨道，一个以用户为中心的性能模型为您提供了健康的目标：为了容许<100毫秒的响应，页面必须在每一个<50毫秒后最迟将控制权交还给主线程。估计输入延迟告诉咱们，若是咱们正在达到这个门槛，理想状况下，它应该低于50ms。对于像动画这样的高压点，最好不要在别的地方作任何事情，在绝对的最小的地方作不到的地方。
并且每帧动画应该在16毫秒内完成，从而达到每秒60帧（1秒÷60 = 16.6毫秒） -最好在10毫秒如下。由于浏览器须要时间将新框架绘制到屏幕上，您的代码应该在达到16.6毫秒以前完成执行。乐观，明智地使用空闲时间。显然，这些目标适用于运行时性能，而不是加载性能。
尽管实现起来可能很是困难，可是一个好的最终目标将是在1秒内有意义的油漆，在1250如下的速度指数值。考虑到在慢速3G网络上的基线是一个200美圆的android手机（例如moto g4），仿真时间为400msrtt和400kbps的传输速度，目标为5s如下互动，重复访问，目标为2s如下。
请注意，在谈到交互式时间时，最好先区分互动性和一致性，以免误解。前者是主内容呈现以后的最先点（其中至少有5秒钟的页面响应）。后者是页面能够预期老是对输入做出响应的地方。
HTML的第一个14〜15kb是最关键的有效负载块-并且是第一次往返传输的预算的惟一部分（这是你在400ms rtt下1秒内得到的）。更通常地说，为了实现上述目标，咱们必须在最大的关键文件大小预算内运行。170KB gzipped（0.8-1mb解压缩）已经将须要长达1秒（取决于资源类型）解析和编译在通常的电话。略高于此就好，但要尽量下降这些数值。你也能够超越捆绑大小的预算。例如，您能够在浏览器的主线程的活动上设置性能预算，例如在开始渲染以前绘制时间，或者追踪前端cpu hogs。像calibre，speedcurve和bundlesize这样的工具能够帮助您控制预算，而且能够集成到构建过程当中。
不要太在乎这些天过得好酷的东西。坚持你的环境来建设，不管是咕噜咕噜，喝咖啡，webpack，包裹，或工具的组合。只要你获得的结果你须要快速，你没有任何问题，维护你的构建过程，你作得很好。
保持逐步加强做为前端架构和部署的指导原则是一个安全的选择。先设计和构建核心体验，再用强大的浏览器的先进功能加强体验，创造灵活的体验。若是您的网站运行速度很慢，并且网页浏览器效果不佳，您的网页显示效果不佳，那么在网络不错的浏览器上运行速度会更快。
有不少未知因素会影响加载 -网络，热调节，缓存驱逐，第三方脚本，解析器阻塞模式，磁盘I / O，ipc jank，安装的扩展，cpu，硬件和内存限制，l2 / l3缓存区别，rtts，图像，Web字体加载行为- JavaScript有最重的经验成本，旁边的Web字体阻止默认渲染和图像每每消耗太多的内存。随着性能瓶颈从服务器移到客户端，做为开发者，咱们必须更详细地考虑全部这些未知数。
一个170kb的预算已经包含关键路径html / css / javascript，路由器，状态管理，实用程序，框架和应用程序逻辑，咱们必须仔细研究网络传输成本，解析/编译时间和运行时间成本咱们选择的框架。
正如seb markbager所指出的那样，衡量框架启动成本的一个好方法是首先渲染一个视图，而后删除它，而后再次渲染，由于它能够告诉你框架是如何扩展的。
第一个渲染每每会预热一堆懒洋洋地编译的代码，一个更大的树能够从它的缩放中受益。第二个渲染基本上是模拟页面上的代码重用如何随着页面复杂度的增加而影响性能特性。
不是每一个项目都须要一个框架。事实上，一些项目能够从彻底移除现有的框架中受益。一旦选择了一个框架，你至少要呆上几年，因此若是你须要使用框架，请确保你的选择是知情的和充分考虑的。在选择一个选项以前，至少考虑大小和初始解析时间的总成本是一个好主意;preact，inferno，vue，苗条或聚合物等轻量级选项可让工做顺利完成。基线的大小将定义应用程序代码的约束条件。
请记住，在移动设备上，与台式机相比，您应该预计会有4倍-5倍的放缓。移动设备有不一样的gpus，cpu，不一样的内存，不一样的电池特性。手机上的解析时间比桌面上高36％。所以，请始终在平均设备上进行测试-这是最能表明您的受众群体的设备。
不一样的框架将会对性能产生不一样的影响，而且须要不一样的优化策略，因此你必须清楚地理解你将依赖的框架的全部细节。在构建Web应用程序时，请查看prpl模式和应用程序外壳架构。这个想法很是简单：将初始路由的交互性所需的最小代码推送为快速渲染，而后使用service worker进行缓存和预先缓存资源，而后异步地延迟加载所需的路由。
根据贵组织的优先级和策略，您可能须要考虑使用谷歌的放大器或Facebook的即时文章或苹果的苹果新闻。若是没有它们，你能够得到良好的性能，可是放大器确实提供了一个可靠的内容交付网络（cdn）的性能框架，而即时文章将提升你在Facebook上的知名度和性能。
这些技术对用户的主要好处是保证了性能，因此有时他们甚至可能更喜欢amp- / apple新闻/即时页面连接，而不是“普通”和可能膨胀的页面。对于处理大量第三方内容的内容较重的网站，这些选项可能会大大加速渲染时间。
网站全部者的利益是显而易见的：这些格式在各自的平台上的可发现性以及在搜索引擎中的可见度提升。你也能够创建一个渐进的网络放大器，经过重用amps做为你的pwa的数据源。下行？显然，在围墙花园中的存在使得开发者可以产生并保持其内容的单独版本，而且在即时文章和苹果消息的状况下没有实际的URL。
根据您拥有多少动态数据，您可能可以将某些部份内容“外包”到静态站点生成器，并将其推送到cdn并从中提供静态版本，从而避免数据库请求。你甚至能够选择一个基于cdn的静态托管平台，用交互式组件加强页面（jamstack）。
请注意，cdns也能够提供（和卸载）动态内容。因此，限制你的cdn到静态资产是没有必要的。仔细检查你的cdn是否执行压缩和转换（例如格式化，图像优化压缩和边缘调整），智能http / 2交付，边缘包括，在cdn的边缘组装页面的静态和动态部分（即离用户最近的服务器）以及其余任务。
首先知道你在处理什么是个好主意。运行全部资产（JavaScript，图像，字体，第三方脚本和页面上的“昂贵”模块，如轮播，复杂的信息图表和多媒体内容）的清单，并将其分组。设置一个电子表格。定义传统浏览器的基本核心体验（即彻底可访问的核心内容），加强的功能强大的浏览器体验（即丰富的，完整的体验）和额外资源（不是绝对须要的，能够延迟加载的资源，例如网页字体，没必要要的风格，旋转木马脚本，视频播放器，社交媒体按钮，大图像）。咱们发表了一篇关于“提升粉丝杂志的表现”的文章，详细描述了这个方法。
尽管至关古老，但咱们仍然能够使用切割芥末技术将核心体验发送到传统浏览器，并加强现代浏览器的体验。在加载资源时要严格：加载核心体验，而后进行加强，而后加入额外的内容。请注意，该技术从浏览器版本中推导设备功能，这已经不是咱们如今能够作的事了。例如，发展中国家的廉价Android手机大多运行Chrome，尽管其内存和CPU的能力有限，但仍将切断芥末。这就是prpl模式能够做为一个很好的选择。最终，使用设备内存客户端提示标题，咱们将可以更可靠地定位低端设备。在写这篇文章的时候，头文件只能在眨眼的时候才支持（通常用于客户端提示）。因为设备内存也有一个已经在Chrome浏览器中可用的JavaScript API，一个选项多是基于API的功能检测，而且只有在不受支持的状况下回退到“切割芥末”技术
在处理单页面应用程序时，可能须要一些时间来初始化应用程序，而后才能呈现页面。寻找模块和技术来加速最初的渲染时间（例如，这里是如何调试反应性能，以及如何提升角度性能），由于大多数性能问题来自初始解析时间来引导应用程序。
JavaScript有成本，但不必定是耗尽性能的文件大小。解析和执行时间取决于设备的硬件而显着变化。在通常的手机（moto g4）上，1MB（未压缩）javascript的解析时间将在1.3-1.4s左右，15-20％的时间都在手机上进行解析。随着编译的玩法，只是准备工做的JavaScript平均须要4秒，大约11秒以前，第一次有意义的移动会话。缘由：在低端移动设备上，解析和执行时间能够轻松地提升2-5倍。
避免分析成本的一个有趣的方法是使用最近引入的用于实验的二进制模板。这些模板不须要被解析。
这就是为何检查每一个JavaScript依赖关系相当重要的缘由，像bundle buddy，webpack-bundle-analyzer和source map explorer这样的工具能够帮助你实现这一点。测量JavaScript解析和编译时间。etsy的设备时间，一个小工具，容许您指示您的JavaScript测量任何设备或浏览器上的解析和执行时间。底线：虽然规模很重要，但这不是一切。当脚本大小增长时，解析和编译时间不必定会线性增长。
使用提早编译器将一些客户端渲染卸载到服务器，从而快速输出可用的结果。最后，考虑使用optimize.js更快的初始加载，经过包装急切调用的函数（但可能再也不须要）。
树形抖动是一种清理构建过程的方法，仅包含生产中实际使用的代码，并消除webpack中未使用的导出。与webpack 3和汇总，咱们也有范围提高，容许这两个工具来检测哪里进口链能够被夷为平地，并转换成一个内联函数而不妥协的代码。与webpack 4，你如今能够使用json树抖动。uncss或氦气能够帮助你从CSS中删除未使用的风格。
另外，你可能要考虑学习如何编写高效的CSS选择器，以及如何避免膨胀和昂贵的风格。感受就像超越那个？您也能够使用webpack来缩短类名称，并使用做用域隔离来在编译时动态地重命名css类名称。
代码拆分是另外一个webpack功能，将您的代码分解为按需加载的“块”。不是全部的JavaScript都必须当即下载，解析和编译。一旦在代码中定义了分割点，webpack就能够处理依赖和输出文件。它使您能够保持最初的下载量小，并在应用程序请求时按需请求代码。另外，请考虑使用preload-webpack-plugin，它采用代码分割的路由，而后使用<link rel =“preload”>或<link rel =“prefetch”>提示浏览器预加载它们。
在哪里定义分割点？经过跟踪哪些css / javascript块被使用，哪些不被使用。umar hansa解释了如何使用devtools的代码覆盖率来实现它。
若是您不使用webpack，请注意汇总显示比browserify导出显着更好的结果。虽然咱们在这里，但您可能须要查看rollupify，它将ecmascript 2015模块转换为一个大的commonjs模块-由于根据您对bundler和模块系统的选择，小模块可能会有使人惊讶的高性能成本。
最后，es2015在现代浏览器中获得了很是好的支持，能够考虑使用babel-preset-env来仅转发您所定位的现代浏览器不支持的es2015 +功能。而后创建两个版本，一个在es6和一个在es5。咱们能够使用script type =“module”来让带有es模块的浏览器支持加载文件，而旧的浏览器则能够使用script nomodule加载遗留的build。
对于lodash，使用babel-plugin-lodash将只加载你在源代码中使用的模块。这可能会为您节省至关多的JavaScript负载。
研究你的用户群中的JavaScript引擎占主导地位，而后探索优化它们的方法。例如，当在用于闪烁浏览器，node.js运行时和电子的v8优化时，利用脚本流来实现单片脚本。它容许异步或延迟脚本在下载开始后在单独的后台线程上解析，所以在某些状况下可将页面加载时间提升多达10％。实际上，在<head>中使用<script defer>，以便浏览器能够及早发现资源，而后在后台线程上解析它。
注意：歌剧迷不支持脚本延期，因此若是你正在开发印度或非洲，延迟将被忽略，致使阻塞渲染，直到脚本已被评估。
在这两种状况下，咱们的目标应该是设置逐步引导：使用服务器端渲染来得到快速的第一个有意义的绘制，但也包含一些最小的必要的JavaScript，以保持交互的时间接近第一个有意义的油漆。若是JavaScript在第一次有意义的绘制以后来得太迟，那么浏览器可能会在解析，编译和执行迟发现的javascript时锁定主线程，从而对站点或应用程序的交互性形成手铐。
为了不它，老是把函数的执行分解成单独的异步任务，而且在可能的状况下使用requestidlecallback。考虑使用webpack的动态import（）支持延迟加载ui的部分，避免加载，解析和编译成本，直到用户真正须要它们。
在本质上，互动时间（tti）告诉咱们如何在导航和互动之间的时间长度。度量是经过查看初始内容呈现以后的前五个第二个窗口定义的，其中没有JavaScript任务花费的时间超过50毫秒。若是发生超过50ms的任务，则从新开始搜索五秒钟的窗口。所以，浏览器会首先假定它达到了交互性，只是为了切换到冻结状态，才最终切换回到交互式。
一旦咱们达到互动，咱们能够随时随地或随时随地启动应用程序的非必要部分。不幸的是，正如保罗·刘易斯（Paul Lewis）注意到的那样，框架一般没有优先级的概念能够提供给开发人员，所以大多数的库和框架都难以实现渐进式引导。若是你有时间和资源，就用这个策略来最终提高性能。
在全部性能优化的状况下，咱们常常没法控制来自业务需求的第三方脚本。第三方脚本指标不受最终用户体验的影响，所以单个脚本常常会被称为冗长的第三方脚本，从而毁掉了一个专门的性能工做。为了控制和缓解这些脚本带来的性能损失，只是将它们异步加载（可能经过延迟），并经过资源提示（如dns-prefetch或preconnect）加速它们是不够的。
正如yoav weiss在第三方脚本的必须讲话中所解释的，在许多状况下，这些脚本会下载动态资源。资源会在页面加载之间发生变化，因此咱们不必定知道哪些主机会从哪里下载资源，以及它们会是什么资源。
咱们有什么选择呢？考虑使用服务人员经过超时资源下载进行竞争，若是资源在必定超时内没有响应，则返回一个空的响应告诉浏览器进行解析页面。您还能够记录或阻止不成功或不符合特定条件的第三方请求。
另外一种选择是创建内容安全策略（csp）以限制第三方脚本的影响，例如，不容许下载音频或视频。最好的选择是经过<iframe>嵌入脚本，以便脚本在iframe的上下文中运行，所以不能访问页面的dom，也不能在你的域上运行任意代码。能够使用sandbox属性进一步限制iframe，所以能够禁用iframe能够执行的任何功能，例如，阻止脚本运行，防止警报，表单提交，插件，访问顶部导航等等。
例如，可能须要容许脚本使用<iframe sandbox =“allow-scripts”>来运行。每一个限制均可以经过沙盒属性上的各类容许值来提升（几乎在任何地方都支持），所以限制它们应该容许的最小限度。考虑使用安全框架和交叉口观察员;这样能够使广告在发生事件或获取他们所须要的信息（例如广告可见度）的同时进行iframed。注意新的策略，例如功能策略，资源大小限制和CPU /带宽优先级，以限制会使浏览器速度变慢的有害Web功能和脚本。同步脚本，同步xhr请求，document.write和过期的实现。
对第三方进行压力测试，在devtools的性能配置文件页面中检查自下而上的摘要，测试若是请求被阻止或超时，会发生什么状况-对于后者，能够使用webpagetest的黑洞服务器72.66.115.13您的主机文件中的特定域。最好是自主主机，并使用单个主机名，但也会生成一个请求映射，显示第四方调用并检测脚本什么时候更改。
仔细检查过时，缓存控制，最大年龄和其余http缓存头已被正确设置。通常而言，资源应该能够在很短的时间内（若是它们可能改变）或无限期地（若是它们是静态的）缓存-只要须要的时候就能够在url中更改它们的版本。禁用最后修改的标题，由于任何资产都会致使带有if-modified-since-header的条件请求，即便资源在高速缓存中也是如此。与etag同样，尽管它有其用途。
使用缓存控制：不可变的，为指纹静态资源设计，以免从新验证（截至2017年12月，在firefox，边缘和safari中支持;在Firefox中只支持https：//事务）。您能够使用heroku的http缓存标题，jake archibald的“缓存最佳实践”和ilya grigorik的http缓存入门指南。另外，要当心不一样的头文件，特别是与cdns相关的文件，而且要注意关键头文件，这有助于避免每当新的请求与先前的请求略有不一样时进行验证的额外往返
在2015年，谷歌推出了brotli，一种新的开源无损数据格式，如今全部的浏览器都支持这种格式。在实践中，brotli彷佛比gzip和deflate更有效。压缩速度可能很是慢，具体取决于设置，但较慢的压缩将最终致使较高的压缩率。不过，它解压的速度很快。
只有当用户经过https访问网站时，浏览器才会接受。有什么收获？brotli如今还不能在某些服务器上预装，并且在没有自编译nginx或ubuntu的状况下安装并不简单。不过，这并不难。事实上，一些cdns支持它，甚至能够启用brotli，即便在不支持它的cdns（与service worker）。
在最高级别的压缩，brotli是如此之慢以致于任何潜在的文件大小增益均可能被服务器开始发送响应所需的时间所抵消，由于它等待动态压缩资源。与静态压缩，可是，更高的压缩设置是首选）。
或者，您能够考虑使用zopfli的压缩算法，该算法将数据编码为deflate，gzip和zlib格式。任何常规的gzip压缩资源都将受益于zopfli改进的deflate编码，由于这些文件比zlib的最大压缩率要小3％到8％。遇上是文件将须要约80倍的时间来压缩。这就是为何使用zopfli是一个好主意，这种资源不会有太大的变化，这些文件被设计为被压缩一次并下载不少次。
若是您能够绕过动态压缩静态资产的成本，那么这是值得的。brotli和zopfli均可以用于任何明文有效载荷- html，css，svg，javascript等等。
战略？在最高级别使用brotli + gzip预压缩静态资产，并在1-4级别使用brotli快速压缩（动态）html。另外，请检查cdns上的brotli支持（例如，keycdn，cdn77，快速）。确保服务器正确处理brotli或gzip的内容协商。若是您不能在服务器上安装/维护brotli，请使用zopfli。
尽量使用具备srcset，大小和<picture>元素的响应图像。而你也能够经过使用<picture>元素和jpeg后备（参见andreas bovens的代码片断）提供webp图像，或者经过使用webp格式（即将在chrome，opera，firefox中支持）使用内容协商（使用接受标题）。
草图自己支持webp，webp图像能够从photoshop使用webp插件为photoshop导出。其余选项也可用。若是您使用的是wordpress或者joomla，那么有扩展能够帮助您轻松实现对webp的支持，好比WordPress的optimus和cache enabler以及joomla本身支持的扩展（经过cody arsenault）。
您还能够使用客户端提示，但仍须要得到一些浏览器支持。没有足够的资源来烘焙复杂的标记响应图像？使用响应式图像断点生成器或诸如cloudinary之类的服务来自动化图像优化。并且，在许多状况下，单独使用srcset和size将会得到显着的好处。
在粉碎杂志上，咱们使用postfix -opt做为图片名称，例如，brotli-compression-opt.png;每当图像包含该后缀时，团队中的每一个人都知道图像已经被优化。
当你在一个登录页上工做时，一个特定的图像加载速度很是快，确保jpeg是渐进式的，而且使用熟练的，mozjpeg（经过操纵扫描级来改善开始渲染时间）或者guetzli，google的new关注感知性能的开源编码器，以及利用zopfli和webp的学习。惟一的缺点是处理速度慢（每百万像素一分钟的cpu）。对于PNG，咱们能够使用pingo，而svg或svgomg svg。
每个图像优化的文章将陈述它，但保持矢量资产清洁和紧张老是值得提醒。确保清理未使用的资源，删除没必要要的元数据，并减小图稿中的路径点数量（所以svg代码）。
到目前为止，这些优化只包含基础知识。addy osmani已经发布了一个很是详细的基本图像优化指南，深刻到图像压缩和颜色管理的细节。例如，您能够将图像中没必要要的部分弄模糊（经过对其应用高斯模糊滤镜）以减少文件大小，最终甚至能够开始移除颜色或将图像变成黑白，以进一步缩小尺寸。对于背景图像，从0到10％质量的photoshop输出照片也是绝对能够接受的。
GIF呢？好，而不是加载影响渲染性能和带宽的繁重动画gif，咱们可能会使用循环的html5视频，但浏览器的性能是缓慢的<video>和图像不一样，浏览器不会预载<video>内容。至少咱们能够添加有损压缩gif gifs，gifsicleor giflossy的有损压缩。
好消息：但愿很快咱们能够使用<img src =“。mp4”>加载视频，早期的测试显示img标签显示的速度比gif快20倍，解码速度比gif快7倍。文件大小的一小部分。
还不够好？好吧，您还能够使用多种背景图像技术提升图像的感知性能。请记住，玩弄对比度和模糊没必要要的细节（或消除颜色）能够减小文件大小。啊，你须要放大一个小照片，而不会丢失质量？考虑使用letsenhance.io。
第一个问题值得问一下，若是你能摆脱首先使用ui系统字体。若是状况并不是如此，那么所提供的网络字体可能包括字形和额外的特征以及未被使用的权重。若是您使用的是开源字体（例如，经过仅包含拉丁字母和一些特殊的重音字形）来最大限度地减少文件大小，则能够向类型代工厂询问Web字体子集或本身的子集。
woff2的支持很是好，你能够使用woff和otf做为不支持它的浏览器的后备。另外，从zach leatherman的“全面的字体加载策略指南”（代码片断也能够做为网页字体加载食谱）中选择一种策略，并使用service worker缓存持久地缓存字体。须要一个快速的胜利？像素的ambacht有一个快速的教程和案例研究，让您的字体顺序。
若是您没法从服务器提供字体并依赖于第三方主机，请确保使用字体加载事件（或Web浏览器不支持的字体加载器）。fout比fuit好;当即开始在回退中渲染文本，并异步加载字体-你也能够使用loadcss。你也许可以摆脱本地安装的os字体，或者使用变得愈来愈引人注目的可变字体。
什么会使一个防弹字体加载策略？从字体显示开始，而后回退到字体加载api，而后回到bram stein的字体观察者。若是你有兴趣从用户的角度来衡量字体加载的性能，andreas marschke探索字体api和usertiming api的性能跟踪。
另外，不要忘记包含font-display：用于弹性和快速字体回退的可选描述符，用于将较大的字体分解为较小的特定于语言的字体的unicode范围，以及用于减小干扰的monica dinculescu的字体样式匹配器因为两种字体之间的尺寸差别，因此布局移位。
当用户请求页面时，浏览器读取html并构造dom，而后获取css并构建cssom，而后经过匹配dom和cssom生成一个渲染树。若是有任何JavaScript须要解决，浏览器将不会开始渲染页面直到解决，从而延迟渲染。做为开发者，咱们必须明确地告诉浏览器不要等待并开始渲染页面。为脚本执行此操做的方法是使用html中的延迟和异步属性。
在实践中，事实证实，咱们应该更喜欢按照异步方式进行（对于包括版本9在内的Internet Explorer用户来讲是有代价的，由于您可能会为其分配脚本）。一样，如上所述，限制第三方库和脚本的影响，特别是使用社交分享按钮和<iframe>嵌入（如地图）。大小限制能够帮助你防止JavaScript库膨胀：若是你不当心添加了一个大的依赖项，工具会通知你，并抛出一个错误。您能够使用静态社交分享按钮（例如经过ssbg）和静态连接来交互式地图。
若是您须要延迟加载图片，视频，广告脚本，a / b测试脚本或任何其余资源，则能够使用闪亮的新的交叉点观察者api，它提供了一种方法来异步观察目标元素与祖先元素或顶层文档的视口。基本上，你须要建立一个新的接口服务器对象，它接收一个回调函数和一组选项。而后咱们添加一个目标来观察。
当目标变得可见或不可见时执行回调函数，因此当它拦截视口时，能够在元素变得可见以前开始采起一些行动。实际上，咱们能够经过rootmargin（根边缘）和阈值（单个数字或一个数字数组，指示咱们瞄准的目标的可见性的百分比），对观察者的回调进行细粒度控制。alejandro garcia anglada发表了一个关于如何实际执行它的方便的教程。
您甚至能够经过向您的网页添加渐进式图片加载来将其提高到新的水平。相似于Facebook，pinterest和中等，你能够先加载低质量，甚至模糊的图像，而后随着页面的不断加载，使用ldip（低质量图像占位符）技术提出的所有质量版本替换它们，由家伙podjarny。若是技术提升了用户体验，意见就不同，可是它确定会缩短第一次有意义的会话的时间。咱们甚至能够经过使用sqip建立图像的低质量版本做为svg占位符来实现自动化。这些占位符能够被嵌入在HTML中，由于它们天然地用文本压缩方法压缩。在他的文章中，dean hume描述了如何使用交集观察者来实现这个技术。
浏览器支持？体面，与铬，火狐，边缘和三星互联网正在船上。webkit状态目前正在开发中。倒退？若是咱们不支持交叉点观察者，咱们仍然能够延迟加载一个polyfill或当即加载图像。甚至还有一个图书馆。
通常来讲，懒惰加载全部昂贵的组件，如字体，JavaScript，轮播，视频和iframe是一个好主意。您甚至能够根据有效的网络质量调整内容服务。网络信息api，特别是navigator.connection.effectivetype（chrome 62+）使用rtt和下行链路值来更准确地表示链接和用户能够处理的数据。您能够使用它来彻底删除视频自动播放，背景图片或Web字体，以便链接速度太慢。
为了确保浏览器尽快开始渲染页面，一般会收集开始渲染页面第一个可见部分所需的全部CSS（称为“critical css”或“fold-up-fold css“）并将其内联添加到页面的<head>中，从而减小往返。因为在慢启动阶段交换包的大小有限，您的关键CSS的预算大约是14 kb。
若是超出这个范围，浏览器将须要额外往返取得更多样式。关键和关键使你可以作到这一点。您可能须要为您使用的每一个模板执行此操做。若是可能的话，考虑使用灯丝组使用的条件内联方法。
与http / 2，关键的CSS能够存储在一个单独的CSS文件，并经过服务器推送传递而不会膨胀的HTML。问题在于服务器推送是很麻烦的，在浏览器上有许多问题和竞争条件。它一直不被支持，并有一些缓存问题（参见hooman beheshti的介绍幻灯片114）。事实上，这种影响多是负面的，并使网络缓冲区膨胀，从而防止文档中的真实帧被传送。另外，因为tcp缓慢启动，彷佛服务器推送在热链接上更加有效。
即便使用http / 1，将关键的css放在根域上的一个单独的文件中也是有好处的，有时甚至比缓存中的内联还要多。chrome推测性地打开第二个http链接到根域当请求页面，这消除了须要一个tcp链接来获取这个css。
有几点须要记住：不像preload能够触发任何域的预加载，你只能从你本身的域或你所受权的域中推送资源。只要服务器从客户端得到第一个请求，就能够启动它。服务器将资源压入推送缓存，并在链接终止时被删除。可是，因为http / 2链接能够在多个选项卡之间重复使用，所以推送的资源也能够被来自其余选项卡的请求声明。
目前尚未简单的方法让服务器知道被推送的资源是否已经存在于用户的缓存中，所以资源会随着每一个用户的访问而不断被推送。因此，你可能须要建立一个缓存感知的http / 2服务器推送机制。若是获取，您能够尝试从缓存中获取它们，以免辅助服务器被彻底推送。但请记住，新的缓存摘要规范否认了手动构建这种“缓存感知”服务器的必要性，基本上在http / 2中声明了一个新的帧类型来传递缓存中已经存在的主机名。所以，它对于cdns也可能特别有用。
对于动态内容，当服务器须要一些时间来生成响应时，因为浏览器不知道页面可能引用的任何子资源，所以没法提出任何请求。对于这种状况，咱们能够预热链接并增长TCP拥塞窗口大小，以便未来的请求能够更快地完成。并且，全部内嵌的资产一般都是推荐服务器的好选择。事实上，inien parameshwaran作了一个比较http / 2推与http预加载的显着的研究，这是一个很棒的阅读与全部你可能须要的细节。服务器推或不服务器推？科林·贝德尔我应该推？可能会指出你在正确的方向。
底线：正如sam saccone所说，预加载对于将资源的开始下载时间更接近初始请求是有利的，而服务器推送对于截取完整的RT（或更多，取决于服务器的思考时间）是好的-若是你有一个service worker，以防止没必要要的推进，也就是说。
常常被遗忘和忽略，流为读取或写入异步数据块提供了一个接口，在任何给定的时间内，只有一部分数据可能在内存中可用。基本上，只要第一个数据块可用，它们就容许原始请求的页面开始处理响应，并使用针对流进行优化的解析器逐步显示内容。
咱们能够从多个来源建立一个流。例如，而不是服务一个空的UI壳，并让JavaScript填充它，您可让service worker构建一个流，其中壳来自缓存，但身体来自网络。正如jeff posnick指出的那样，若是您的web应用由cms支持，那么服务器经过将部分模板拼接在一块儿来呈现html，该模型直接转换为使用流式响应，模板逻辑在service worker而不是服务器中复制。杰克archibald的网络流年的文章突出了如何，你能够创建它。性能提高至关明显。流式传输整个html响应的一个重要优点是，在初始导航请求期间呈现的html能够充分利用浏览器的流式html解析器。在页面加载以后插入到文档中的html块（与经过javascript填充的内容同样常见）没法利用此优化。
浏览器支持？到达那里与铬52 +，火狐57 +（旗后），Safari和边缘支持API和service worker在全部现代浏览器支持。
特别是在新兴市场工做时，您可能须要考虑优化用户选择数据节省的体验。保存数据客户端提示请求头容许咱们将应用程序和有效载荷定制为成本和性能受限的用户。实际上，您能够将高dpi图像的请求重写为低dpi图像，删除网页字体和幻想视差效果，关闭视频自动播放，服务器推送，甚至改变如何传递标记。
目前只支持在铬版本，chrome的android版本或桌面设备上的数据保护程序扩展。最后，您还能够使用服务人员和网络信息api根据网络类型提供低/高分辨率的图像。
使用资源提示在dns-prefetch（在后台执行dns查找）上节省时间，preconnect（要求浏览器在后台启动链接握手（dns，tcp，tls）），prefetch（要求浏览器请求资源）和预加载（预取资源而不执行它们等等）。如今大多数时候，咱们至少要使用preconnect和dns-prefetch，并且咱们会谨慎使用prefetch和preload。只有在您对下一个用户须要的资产很是有信心（例如，在购买渠道中）时才应该使用前者。注意prerender已被弃用，再也不支持。请注意，即便使用preconnect和dns-prefetch，浏览器也会限制其查看/链接的主机数量，所以，根据优先级排序（感谢philip！）是安全的。实际上，使用资源提示多是提升性能的最简单的方法，并且确实效果不错。何时用什么？正如Addy osmani解释的那样，咱们应该预先加载咱们有信心在当前页面中使用的资源。可能用于跨多个导航边界的将来导航的预取资源，例如，还没有访问的网页所需的webpack包。addy关于在chrome中加载优先级的文章显示了chrome如何解释资源提示，因此一旦你决定了哪些资源对于渲染相当重要，你能够给它们赋予高优先级。看你的请求是如何优先的，你能够在chrome devtools网络请求表（以及Safari浏览器技术预览）中启用“优先级”列。
例如，因为字体一般是页面上的重要资源，所以请求浏览器使用预加载下载字体老是一个好主意。你也能够动态加载JavaScript，有效的延迟加载执行。另外，因为<link rel =“preload”>接受媒体属性，因此您能够选择基于@media查询规则选择资源的优先级。
须要注意的一点是：预加载能够使资产的开始下载时间更接近初始请求，可是预加载的资产会落在与发出请求的页面相关的内存缓存中。这意味着预加载的请求不能在页面之间共享。另外，预加载能够很好地与http缓存配合使用：若是该项目已经存在于http缓存中，则永远不会发送网络请求。
所以，它对晚期发现的资源，经过背景图像加载的英雄图像，内联关键的css（或javascript）以及预加载其他的css（或javascript）是有用的。另外，预加载标签只能在浏览器从服务器收到html而且先行分析器已经找到预加载标签以后才能启动预加载。因为咱们不等待浏览器解析html来启动请求，因此经过http头部进行预加载要快一些。早期的提示将有助于进一步的实现，即便在发送html的响应头文件以前，也能够预加载。
注意：若是您使用预加载，必须定义或不加载任何内容，加上预加载的字体（不带crossorigin属性）将会双重提取。
用css遏制隔离昂贵的组件-例如，限制浏览器样式的范围，用于非画布导航的布局和会话工做或第三方小部件的范围。请确保在滚动页面或动画元素时不会出现滞后现象，而且始终每秒触及60帧。若是这是不可能的，那么至少使每秒帧数是一致的，最好是60到15之间的混合范围。使用css'will-change来通知浏览器哪些元素和属性会改变。
还要测量运行时渲染性能（例如，在devtools中）。开始吧，查看paul lewis关于浏览器渲染优化的免费udacity课程以及emily hayman关于高性能网页动画和交互的文章。
咱们还获得了一个由sergey chikuyonok撰写的关于如何得到gpu动画的文章。快速提示：对gpu合成图层的更改是最便宜的，因此若是只经过不透明度和变换触发合成，就能够走上正轨。
尽管组件在网页上的显示顺序以及咱们如何为浏览器提供资源的策略，但咱们也不该低估感知性能的做用。这个概念处理等待的心理方面，基本上保持客户忙碌或从事其余事情正在发生。那就是感知管理，抢先发动，提早完成和宽容管理的地方。
这是什么意思呢？在加载资产的同时，咱们能够老是领先于客户，因此在后台发生不少事情的时候，体验会很快。为了保持客户的参与，咱们能够使用框架屏幕（实现演示），而不是加载指标，添加转换/动画，基本上在没有更多优化的时候欺骗用户。
随着谷歌走向一个更安全的网络，并最终将全部的http页面做为“不安全”的铬页面处理，切换到http / 2环境是不可避免的。http / 2支持得很是好;它不会去任何地方;并且在大多数状况下，你最好用它。一旦在https上运行，您能够经过服务人员和服务器推送（至少是长期的）来得到重大的性能提高。
最耗时的任务是迁移到https，而且根据您的http / 1.1用户群（即，在传统操做系统上的用户或旧版浏览器中的用户）的大小，您必须发送一个不一样的版本传统的浏览器性能优化，这将须要您适应不一样的构建过程。注意：设置迁移和新的构建过程可能会很是棘手和耗时。对于本文的其他部分，我假设你要么切换到或已经切换到http / 2。
再次，经过http / 2服务资产须要对目前服务资产的部分检查。您须要在打包模块和并行加载许多小模块之间找到一个很好的平衡点。在一天结束的时候，最好的要求仍是没有要求，可是目标是在资产的快速交付和缓存之间找到一个很好的平衡点。
一方面，您可能但愿避免将资源彻底并置，而将整个界面分解为许多小模块，将其做为构建过程的一部分进行压缩，经过“侦察”方法引用它们并将其并行加载。一个文件中的更改将不须要从新下载整个样式表或JavaScript。它也最大限度地减小了解析时间，并保持单个页面的有效负载低。
另外一方面，包装仍然很重要。首先，压缩会受到影响。一个大包的压缩将受益于字典重用，而小的单独包不会。有标准的工做来解决这个问题，但如今已经很远了。其次，浏览器还没有针对此类工做流进行优化。例如，chrome将触发与资源数量成线性关系的进程间通讯（ipcs），所以包含数百个资源将会产生浏览器运行时成本。
仍然能够尝试逐渐加载css。显然，经过这样作，您正在主动惩罚http / 1.1用户，因此您可能须要为不一样的浏览器生成不一样的构建，并将其做为部署过程的一部分，这就是事情稍微复杂的地方。你能够用http / 2链接合并，这容许你使用域分片，而从http / 2中受益，可是在实践中实现这一点是困难的。
该怎么办？若是你运行的是http / 2，发送大约6-10个包彷佛是一个体面的妥协（对传统的浏览器来讲也不算太坏）。实验和测量，以找到适合您的网站的平衡。
不一样的服务器和cdns可能会不一样地支持http / 2。使用很快呢？检查您的选项，或快速查看您的服务器如何执行以及您但愿支持哪些功能。
经过在你的服务器上启用ocsp装订，你能够加快你的tls握手。在线证书状态协议（ocsp）被建立为证书撤销列表（crl）协议的替代方案。这两种协议都用来检查一个ssl证书是否被吊销。然而，ocsp协议并不要求浏览器花费时间下载，而后在列表中搜索证书信息，所以减小了握手所需的时间。
因为咱们的ipv4空间不足，主要的移动网络正在迅速采用ipv6（美国的ipv6采用率达到了50％），所以将DNS更新为ipv6是一个不错的主意，以保证将来的发展。只要确保在整个网络上提供双栈支持-它容许ipv6和ipv4同时并行运行。毕竟，ipv6不是向后兼容的。另外，研究代表，因为邻居发现（ndp）和路由优化，ipv6使这些网站速度提升了10％到15％。
若是您使用的是http / 2，请仔细检查您的服务器是否为http响应头实施了hpack压缩，以减小没必要要的开销。因为http / 2服务器比较新，因此可能不彻底支持这个规范，以hpack为例。h2spec是一个伟大的（若是技术上很是详细）的工具来检查。hpack的做品。
http / 2的全部浏览器实现都运行在tls上，所以您可能但愿避免安全警告或网页上的某些元素没法正常工做。仔细检查您的安全标头设置是否正确，消除已知的漏洞并检查您的证书。另外，请确保全部外部插件和跟踪脚本都经过https加载，不能跨站点脚本，而且http严格传输安全性标头和内容安全策略标头都已正确设置。
网络上的性能优化不会比本地存储在用户机器上的缓存更快。若是您的网站是经过https运行的，请使用“服务人员的实用指南”将静态资产缓存到service worker缓存中，并存储离线回退（甚至是离线页面），并从用户的机器中检索它们，而不是去网络。还要检查jake的离线烹饪书和免费的udacity课程“离线网络应用程序”。浏览器支持？如上所述，它是普遍支持（铬，火狐，Safari浏览器，三星互联网，边缘17+）和后备是不管如何网络。它有助于提高性能吗？哦，是的，它的确如此。
在Chrome和Firefox测试是不够的。了解您的网站在代理浏览器和旧版浏览器中的工做方式。例如，uc浏览器和opera mini在亚洲市场份额很大（在亚洲高达35％）。测量您感兴趣的国家的平均互联网速度，以免大惊小怪。使用网络调节进行测试，并模拟高dpi设备。browserstack是太棒了，但也测试真实的设备。
有一个私人的网页测试实例老是有利于快速和无限的测试。不过，具备自动警报功能的连续监控工具可让您更详细地了解您的表现。设置您本身的用户时间标记来衡量和监控特定于业务的指标。
另外，考虑添加自动性能回归警报来监视随时间的变化。研究使用朗姆酒解决方案来监测性能随着时间的变化。对于相似自动化单元测试的负载测试工具，您能够使用k6及其脚本API。还要看速度追踪器，灯塔和口径。
这个列表是至关全面的，完成全部的优化可能须要至关长的一段时间。因此，若是你只有一个小时才能得到显着的改善，你会怎么作？让咱们把这一切都归结为10个低悬的水果。显然，在你开始以前，一旦你完成，测量的结果，包括3g和电缆链接开始渲染时间和speedindex。
1. 衡量现实世界的经验并设定适当的目标。一个好的目标是第一次有意义的会话<1秒，速度指数值<1250，交互时间<5秒慢3g，重复访问，tti <2s。优化开始渲染时间和交互时间。
2. 准备主要模板的关键CSS，并将其包含在页面的<head>中。（你的预算是14 kb）。对于css / js，在最大的关键文件大小预算内运行。170KB gzipped（0.8-1mb解压缩）。
3. 延迟和延迟加载尽量多的脚本，包括您本身的脚本和第三方脚本，尤为是社交媒体按钮，视频播放器和昂贵的JavaScript。
4. 经过更快的dns-lookup，preconnect，prefetch和preload，添加资源提示来加速交付。
5. 子集Web字体并加载它们（或者只是切换到系统字体）。
6. 优化图像，并考虑使用webp的关键页面（如登录页）。
7. 检查http缓存头和安全头是否设置正确。
8. 在服务器上启用brotli或zopfli压缩。（若是这是不可能的，不要忘记启用gzip压缩。）
9. 若是http / 2可用，则启用hpack压缩并开始监视混合内容警告。若是您正在运行lts，还能够启用ocsp装订。
10. 缓存资源，如字体，样式，JavaScript和图像-实际上，尽量！-在service worker缓存中。
考虑到这个清单，你应该准备好任何类型的前端性能项目。请随意下载清单的打印准备pdf以及一个可编辑的苹果页面文档，以根据您的需求定制清单：
l 下载清单pdf（pdf，0.129 mb）
l 在苹果页面下载清单（.pages，0.236 mb）
若是您须要替代品，您也能够经过dan rublic查看前端清单以及jon yablonski的“设计师网站性能清单”。
一些优化可能超出了你的工做或预算的范围，或者可能只是由于你必须处理的遗留代码而被过分杀伤。不要紧！使用这个清单做为通常（并但愿全面）指南，并建立适用于您的上下文的问题列表。但最重要的是，在优化以前测试并测量您本身的项目以肯定问题。2018年快乐的表现结果，每一个人！
很是感谢podjarny，yoav weiss，addy osmani，artem denysov，denys mishunov，ilya pukhalski，jeremy wagner，colin bendell，mark zeman，patrick meenan，leonardo losoviz，andy davies，rachel andrew，anselm hannemann，patrick hamann，andydavies，tim kadlec，rey bango，matthias ott，mariana peralta，philipp tellis，ryan townsend，mohamed hussain sh，jacobgroß，tim swalling，bob visser，kev adamson，aleksey kulikov和rodney rehm评论这篇文章，还有咱们的精彩的社区，分享了它在性能优化方面的技巧和经验教训，供你们使用。你真的粉碎！