前端性能优化清单

原文地址：https://www.smashingmagazine.com/2018/01/front-end-performance-checklist-2018-pdf-pages/

前端性能优化清单

性能很重要——我们都知道。但是，我们是否真的总是知道我们的性能瓶颈究竟是什么？是昂贵的JavaScript，慢Web字体传递，沉重的图像，或缓慢渲染？是否值得借助交叉口观察员，客户提示，css遏制，HTTP / 2和service worker探索摇树优化，范围提升，代码分割以及所有的花式加载模式？最重要的是，我们从哪里开始提高绩效，如何建立一个长期的绩效文化？

早些时候，性能往往只是事后才想到的。通常推迟到项目的最后，这将归结为缩小，串联，资产优化和可能在服务器的配置文件上的一些细微的调整。现在回头看，事情似乎已经发生了相当大的变化。

性能不仅仅是一个技术问题：它很重要，而且在将其引入到工作流程中时，必须通过性能影响来告知设计决策。性能必须不断测量，监控和改进，网络日益复杂的挑战使得很难跟踪指标，因为指标会因设备，浏览器，协议，网络类型和延迟而显着变化（cdns，isps，缓存，代理，防火墙，负载均衡器和服务器都在性能中发挥作用）。

所以，如果我们在提高性能的时候创建了所有事情的概述，从流程的开始到网站的最终发布，这个列表会是什么样的？下面你会发现2018年的一个（希望是公正的，客观的）前端性能检查清单——你可能需要考虑的问题的概述，以确保你的响应时间快，用户交互顺畅，你的网站不流失用户的带宽。

1、做好准备：计划和指标

微观优化对于保持业绩的顺利进行是非常重要的，但是要明确定义目标是至关重要的——可衡量的目标会影响整个过程中做出的任何决策。有几种不同的模型，下面讨论的模型都是很有见地的——只要确保尽早设置自己的优先级。

1.1、建立一种性能文化（1）

在许多组织中，前端开发人员确切知道哪些常见的底层问题以及应该使用何种加载模式来修复这些问题。但是，只要开发/设计和营销团队之间没有一致，绩效就不会长期持续下去。研究客户服务中常见的抱怨，看看提高性能如何帮助解决这些常见问题。

运行性能实验并测量结果 -无论是在移动设备上还是在桌面上。它将帮助您建立一个公司量身定制的案例研究与真实的数据。此外，使用来自wpo统计信息发布的案例研究和实验的数据可以帮助提高业务对于性能至关重要的敏感性，以及它对用户体验和业务指标的影响。说虽然单靠表演是不够的，你还需要建立一些可衡量和可追踪的目标并观察它们。

1.2、目标：至少比最快的竞争对手快20％（2）

根据心理学研究，如果你希望用户觉得你的网站比竞争对手的网站快，你至少要快20％。研究你的主要竞争对手，收集他们如何在移动和桌面上执行的指标，并设置阈值，将帮助你超越他们。为了获得准确的结果和目标，首先要研究你的分析，看看你的用户在哪里。那么你可以模仿第90百分位的测试经验。收集数据，建立电子表格，削减20％，并以这种方式设定你的目标（即绩效预算）。现在你有一些可以测试的东西。

如果你在考虑预算的情况下，尽量减少最小的脚本以便快速交互，那么你就处于一个合理的路径上。lara hogan关于如何用性能预算来处理设计的指南可以为设计人员提供有用的指针，而性能预算计算器和浏览器卡路里都可以帮助创建预算。

超出绩效预算，考虑对您的业务最有利的关键客户任务。设定和讨论关键行动的可接受的时间阈值，并建立整个组织已经同意的“准备就绪”的用户时间标记。在许多情况下，用户旅程将涉及许多不同部门的工作，因此，按照可接受的时间安排将有助于支持或阻止下一步的业绩讨论。确保额外的资源和功能的额外成本可见和理解。

另外，正如帕特里克·梅南（patrick meenan）所建议的那样，在设计过程中计划一个装载顺序和权衡是值得的。如果您尽早优先考虑哪些部分更为重要，并确定它们应该出现的顺序，您也将知道什么可以推迟。理想情况下，该顺序也将反映您的CSS和JavaScript导入的顺序，所以在构建过程中处理它们将更容易。当页面被加载时（例如当网页字体没有被加载时），考虑“中间”状态下的视觉体验应该是什么。

