2021前端性能指标研究表（译）

本文纯谷歌翻译自外网，且看且珍惜。有错误评论区指正，thx。

下面是一些前端性能指标（front-end performance issues）的预览，你可能需要考虑以确保您的响应时间快速且平滑。

做好准备：规划和指标（Get Ready: Planning and Metrics）

建立绩效文化。
如果没有长期的业务支持，就不会出现持续的业务学习。常见的客户服务投诉，看看如何提高绩效真实缓解一些问题。使用数据建立公司定制的案例研究。和业务指标。在设计过程中规划加载顺序和权衡。
比邀请的速度快20%。
在代表您的听众的设备上收集数据。更喜欢真实的设备而不是模拟。选择Moto G4/G5 Plus、中端三星设备（Galaxy A50、S8）、中端设备像 Nexus 5X、小米 A3 或小米红米 Note 7 这样的路上设备和像慢速设备或者，阿尔卡特1X或Cubot X19。或者，通过在桌面上进行测试来模拟移动体验节流网络（例如 300 毫秒 RTT，数据 1.6 Mbps，向上 0.8 Mbps）伴随节流 CPU（5×慢）。然后切换到普通 3G，慢速 4G（例如 170ms RTT，9 Mbps down，9 Mbps上）和 Wi-Fi。收集数据、设置电子表格、减少 20% 设定目标（业绩预告）。
选择正确的指标。
并非每个指标都同等重要。研究哪些指标最重要：通常是与您可以快速开始渲染最重要的像素以及您可以提供多快相关输入响应。优先考虑客户认为的页面加载。时间到原创、首次输入延迟、英雄渲染时间、最大内容绘制、总设计师时间和累积布局偏移通常很重要。不是：第一个有意义的油漆。
为测试设置“干净”和“客户”配置文件。
关闭反病毒和后台CPU任务，删除后台传输和使用没有浏览器扩展程序的干净用户文件进行测试，结果出现配置学习。您的客户使用哪些扩展，并专门使用的“客户”配置文件进行测试。由维塔利弗里德曼策划。永久网址：www.smashed.by/perf-checklist。2021年1月11日。
与您的同事分享清单。
确保您团队的成员都知道清单。性能影响，您的项目减少减少整个团队的演绎。根据演练地图设计挖掘。

设定切合实际的目标（Setting Realistic Goals）

100 毫秒响应时间，每秒60帧。
每帧动画应在 16 毫秒内完成——理想情况下为 10 毫秒，从而实现每秒60帧（1秒÷60 = 16.6毫秒）。是乐观并聪明地利用西方时间。对于像动画这样的高压点，最好做估计没有其他的地方和绝对可能的地方。延迟应低于50毫秒。明智地利用空闲时间，使用空闲直到紧急方法。
LCP < 2.5s, FID < 100ms, CLS < 0.1, Time To Interactive < 5s on 3G.
考虑到基准是 200 美元的 Android 手机在慢速 3G 上，以 400 毫秒 RTT 模拟和400kbps的传输速度，目标是交互时间<5秒，重复访问，在2-3秒内。争取最大的内容绘制< 2.5秒并最小化总阻塞时间状语从句：累积布局移位。努力使这些值尽可能低。
关键文件大小保存 < 170KB
HTML 的前 14-16KB 是最关键的有效南瓜块——也是可以在第一次可能的中目标交付的实现。为实现上述，操作在最大的关键文件大小预算内。170KB gzip压缩（0.7-0.8MB解压。确保您的提前会根据网络条件和硬件限制而变化。

定义环境（Defining the Environment）