计划，计划，计划。可能很早就进入快速优化的阶段，并且最终可能成为快速获胜的一个好策略 -但是如果没有规划和现实的公司规划，量身定制的表现目标。

1.3、选择正确的指标（3）

不是所有的指标都同样重要。研究哪些指标对于您的应用程序最为重要：通常，这与您能够以多快的速度开始渲染最重要的像素（以及它们是什么）有关，以及为这些渲染的像素提供输入响应速度的速度。这些知识将为您持续努力提供最佳的优化目标。这样或者那样，而不是专注于整个页面加载时间（例如通过onload和domcontentloaded计时），优先考虑您的客户感知的页面加载。这意味着要关注一组稍微不同的指标。实际上，选择正确的指标是一个没有明显优势的过程。

以下是一些值得考虑的指标：

l 第一个有意义的油漆（fmp，当主要内容出现在页面上），

l 英雄渲染时间（当页面的重要内容完成渲染时），

l 交互的时间（tti，布局已经稳定的点，关键字体是可见的，并且主线程足以处理用户输入-基本上是用户可以点击ui并与之交互的时间标记），

l 输入响应性（界面响应用户操作需要多少时间），

l 知觉速度指数（测量页面内容的可视化速度有多快;得分越低越好），

l 您的自定义指标，由您的业务需求和客户体验所定义。

steve souders有每个指标的详细解释。而在许多情况下，tti和输入响应将是最关键的，这取决于您的应用程序的上下文，这些度量可能有所不同：例如，对于netflix电视用户来说，键盘输入响应能力，内存使用情况和tti更为重要。

1.4、收集代表观众的设备上的数据（4）

为了收集准确的数据，我们需要彻底选择要测试的设备。选择一个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有交互问题。

1.5、与同事分享清单（5）

确保清单对您的团队中的每个成员都很熟悉，以避免误解。每个决策都有性能影响，项目将从前端开发人员获得巨大收益，将整个团队的绩效价值正确地传达给每个人，这样每个人都会为此感到责任，而不仅仅是前端开发人员。根据绩效预算和清单中定义的优先顺序制定设计决策。

2、设定切实的目标

2.1、100毫秒响应时间，60 fps（6）

为了使交互感觉平滑，界面有100ms响应用户的输入。任何更长的时间，用户觉得应用程序laggy。轨道，一个以用户为中心的性能模型为您提供了健康的目标：为了允许<100毫秒的响应，页面必须在每个<50毫秒后最迟将控制权交还给主线程。估计输入延迟告诉我们，如果我们正在达到这个门槛，理想情况下，它应该低于50ms。对于像动画这样的高压点，最好不要在别的地方做任何事情，在绝对的最小的地方做不到的地方。

而且每帧动画应该在16毫秒内完成，从而达到每秒60帧（1秒÷60 = 16.6毫秒） -最好在10毫秒以下。因为浏览器需要时间将新框架绘制到屏幕上，您的代码应该在达到16.6毫秒之前完成执行。乐观，明智地使用空闲时间。显然，这些目标适用于运行时性能，而不是加载性能。

2.2、速度指数<1250，tg <3s，关键文件大小预算<170kb（7）

尽管实现起来可能非常困难，但是一个好的最终目标将是在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这样的工具可以帮助您控制预算，并且可以集成到构建过程中。

3、定义环境

3.1、选择并设置您的构建工具（8）

不要太在意这些天过得好酷的东西。坚持你的环境来建设，无论是咕噜咕噜，喝咖啡，webpack，包裹，或工具的组合。只要你得到的结果你需要快速，你没有任何问题，维护你的构建过程，你做得很好。

3.2、逐步增强（9）

保持逐步增强作为前端架构和部署的指导原则是一个安全的选择。先设计和构建核心体验，再用强大的浏览器的先进功能增强体验，创造灵活的体验。如果您的网站运行速度很慢，而且网页浏览器效果不佳，您的网页显示效果不佳，那么在网络不错的浏览器上运行速度会更快。

3.3、选择一个强大的性能基准（10）

有很多未知因素会影响加载 -网络，热调节，缓存驱逐，第三方脚本，解析器阻塞模式，磁盘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进行缓存和预先缓存资源，然后异步地延迟加载所需的路由。

3.4、你会使用AMP或即时文章么（11）

根据贵组织的优先级和策略，您可能需要考虑使用谷歌的放大器或Facebook的即时文章或苹果的苹果新闻。如果没有它们，你可以获得良好的性能，但是放大器确实提供了一个可靠的内容交付网络（cdn）的性能框架，而即时文章将提高你在Facebook上的知名度和性能。

这些技术对用户的主要好处是保证了性能，所以有时他们甚至可能更喜欢amp- / apple新闻/即时页面链接，而不是“普通”和可能膨胀的页面。对于处理大量第三方内容的内容较重的网站，这些选项可能会大大加速渲染时间。

网站所有者的利益是显而易见的：这些格式在各自的平台上的可发现性以及在搜索引擎中的可见度提高。你也可以建立一个渐进的网络放大器，通过重用amps作为你的pwa的数据源。下行？显然，在围墙花园中的存在使得开发者能够产生并保持其内容的单独版本，并且在即时文章和苹果消息的情况下没有实际的URL。

3.5、明智地选择你的cdn（12）

根据您拥有多少动态数据，您可能能够将某些部分内容“外包”到静态站点生成器，并将其推送到cdn并从中提供静态版本，从而避免数据库请求。你甚至可以选择一个基于cdn的静态托管平台，用交互式组件增强页面（jamstack）。

请注意，cdns也可以提供（和卸载）动态内容。所以，限制你的cdn到静态资产是没有必要的。仔细检查你的cdn是否执行压缩和转换（例如格式化，图像优化压缩和边缘调整），智能http / 2交付，边缘包括，在cdn的边缘组装页面的静态和动态部分（即离用户最近的服务器）以及其他任务。

4、构建优化

4.1、确定你的优先顺序（13）

首先知道你在处理什么是个好主意。运行所有资产（JavaScript，图像，字体，第三方脚本和页面上的“昂贵”模块，如轮播，复杂的信息图表和多媒体内容）的清单，并将其分组。设置一个电子表格。定义传统浏览器的基本核心体验（即完全可访问的核心内容），增强的功能强大的浏览器体验（即丰富的，完整的体验）和额外资源（不是绝对需要的，可以延迟加载的资源，例如网页字体，不必要的风格，旋转木马脚本，视频播放器，社交媒体按钮，大图像）。我们发表了一篇关于“提高粉丝杂志的表现”的文章，详细描述了这个方法。

4.2、考虑使用“切割芥菜”模式（14）

尽管相当古老，但我们仍然可以使用切割芥末技术将核心体验发送到传统浏览器，并增强现代浏览器的体验。在加载资源时要严格：加载核心体验，然后进行增强，然后加入额外的内容。请注意，该技术从浏览器版本中推导设备功能，这已经不是我们现在可以做的事了。例如，发展中国家的廉价Android手机大多运行Chrome，尽管其内存和CPU的能力有限，但仍将切断芥末。这就是prpl模式可以作为一个很好的选择。最终，使用设备内存客户端提示标题，我们将能够更可靠地定位低端设备。在写这篇文章的时候，头文件只能在眨眼的时候才支持（一般用于客户端提示）。由于设备内存也有一个已经在Chrome浏览器中可用的JavaScript API，一个选项可能是基于API的功能检测，并且只有在不受支持的情况下回退到“切割芥末”技术

4.3、解析JavaScript是昂贵的，所以保持小（15）

在处理单页面应用程序时，可能需要一些时间来初始化应用程序，然后才能呈现页面。寻找模块和技术来加速最初的渲染时间（例如，这里是如何调试反应性能，以及如何提高角度性能），因为大多数性能问题来自初始解析时间来引导应用程序。

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测量任何设备或浏览器上的解析和执行时间。底线：虽然规模很重要，但这不是一切。当脚本大小增加时，解析和编译时间不一定会线性增加。