选择并设置您的构建工具。
不要太在意重点的酷。只要你能快速获得结果您在维护构建过程方面没有问题，您做得很好。唯一的例外可能是 Webpack 或 Parcel，它们提供了优秀的技术，例如代码-分裂。如果尚未使用，请务必详细查看代码拆分和摇树。
使用渐进增益作为默认设置。
先设计创新核心体验，再用高级体验提升体验有自己的浏览器，创造弹性体验。如果您的网站在次优网络上的浏览器中屏幕很慢的机器，那么它寻找在一个不错的网络上有一个不错的浏览器的快速机器上运行得可以。
选择一个绩效的绩效标准。
JavaScript 的体验成本最高。170KB 的服务器已经包含关键路径 HTML/CSS/JavaScript、主机、状态管理、实用程序、框架和应用程序逻辑，彻底检查网络传输成本、解析/编译时间和我们选择的框架的运行时成本。
日常框架和依赖项。
不是每个项目都需要框架，也不是SPA的每个页面都需要加载框架。是在你的中深思熟虑。通过探索特性、可访问性、稳定性来选择JS，业绩、包生态系统、学习历程、文档、工具、追踪记录、团队、Next.js (React)、Gatsby(React)、Vuepress(Vue)和PreactCLI 提供合理的默认值，以便在移动硬件上快速加载开箱即用。
聪明地选择你的战斗：React、Vue、Angular、Ember 和 Co。
确保您选择的框架提供服务器端渲染或预渲染。在确定之前测量的移动设备上服务器和客户端渲染模式下的启动时间。了解您将依赖的框架的具体细节。研究PRPL模式和应用外壳程序框架。应用的选项是 Preact、Inferno、Vue、Svelte、Alpine、Polymer。
优化API的性能。
如果许多资源需要来自 API 的数据，则 API 可能会成为性能数据。考虑使用GraphQL，一种查询语言和一个服务器端运行时来执行查询使用您为数据定义的类型系统。与 REST 不同，GraphQL 可以检索所有数据一次请求，而不会忘或不足获取数据，因为它同时地与休息发生。
您将使用 AMP 还是 Instant Articles？
没有它们，您可以实现良好的性能，但 AMP可能会提供可靠的性能框架，有免费CDN，而即阅文将提高您的知识性和性能在脸书上。您也可以构建渐进式网络AMP。
聪明地选择您的 CDN。
可知您拥有多少动态，您可能可以“删除”部分数据内容到现场生成器，将其传送到 CDN 并提供更新版本，从而避免数据库请求（JAMStack）。仔细检查您的 CDN 是否执行内容压缩和转换，（例如在格式、压缩和在边界调整大小），为您提供对服务器工作人员和边界端的支持。

资产优化(Assets Optimizations)

使用 Brotli 进行纯文本压缩。
Brotli 是一种新的无数据格式，现在所有的现代浏览器都支持。它更有效与Gzip已和放气相比，压缩速度非常慢，但解压缩速度很快。预压缩静态使用最高级别的Brotli+Gzip压缩资产，使用Brotli动态压缩（动态）HTML在1-4级。检查对CDN的Brotli支持了。确保服务器处理的内容正确协商 Brotli 或 gzip。
使用响应式图像、AVIF 和 WebP。
尽可能，使用自适应图片包含有srcset，尺寸，<画面>状语从句：图像集。AVIF> WebP的。即成AVIF和WebP的格式与<画面>和一个JPEG/PNG回退，或通过使用内容协商（使用Accept标头）。注意：使用WebP，您将减少有效负载，但使用JPEG您将提高预测性能，因此用户可能会更快地看到实际图像
ol’ JPEG 自己 WebP 图像通过网络可能会解决。
图像是否经过适当优化？
使用mozJPEG进行JPEG压缩，使用SVGO进行SVG压缩，使用Pingo进行PNG — 或Squoosh对于所有这些（包括 AVIF）。要检查响应式标记的效率，您可以使用图像堆。对于关键图像，使用渐进式JPEG并不清楚不需要部分（通过应用高斯模糊过滤器）并过滤材料（您可以使用 CSS 过滤器重应用它）。确保为所有图片定义了宽度和高度，将图片自动压缩添加到您的拉取请求并查看延迟加载不太重要的图像。
视频是否经过适当优化？
代替动画 GIF，使用动画 WebP（GIF 后备）或内联HTML5视频。请确保您的MP4S与多通道编码处理后，使用frei0r iirblur效果（如果适用）模糊，伪装moov atom元数据移动到伪装文件，而您的服务器接受字节服务。一般以AV1格式提供视频格式，可提供一个备用的为好。调整视频和使用适应的媒体服务提供您的客户可以在他们的设备上实际播放而不会出现停顿的内容。
网络字体是否经过优化？
子集字体。选择WOFF2 并使用 WOFF 成为后备。在后备中显示内容最终解决方案：两阶段渲染，首先使用一个超子集，然后再加载该系列的其余部分。预加载每个系列的1-2种。避免字体声明的local()值，但要考虑字体安装本地的操作系统的。字体不要引用，包括显示：使用字体和加载事件用于组重绘。使用Web Font Reflow Count和Time To Real Italics指标。