4.4、你在使用提前编译器吗？（16）

使用提前编译器将一些客户端渲染卸载到服务器，从而快速输出可用的结果。最后，考虑使用optimize.js更快的初始加载，通过包装急切调用的函数（但可能不再需要）。

4.5、你在使用摇树优化，范围提升和代码分割吗？（17）

树形抖动是一种清理构建过程的方法，仅包含生产中实际使用的代码，并消除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负载。

4.6、利用你的目标JavaScript引擎的优化（18）

研究你的用户群中的JavaScript引擎占主导地位，然后探索优化它们的方法。例如，当在用于闪烁浏览器，node.js运行时和电子的v8优化时，利用脚本流来实现单片脚本。它允许异步或延迟脚本在下载开始后在单独的后台线程上解析，因此在某些情况下可将页面加载时间提高多达10％。实际上，在<head>中使用<script defer>，以便浏览器可以及早发现资源，然后在后台线程上解析它。

注意：歌剧迷不支持脚本延期，所以如果你正在开发印度或非洲，延迟将被忽略，导致阻塞渲染，直到脚本已被评估。

4.7、客户端渲染或服务器端渲染？（19）

在这两种情况下，我们的目标应该是设置逐步引导：使用服务器端渲染来获得快速的第一个有意义的绘制，但也包含一些最小的必要的JavaScript，以保持交互的时间接近第一个有意义的油漆。如果JavaScript在第一次有意义的绘制之后来得太迟，那么浏览器可能会在解析，编译和执行迟发现的javascript时锁定主线程，从而对站点或应用程序的交互性造成手铐。

为了避免它，总是把函数的执行分解成单独的异步任务，并且在可能的情况下使用requestidlecallback。考虑使用webpack的动态import（）支持延迟加载ui的部分，避免加载，解析和编译成本，直到用户真正需要它们。

在本质上，互动时间（tti）告诉我们如何在导航和互动之间的时间长度。度量是通过查看初始内容呈现之后的前五个第二个窗口定义的，其中没有JavaScript任务花费的时间超过50毫秒。如果发生超过50ms的任务，则重新开始搜索五秒钟的窗口。因此，浏览器会首先假定它达到了交互性，只是为了切换到冻结状态，才最终切换回到交互式。

一旦我们达到互动，我们可以随时随地或随时随地启动应用程序的非必要部分。不幸的是，正如保罗·刘易斯（Paul Lewis）注意到的那样，框架通常没有优先级的概念可以提供给开发人员，因此大多数的库和框架都难以实现渐进式引导。如果你有时间和资源，就用这个策略来最终提升性能。

4.8、你是否限制了第三方脚本的影响？（20）

在所有性能优化的情况下，我们经常无法控制来自业务需求的第三方脚本。第三方脚本指标不受最终用户体验的影响，因此单个脚本经常会被称为冗长的第三方脚本，从而毁掉了一个专门的性能工作。为了控制和缓解这些脚本带来的性能损失，只是将它们异步加载（可能通过延迟），并通过资源提示（如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您的主机文件中的特定域。最好是自主主机，并使用单个主机名，但也会生成一个请求映射，显示第四方调用并检测脚本何时更改。

4.9、http缓存头设置正确（21）

仔细检查过期，缓存控制，最大年龄和其他http缓存头已被正确设置。一般而言，资源应该可以在很短的时间内（如果它们可能改变）或无限期地（如果它们是静态的）缓存-只要需要的时候就可以在url中更改它们的版本。禁用最后修改的标题，因为任何资产都会导致带有if-modified-since-header的条件请求，即使资源在高速缓存中也是如此。与etag一样，尽管它有其用途。

使用缓存控制：不可变的，为指纹静态资源设计，以避免重新验证（截至2017年12月，在firefox，边缘和safari中支持;在Firefox中只支持https：//事务）。您可以使用heroku的http缓存标题，jake archibald的“缓存最佳实践”和ilya grigorik的http缓存入门指南。另外，要小心不同的头文件，特别是与cdns相关的文件，并且要注意关键头文件，这有助于避免每当新的请求与先前的请求略有不同时进行验证的额外往返

5、资产优化

5.1、brotli或zopfli纯文本压缩在使用中？（22）

在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。

5.2、图像是否正确优化？（23）

尽可能使用具有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;每当图像包含该后缀时，团队中的每个人都知道图像已经被优化。

5.3、将图像优化提升到一个新的水平（24）

当你在一个登陆页上工作时，一个特定的图像加载速度非常快，确保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。

5.4、网页字体是否优化？（25）

第一个问题值得问一下，如果你能摆脱首先使用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的字体样式匹配器由于两种字体之间的尺寸差异，所以布局移位。

6、交付优化

6.1、你限制的JavaScript库的影响，并加载它们异步？（26）

当用户请求页面时，浏览器读取html并构造dom，然后获取css并构建cssom，然后通过匹配dom和cssom生成一个渲染树。如果有任何JavaScript需要解决，浏览器将不会开始渲染页面直到解决，从而延迟渲染。作为开发者，我们必须明确地告诉浏览器不要等待并开始渲染页面。为脚本执行此操作的方法是使用html中的延迟和异步属性。

在实践中，事实证明，我们应该更喜欢按照异步方式进行（对于包括版本9在内的Internet Explorer用户来说是有代价的，因为您可能会为其分配脚本）。同样，如上所述，限制第三方库和脚本的影响，特别是使用社交分享按钮和<iframe>嵌入（如地图）。大小限制可以帮助你防止JavaScript库膨胀：如果你不小心添加了一个大的依赖项，工具会通知你，并抛出一个错误。您可以使用静态社交分享按钮（例如通过ssbg）和静态链接来交互式地图。

6.2、你是懒惰加载与交叉口观察员昂贵的脚本？（27）

如果您需要延迟加载图片，视频，广告脚本，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字体，以便连接速度太慢。

6.3、你快速推动关键的CSS？（28）

为了确保浏览器尽快开始渲染页面，通常会收集开始渲染页面第一个可见部分所需的所有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，以防止不必要的推动，也就是说。

6.4、你有回应吗？（29）

经常被遗忘和忽略，流为读取或写入异步数据块提供了一个接口，在任何给定的时间内，只有一部分数据可能在内存中可用。基本上，只要第一个数据块可用，它们就允许原始请求的页面开始处理响应，并使用针对流进行优化的解析器逐步显示内容。

我们可以从多个来源创建一个流。例如，而不是服务一个空的UI壳，并让JavaScript填充它，您可以让service worker构建一个流，其中壳来自缓存，但身体来自网络。正如jeff posnick指出的那样，如果您的web应用由cms支持，那么服务器通过将部分模板拼接在一起来呈现html，该模型直接转换为使用流式响应，模板逻辑在service worker而不是服务器中复制。杰克archibald的网络流年的文章突出了如何，你可以建立它。性能提升相当明显。流式传输整个html响应的一个重要优势是，在初始导航请求期间呈现的html可以充分利用浏览器的流式html解析器。在页面加载之后插入到文档中的html块（与通过javascript填充的内容一样常见）无法利用此优化。

浏览器支持？到达那里与铬52 +，火狐57 +（旗后），Safari和边缘支持API和service worker在所有现代浏览器支持。

6.5、你用Save-Data保存数据吗？（30）

特别是在新兴市场工作时，您可能需要考虑优化用户选择数据节省的体验。保存数据客户端提示请求头允许我们将应用程序和有效载荷定制为成本和性能受限的用户。实际上，您可以将高dpi图像的请求重写为低dpi图像，删除网页字体和幻想视差效果，关闭视频自动播放，服务器推送，甚至改变如何传递标记。

目前只支持在铬版本，chrome的android版本或桌面设备上的数据保护程序扩展。最后，您还可以使用服务人员和网络信息api根据网络类型提供低/高分辨率的图像。

6.6、热连接能加快传输？（31）

使用资源提示在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属性）将会双重提取。

6.7、你有没有优化渲染性能？（32）

用css遏制隔离昂贵的组件-例如，限制浏览器样式的范围，用于非画布导航的布局和会话工作或第三方小部件的范围。请确保在滚动页面或动画元素时不会出现滞后现象，并且始终每秒触及60帧。如果这是不可能的，那么至少使每秒帧数是一致的，最好是60到15之间的混合范围。使用css'will-change来通知浏览器哪些元素和属性会改变。