构建优化（Build Optimizations）

确定您的优先事项。
在所有的资产（JavaScript，字体，脚本的运行，页面上的“昂贵”模块），并将它们分成几组。定义基本核心体验（旧版浏览器完全可访问的核心内容）、增强的体验（一个功能强大的浏览器的直观完整体验）和附加功能（并非绝对的）需要并且可以延迟加载）。
在生产中使用本地JavaScript模块。
将核心体验发送到旧版浏览器，将增强的体验发送到现代浏览器。使用 ES2017+

交付优化（Delivery Optimizations）

异步加载JavaScript。
开发人员，我们必须明确告诉浏览器不要等待并开始渲染页面使用HTML中的defer和async属性。总是更喜欢defer而不是async。使用defer，浏览器在解析HTML并且所有先前的同步脚本都已执行之前，不会执行脚本。别同时使用。除非你需要JS之前开始渲染执行，的英文这地更好利用延迟。
使用IntersectionObserver 延迟加载的组件。
延迟加载所有插件的组件，例如繁重的JavaScript、视频、iframe、小用户和潜在的图像。最高效的方法是使用本机延迟加载
（加载和资本属性）或通过使用 Intersection Observer — 后期可以也用于滚动、视差和广告跟踪。
延迟昂贵的图像的渲染和解码。
使用content-visibility: auto，我们可以提示浏览器跳过孩子的地图，而该容器是外部的视口。只要确保使用含有本。征尺寸与
占位符大小消息浏览CLS。此外，提示器对图像进行解码带有<imgdecode = “异步”>的主线程，以减少操作所需的CPU时间。
快速发送关键CSS。
收集开始页面第一个可见部分可能的所有CSS（“关键
CSS”或“above-the-fold”CSS），将其内联添加到页面的中（保持在14 KB以下）。考虑条件内联方法。将关键CSS放在根目录上的单独文件中域有好处，有时是因为外界有好处。
实验重组合您的 CSS 规则。
考虑将主CSS文件拆分为单独的媒体查询。避免放置<链路的rel = “样式表”/前>异步场景。如果脚本不依赖于样式表，考虑将
阻塞样式上面的阻塞脚本。如果他们这样做，将该JavaScript的分成两部分并加载它你的 CSS 的关键。缓存内联 CSS 与服务工作者和实验中体CSS。动态样式可能很有钱：检查您的 CSS-in-JS 库是否优化了执行当您的 CSS 不依赖于主题/道具时，不要组合样式组件。
流响应。
Streams 提供了一个用于读取或写入数据块的接口，只有一个有的子集可能在任何给定的时间在内存中可用。而不是服务空UI shell 并让 JavaScript 填充它，让 Service Worker 构建一个流，其中外壳来自一个高速缓存，但身体来自于网络。HTML中呈现
然后开始导航请求可以充分利用浏览器的 HTML 解析器。
考虑让您的组件连接/设备内存查看。
为受成本和性能限制的用户定制应用程序和有效负载的保存数据提示请求头。您可以将高 DPI 图像的请求改写为低 DPI 图像、删除网络字体和视差、关闭视频自动播放，甚至更改播放方式你提供标记。使用网络信息 API交付沉重组件的变体基于连接性，以及内存 API根据设备内存调整资源。
提前连接以戏剧速度的传递。
使用资源提示来节省dns-prefetch的时间（后台DNS查看），预连接（开始连接招手（DNS、TCP、TLS））、预取（请求资源）、预加载（预取资源而不执行它们等）和预渲染（提前获取资源但不执行JS或提前渲染页面的任何部分）。使用预加载时，必须定义为或不加载；没有跨域的预加载字体对于预载，存在优先属性级，因此请考虑考虑。在外部脚本之前将rel="preload"元素注入DOM。
使用Service Worker 进行访问和网络回退。
如果您的网站通过 HTTPS 运行，Worker 数据库缓存在服务中并存储离线回退（甚至机器离线页面）并从用户的上检索它们，而不是而不是去网络。将 app shell 和一些存储在 service worker 的缓存中关键页面，例如离线页面或主页。但是：确保正确的 CORS 响应存在跨域资源的标头，不要选择性不透明的响应和选择加入跨域图像资产进入CORS模式。
在 CDN/Edge 上使用 Service Worker（例如用于 A/B 测试）。
随着 CDN 在服务器上实现 Service Worker，考虑调整 Service Worker边界性能也是如此。例如，在 A/B 测试中，当 HTML 需要改变其内容时不同的用户，使用 CDN 上的 Service Worker 来处理逻辑。或流 HTML写作以加速使用谷歌字体的网站。
优化渲染性能。
如果需要，使用精细的CSS包含隔离昂贵的组件。确保没有动画滚动页面或当一个元素被动画的时候，那你总是达到每秒60帧。如果不可能的，那么制作每帧第二个一致性至少比60到15的混合范围更可取。使用CSS将变到通知浏览器哪些元素将发生变化。
您是否优化了渲染体验？
尽量避免表现的作用。在加载资产时，尽量保持全景客户阶梯，因此体验第一时间，而有很多为了保持客户参与度，请使用屏幕而不是在后台。加载并添加动画。
防止布局移位（回流）和重新绘制。 (Prevent layout shifts (reflows) and repaints.)
返回是由重缩放的图像和视频、注入的广告或字体发现网络、用实际内容填充组件的脚本。设置宽度和高度属性图像，因此现代浏览器默认分配框并保留空间。使用SVG占位符来保留视频和图像将出现在其中的显示框。混合延迟加载仅在本地延迟加载不是时才加载外部延迟加载支持的。将Web字体重绘效果，并使用字体样式匹配器匹配行高和技巧。使用 Layout Instability API 和Cumulative Layout Shift (CLS)追踪观察的稳定性。