还要测量运行时渲染性能（例如，在devtools中）。开始吧，查看paul lewis关于浏览器渲染优化的免费udacity课程以及emily hayman关于高性能网页动画和交互的文章。

我们还得到了一个由sergey chikuyonok撰写的关于如何获得gpu动画的文章。快速提示：对gpu合成图层的更改是最便宜的，所以如果只通过不透明度和变换触发合成，就可以走上正轨。

6.8、你有优化渲染体验吗？（33）

尽管组件在网页上的显示顺序以及我们如何为浏览器提供资源的策略，但我们也不应低估感知性能的作用。这个概念处理等待的心理方面，基本上保持客户忙碌或从事其他事情正在发生。那就是感知管理，抢先发动，提前完成和宽容管理的地方。

这是什么意思呢？在加载资产的同时，我们可以总是领先于客户，所以在后台发生很多事情的时候，体验会很快。为了保持客户的参与，我们可以使用框架屏幕（实现演示），而不是加载指标，添加转换/动画，基本上在没有更多优化的时候欺骗用户。

7、HTTP/2

7.1、迁移到https，然后打开http / 2（34）

随着谷歌走向一个更安全的网络，并最终将所有的http页面作为“不安全”的铬页面处理，切换到http / 2环境是不可避免的。http / 2支持得非常好;它不会去任何地方;而且在大多数情况下，你最好用它。一旦在https上运行，您可以通过服务人员和服务器推送（至少是长期的）来获得重大的性能提升。

最耗时的任务是迁移到https，并且根据您的http / 1.1用户群（即，在传统操作系统上的用户或旧版浏览器中的用户）的大小，您必须发送一个不同的版本传统的浏览器性能优化，这将需要您适应不同的构建过程。注意：设置迁移和新的构建过程可能会非常棘手和耗时。对于本文的其余部分，我假设你要么切换到或已经切换到http / 2。

7.2、正确部署http / 2（35）

再次，通过http / 2服务资产需要对目前服务资产的部分检查。您需要在打包模块和并行加载许多小模块之间找到一个很好的平衡点。在一天结束的时候，最好的要求还是没有要求，但是目标是在资产的快速交付和缓存之间找到一个很好的平衡点。

一方面，您可能希望避免将资源完全并置，而将整个界面分解为许多小模块，将其作为构建过程的一部分进行压缩，通过“侦察”方法引用它们并将其并行加载。一个文件中的更改将不需要重新下载整个样式表或JavaScript。它也最大限度地减少了解析时间，并保持单个页面的有效负载低。

另一方面，包装仍然很重要。首先，压缩会受到影响。一个大包的压缩将受益于字典重用，而小的单独包不会。有标准的工作来解决这个问题，但现在已经很远了。其次，浏览器尚未针对此类工作流进行优化。例如，chrome将触发与资源数量成线性关系的进程间通信（ipcs），因此包含数百个资源将会产生浏览器运行时成本。

仍然可以尝试逐渐加载css。显然，通过这样做，您正在主动惩罚http / 1.1用户，所以您可能需要为不同的浏览器生成不同的构建，并将其作为部署过程的一部分，这就是事情稍微复杂的地方。你可以用http / 2连接合并，这允许你使用域分片，而从http / 2中受益，但是在实践中实现这一点是困难的。

该怎么办？如果你运行的是http / 2，发送大约6-10个包似乎是一个体面的妥协（对传统的浏览器来说也不算太坏）。实验和测量，以找到适合您的网站的平衡。

7.3、你的服务器和cdns支持http / 2吗？（36）

不同的服务器和cdns可能会不同地支持http / 2。使用很快呢？检查您的选项，或快速查看您的服务器如何执行以及您希望支持哪些功能。

7.4、启用了ocsp装订？（37）

通过在你的服务器上启用ocsp装订，你可以加快你的tls握手。在线证书状态协议（ocsp）被创建为证书撤销列表（crl）协议的替代方案。这两种协议都用来检查一个ssl证书是否被吊销。然而，ocsp协议并不要求浏览器花费时间下载，然后在列表中搜索证书信息，因此减少了握手所需的时间。