网络和 HTTP/2（Networking and HTTP/2）

OCSP 装订是否可以？
通过在您的服务器上启用OCSP装订，您可以加速TLS握手。OCSP协议无需浏览器花时间下载然后搜索列表证书信息，从而减少需要的时间。
您是否减少了SSL证书吊销的影响？
扩展(扩展()证书既扩展又验证EV，因为他们需要人工审查证书并确保其有效性。域验证（DV）证书，相反，通常是免费提供的。EV证书不完全支持OCSP装订，因此一直提供OCSP装订的DV证书并保持TLS证书。
你已经采用IPv6了吗？
研究证明，由于邻居发现（NDP）和路线优化。更新IPv6的DNS，以保持未来的防弹能力。只要确保跨网络提供双栈支持——它允许IPv6和IPv4运行同时并排向。IPv6不向后。
是否正在使用 TCP BBR？
BBR是一种相对较新的TCP延迟控制TCP流量控制算法。它响应实际塞，而不是像 TCP 那样拥丢包，因此，它的速度要快得多，B允许拥塞控制并设置tcp_notsentlowat。到 16KB 用于 HTTP/2 优先级，才能在 Linux 4.9 内核及更高版本上可靠地工作。
总是首选HTTP/2。
HTTP/2 得到了很好的支持，并提供了性能提升。它不会去任何地方，而且在新闻报道下，您最好使用它。根据您的移动用户群有多大，您可能需要不同的构建，你可以从适应不同的构建中发生过程。（HTTP/2 在具有明显丢包率的网络上通常较慢。）
正确部署 HTTP/2。
你需要在打包模块和加载很多小模块之间找到一个很好的平衡块在平行下。将整个界面分解成许多小模块;然后分组，压缩并不是捆绑它们。在包分类分解，或通过哪些CSSJS/块是/用过的。独立的供应商和客户端代码，并独立供应商的依赖很少和频繁。发送关于6-10包似乎是一个体面的妥协（而不是太坏的传统浏览器）。实验和测量，以找到正确的平衡。尽最大努力通过 HTTP/2 连接发送多小的资产。
做你的服务器和CDN 的支持HTTP / 2？
不同的服务器和CDN的支持HTTP / 2种不同。使用CDN比较来检查你的选项，或快速查找您期望支持的功能。启用BBR拥塞控制，为HTTP/2优先级设置tcp_notsent_lowat为16KB。
是否正在使用 HPACK 压缩？
如果您使用 HTTP/2，请仔细检查您的服务器是否实现了 HPACK 压缩HTTP响应报头，以减少交通的负担。因为HTTP / 2服务器是相对较新，他们可能不完全支持规范，例如HPACK。H2spec是一个很好的（如果技术上非常详细）工具来它它。
为 HTTP/3 做好准备。
在 HTTP/2 中，多个请求共享一个连接，在 HTTP/3 中请求也共享一个连接连接但独立传输，因此被丢弃的数据包不再影响所有请求，只是一个流。借助HTTP3的QUIC，TCP和TLS结合并在同一时间内完成单次请求，从第二次连接开始，我们可以发送和接收第一次包装中的应用层数据（0-RTT）。所以包装很重要，所以不要发送单片JS，在并行发送多JS-文件。期待在移动上加载时间的影响。
您的服务器和 CDN 是否支持 HTTP/3？
QUIC HTTP/3 更好，更防弹：更快的招呼，更好的智能，更可靠的独立流，更健康，如果客户端之前使用 0-RTT与服务器建立了连接。然而，这是相当CPU密集型（2-3倍CPU使用率）相同的）。检查您的服务器或CDN是否支持HTTP over QUIC（也如下作为HTTP / 3），如果你可以启用它。
确保您服务器上的安全措施是防弹的。
仔细检查您的安全标头是否设置正确，删除已知安全漏洞，并检查您的证书。确保所有外部插件和记录脚本都已加载通过HTTPS，跨站点脚本是不可能的，并且HTTP强制传输安全标头和内容安全策略标头已正确设置。

测试和监控（Testing and Monitoring）

监控混合内容警告。
如果您最近从 HTTP 迁移到 HTTPS，确保监控活动的和使用 Report-URI.io 等工具进行被动混合内容警告。您还可以使用混合内容警告。内容扫描可扫描可使用 HTTPS 的网站以查找混合内容。
您是否优化了审核和调试工作流程？
花时间研究调试器中的调试和审计技术，WebPageTest，灯塔和增压您的文本编辑器。E，G，你可以从谷歌驱动WebPageTest
电子，并没有时间性、性能和SEO访问您的特拉维斯设置使用 Lighthouse CI 或直接进入 Webpack。使用 Perf 诊断 CSS 进行快速检查。
您是否在代理浏览器和旧浏览器中进行过测试？
在 Chrome 和 Firefox 中进行测试是经典的。查看您的网站在代理中的工作方式浏览器和传统浏览器（包括UC浏览器和Opera Mini的的）。测量平均中你的用户群的上网速度，以避免大的意外。测试与网络限制和模拟高DPI设备。BrowserStack是太棒了，但在实际设备上测试过。
您是否测试过404页面的性能？
每次客户请求不存在的资产时，他们都收到404响应——并且通常这种反应是巨大的。确保检查和优化您的适时策略404页。确保只有在浏览器需要HTML响应时才向浏览器提供HTML，并为所有其他响应返回一个错误。
您是否测试了 GDPR 同意提示的性能？
偶尔情况下接受Cookie的提示，不应该对CLS的影响，但有时他们会破坏，所以考虑使用免费和福利选项Osano或cookie-consent-box。同意书是可能会改变脚本对整体性能的影响，所以设置并研究了一些
针对不同类型同意的不同 Web 性能配置文件。
有你测试的可访问性的影响？
使用 JavaScript 的大页面和 DOM 操作会导致屏幕阅读延迟公告。快速实现互动手段多少时间，直到屏幕上通过阅读器可以在给定页面上导航，屏幕阅读器用户实际上可以点击键盘进行交互。
是否设置了持续监控？
良好的性能指标是被动和主动监测工具的组合。有一个WebPagetest 的非法实例和使用 Lighthouse总是有快速的测试，但是还可以使用RUM工具（例如SpeedTracker、SpeedCurve和其他设置自己的用户正时标记来衡量和企业具体监测指标。

快速取胜（Quick wins）

此列表非常全面，完成所有优化可能需要很长时间。那么，如果你只有 1 小时的时间来获得显着的改进，你会怎么做？让我们把这一切都煮沸下降到18唾手可得的成果。显然，然后再开始，一旦完成，测量结果，包括最大的内容绘制和 3G 和电缆连接上的交互时间。(This list is quite comprehensive, and completing all of the optimizations might take quite a while.So, if you had just 1 hour to get significant improvements, what would you do? Let’s boil it all down to 18 low-hanging fruits. Obviously, before you start and once you finish, measure results, including Largest Contentful Paint and Time To Interactive on a 3G and cable connection.)

体验现实世界的体验并设定适当的目标。目标是至少快20%速度接收的提供。留最大内容量<2.5s的，第一输入延迟内<100毫秒，在慢速3G上交互时间<5秒，对于重复访问，TTI <2秒。至少优化第一次内容绘制和互动时间。
优化图像Squoosh，mozjpeg，guetzli，PINGO和SVGOMG，和服务AVIF / WebP的的与图像 CDN。
主要模板准备关键CSS，将它们内联到每个模板的中。对于 CSS/JS，在最大的关键文件大小保存内运行。170KB gzip 压缩（0.7MB 解压缩）。
体验乐趣、优化、延迟和延迟加载。投资于您的捆绑器的配置以删除平行并检查轻量级替代方案。
始终自托管您的静态资产。总是更喜欢自托管第三方资产。限制他们的影响。使用造型，在交互时加载小手并注意防止闪光的瞬间。
选择框架时选择程序。对于单页应用程序，确定关键页面并一起地为它们提供服务，或集中采集它们，并使用渐进式水合作用组件级和导入模块交互。
单独的客户端渲染不是性能的好选择。如果您的页面没有预呈现好很多，并推迟框架的启动。使用流式服务器端渲染。
仅将遗留代码提供给具有模块/无模块模式的遗留浏览器。
实验重组合 CSS 规则并测试体内 CSS。
添加资源提示以加速交付速度，包括dns-lookup、preconnect、prefetch 、 preload 、 prerender。
对网页字体进行子集化并异步加载，首先利用CSS中的字体显示快速渲染。
检查 HTTP 缓存头和安全头是否设置正确。
在服务器上启用Brotli压缩。（如果这不可能，请不要忘记启用Gzip压缩。）
如果你的服务器在 Linux 内核版本 4.9+ 上运行，则可以支持 TCP BBR 拥塞。
如果可能，可以启用 OCSP 装订和 IPv6。始终提供 OCSP 装订的 DV 证书。
HTTP/2 启用 HPACK 压缩，如果可以，请移至 HTTP/3。
在Service Worker缓存中缓存字体、样式、JavaScript和图像等资产。
探索避免再水化的选项，使用渐进式水化和流媒体服务器端为您的单页应用程序呈现。