7.5、你有没有采用ipv6？（38）

由于我们的ipv4空间不足，主要的移动网络正在迅速采用ipv6（美国的ipv6采用率达到了50％），因此将DNS更新为ipv6是一个不错的主意，以保证未来的发展。只要确保在整个网络上提供双栈支持-它允许ipv6和ipv4同时并行运行。毕竟，ipv6不是向后兼容的。另外，研究表明，由于邻居发现（ndp）和路由优化，ipv6使这些网站速度提高了10％到15％。

7.6、是使用hpack压缩？（39）

如果您使用的是http / 2，请仔细检查您的服务器是否为http响应头实施了hpack压缩，以减少不必要的开销。由于http / 2服务器比较新，所以可能不完全支持这个规范，以hpack为例。h2spec是一个伟大的（如果技术上非常详细）的工具来检查。hpack的作品。

7.7、确保您的服务器上的安全性是防弹的（40）

http / 2的所有浏览器实现都运行在tls上，因此您可能希望避免安全警告或网页上的某些元素无法正常工作。仔细检查您的安全标头设置是否正确，消除已知的漏洞并检查您的证书。另外，请确保所有外部插件和跟踪脚本都通过https加载，不能跨站点脚本，并且http严格传输安全性标头和内容安全策略标头都已正确设置。

7.8、是用于缓存和网络回退的服务人员吗？（41）

网络上的性能优化不会比本地存储在用户机器上的缓存更快。如果您的网站是通过https运行的，请使用“服务人员的实用指南”将静态资产缓存到service worker缓存中，并存储离线回退（甚至是离线页面），并从用户的机器中检索它们，而不是去网络。还要检查jake的离线烹饪书和免费的udacity课程“离线网络应用程序”。浏览器支持？如上所述，它是广泛支持（铬，火狐，Safari浏览器，三星互联网，边缘17+）和后备是无论如何网络。它有助于提升性能吗？哦，是的，它的确如此。

8、测试和监测

8.1、您是否在代理浏览器和旧版浏览器中进行过测试？（42）

在Chrome和Firefox测试是不够的。了解您的网站在代理浏览器和旧版浏览器中的工作方式。例如，uc浏览器和opera mini在亚洲市场份额很大（在亚洲高达35％）。测量您感兴趣的国家的平均互联网速度，以避免大惊小怪。使用网络调节进行测试，并模拟高dpi设备。browserstack是太棒了，但也测试真实的设备。

8.2、是连续监测设置？（43）

有一个私人的网页测试实例总是有利于快速和无限的测试。不过，具有自动警报功能的连续监控工具可以让您更详细地了解您的表现。设置您自己的用户时间标记来衡量和监控特定于业务的指标。

另外，考虑添加自动性能回归警报来监视随时间的变化。研究使用朗姆酒解决方案来监测性能随着时间的变化。对于类似自动化单元测试的负载测试工具，您可以使用k6及其脚本API。还要看速度追踪器，灯塔和口径。

9、总结

这个列表是相当全面的，完成所有的优化可能需要相当长的一段时间。所以，如果你只有一个小时才能获得显着的改善，你会怎么做？让我们把这一切都归结为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缓存中。

10、下载清单

考虑到这个清单，你应该准备好任何类型的前端性能项目。请随意下载清单的打印准备pdf以及一个可编辑的苹果页面文档，以根据您的需求定制清单：

l 下载清单pdf（pdf，0.129 mb）

l 在苹果页面下载清单（.pages，0.236 mb）

如果您需要替代品，您也可以通过dan rublic查看前端清单以及jon yablonski的“设计师网站性能清单”。

11、结束语

一些优化可能超出了你的工作或预算的范围，或者可能只是因为你必须处理的遗留代码而被过度杀伤。没关系！使用这个清单作为一般（并希望全面）指南，并创建适用于您的上下文的问题列表。但最重要的是，在优化之前测试并测量您自己的项目以确定问题。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评论这篇文章，还有我们的精彩的社区，分享了它在性能优化方面的技巧和经验教训，供大家使用。你真的粉碎！