让application性能提升 10 倍的 10 个技巧

提高 Web应用的性能比以往任何时候都更加重要。 在线经济活动的份额正在增长；目前发达国家有超过 5% 的经济是在互联网上进行的（请参阅下面的互联网统计资源）。 我们这个永远在线、高度互联的现代世界意味着用户的期望比以往任何时候都高。 如果您的网站不能立即响应，或者您的应用程序不能立即运行，用户很快就会转向您的竞争对手。

例如，亚马逊近 10 年前进行的一项研究证明，即使在那时，页面加载时间减少 100 毫秒也可以使其收入增加 1%。 另一项最新研究强调了这样一个事实：超过一半接受调查的网站所有者表示，他们因应用性能不佳而损失了收入或客户。

网站需要多快？ 页面每加载一秒，大约有 4% 的用户会放弃该页面。 顶级电子商务网站提供首次互动时间为一到三秒，可提供最高的转化率。 显然，Web应用性能的风险很高，并且可能会越来越高。

想要提高绩效很容易，但实际看到成果却很难。 为了帮助您实现这一目标，这篇博文提供了十条技巧，帮助您将网站性能提高 10 倍。 这是系列文章的第一篇，详细介绍了如何借助一些经过充分测试的优化技术以及 NGINX 的一点支持来提高应用的性能。本系列还概述了您可以在此过程中获得的潜在安全性改进。

提示 1 – 使用反向代理服务器加速和保护applications

如果您的 Web应用在单台机器上运行，那么性能问题的解决方案可能看起来很明显：只需获得一台更快的机器，配备更多的处理器、更多的 RAM、快速的磁盘阵列等等。 然后新机器可以比以前更快地运行您的 WordPress 服务器、Node.js应用、Java应用等。 （如果您的应用访问数据库服务器，解决方案可能仍然看起来很简单：获得两台更快的机器，并在它们之间建立更快的连接。）

问题是，机器速度可能不是问题。 Web应用通常运行缓慢，因为计算机在不同类型的任务之间切换：通过数千个连接与用户交互、从磁盘访问文件以及运行应用代码等等。 应用服务器可能会出现故障 - 内存不足、将大块内存交换到磁盘，以及许多请求等待单个任务（如磁盘 I/O）。

您不需要升级硬件，而是可以采取一种完全不同的方法：添加反向代理服务器来卸载其中一些任务。 反向代理服务器位于运行应用的机器前面，处理互联网流量。 只有反向代理服务器直接连接到 Internet；与应用服务器的通信是通过快速的内部网络进行的。

使用反向代理服务器可使应用服务器无需等待用户与 Web 应用程序交互，而可以专注于构建页面以供反向代理服务器通过 Internet 发送。 应用服务器不再需要等待客户端响应，可以以接近优化基准的速度运行。

添加反向代理服务器还可以增加您的 Web 服务器设置的灵活性。 例如，如果某种类型的服务器超载，则可以轻松添加另一台相同类型的服务器；如果服务器宕机，则可以轻松更换。

由于其提供的灵活性，反向代理服务器也是许多其他性能提升功能的先决条件，例如：

• 负载平衡（参见技巧 2 ）——负载平衡器在反向代理服务器上运行，以便在多个应用服务器之间均匀共享流量。 有了负载平衡器，您可以添加应用服务器，而根本不需要更改应用。
• 缓存静态文件（参见技巧 3 ）——直接请求的文件（例如图像文件或代码文件）可以存储在反向代理服务器上并直接发送到客户端，从而更快地提供资产服务并减轻应用服务器的负担，从而使应用运行得更快。
• 保护您的网站——可以配置反向代理服务器以实现高安全性，并对其进行监控以快速识别和响应攻击，从而保护应用服务器。

NGINX 软件专门设计用于用作反向代理服务器，具有上面描述的附加功能。 NGINX 使用事件驱动的处理方法，比传统服务器更高效。 NGINX Plus 增加了更多高级反向代理功能，例如应用健康检查、专门的请求路由、高级缓存和支持。

提示 2——添加负载均衡器

添加负载平衡器是一个相对容易的改变，它可以显著提高网站的性能和安全性。 您无需让核心 Web 服务器变得更大、更强大，而是使用负载平衡器在多个服务器之间分配流量。 即使应用编写得不好，或者在扩展方面存在问题，负载均衡器也可以在不进行任何其他更改的情况下改善用户体验。

负载均衡器首先是一个反向代理服务器（参见提示 1 ）——它接收互联网流量并将请求转发到另一台服务器。 诀窍在于负载均衡器支持两个或多个应用服务器，使用多种算法在服务器之间分割请求。 最简单的负载均衡方法是循环，每个新请求都被发送到列表中的下一个服务器。 其他方法包括向具有最少活动连接的服务器发送请求。 NGINX Plus 具有在同一服务器上继续给定用户会话的功能，这称为会话持久性。

负载平衡器可以显著提高性能，因为它们可以防止一台服务器过载，而其他服务器则等待流量。 它们还可以轻松扩展您的 Web 服务器容量，因为您可以添加相对低成本的服务器并确保它们得到充分利用。

可以进行负载平衡的协议包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、 FastCGI 、SCGI、uwsgi、memcached 和其他几种应用类型，包括基于 TCP 的应用和其他第 4 层协议。 分析您的 Web应用以确定您使用哪个应用程序以及哪里的性能滞后。

用于负载均衡的同一服务器还可以处理其他几项任务，例如 SSL 终止、支持客户端使用 HTTP/ 1.x和 HTTP/2 以及静态文件的缓存。

NGINX 经常用于负载均衡。 要了解更多信息，请下载我们的电子书《选择软件负载均衡器的五个理由》 。 您可以在《使用 NGINX 和 NGINX Plus 进行负载均衡，第 1 部分》中获得基本的配置说明，并在《NGINX Plus 管理指南》中获得完整的文档。 NGINX Plus是我们的商业产品，支持更专业的负载均衡功能，例如基于服务器响应时间的负载路由和在 Microsoft 的 NTLM 协议上进行负载均衡的能力。

提示 3——缓存静态和动态内容

缓存通过更快地向客户端提供内容来提高 Web应用的性能。 缓存可以涉及多种策略：预处理内容以便在需要时快速交付、将内容存储在更快的设备上、将内容存储在更靠近客户端的地方，或者将内容存储为多种策略的组合。

有两种不同类型的缓存需要考虑：

• 静态内容缓存——不经常更改的文件，例如图像文件（JPEG、PNG）和代码文件（CSS、JavaScript），可以存储在边缘服务器上，以便从内存或磁盘快速检索。
• 动态内容缓存——许多 Web应用会为每个页面请求生成新的 HTML。 通过在短时间内短暂缓存生成的 HTML 的一个副本，您可以显著减少必须生成的页面总数，同时仍能提供足够新鲜的内容来满足您的要求。

例如，如果某个页面每秒的浏览量为 10 次，并且您将其缓存 1 秒，则该页面 90% 的请求将来自缓存。 如果您单独缓存静态内容，即使是新生成的页面版本也可能主要由缓存内容组成。

缓存 Web应用生成的内容主要有三种技术：

• 将内容移近用户——将内容副本保存在离用户更近的地方可减少其传输时间。
• 将内容移动到更快的机器——内容可以保存在更快的机器上，以便更快地检索。
• 将内容从过度使用的机器上移走——机器有时运行速度比其在特定任务上的基准性能慢得多，因为它们正忙于其他任务。 在不同的机器上缓存可以提高缓存资源和非缓存资源的性能，因为主机的过载较少。

Web应用的缓存可以从内部（Web应用服务器）向外实现。 首先，对动态内容使用缓存，以减少应用服务器的负载。 然后，使用缓存来存储静态内容（包括原本是动态内容的临时副本），进一步减轻应用服务器的负担。 然后将缓存从应用服务器移到速度更快和/或更靠近用户的机器上，从而减轻应用服务器的负担，并减少检索和传输时间。

改进的缓存可以极大地加快应用的速度。 对于许多网页来说，静态数据（例如大型图像文件）占内容的一半以上。 如果不使用缓存，检索和传输此类数据可能需要几秒钟，但如果数据在本地缓存，则只需几分之一秒。

作为实际中使用缓存的示例，NGINX 和 NGINX Plus 使用两个指令来设置缓存： proxy_cache_path和proxy_cache 。 您指定缓存位置和大小、文件在缓存中保存的最长时间以及其他参数。 使用第三个（非常流行的）指令proxy_cache_use_stale ，您甚至可以在提供新内容的服务器繁忙或关闭时指示缓存提供陈旧的内容，从而为客户端提供一些东西而不是什么都没有。 从用户的角度来看，这可能会大大提高您的网站或应用程序的正常运行时间。

NGINX Plus 具有高级缓存功能，包括支持缓存清除和在仪表板上可视化缓存状态以进行实时活动监控。

有关使用 NGINX 缓存的更多信息，请参阅参考文档和NGINX Plus 管理指南。

笔记： 缓存跨越了应用人员、做出资本投资决策的人员和实时运行网络的人员之间的组织界限。 复杂的缓存策略（如这里提到的策略）是DevOps 视角价值的一个很好的例子，其中应用开发人员、架构和运营视角相融合，以帮助实现站点功能、响应时间、安全性和业务结果（如完成的交易或销售）的目标。

提示 4——压缩数据

压缩是一个巨大的潜在性能加速器。 针对照片（JPEG 和 PNG）、视频（MPEG-4）和音乐（MP3）等，有精心设计且高效的压缩标准。 每个标准都将文件大小减少一个数量级或更多。

文本数据（包括 HTML（包括纯文本和 HTML 标签）、CSS 和 JavaScript 等代码）通常以未压缩的形式传输。 压缩这些数据可能会对感知的 Web应用性能产生不成比例的影响，尤其是对于移动连接速度慢或受限的客户端而言。

这是因为文本数据通常足以让用户与页面进行交互，而多媒体数据可能更具支持性或装饰性。 智能内容压缩可以减少 HTML、Javascript、CSS 和其他基于文本的内容的带宽要求，通常可减少 30% 或更多，同时相应减少加载时间。

如果您使用 SSL，压缩会减少必须进行 SSL 编码的数据量，从而抵消压缩数据所需的部分 CPU 时间。

压缩文本数据的方法多种多样。 例如，请参阅技巧 6，了解 SPDY 和 HTTP/2 中专门针对标头数据而改编的新型文本压缩方案。 作为文本压缩的另一个示例，您可以在 NGINX 中启用 GZIP压缩。在服务上预压缩文本数据后，您可以使用gzip_static指令直接提供压缩的.gz文件。

提示 5——优化 SSL/TLS

安全套接字层 ( SSL ) 协议及其后继协议传输层安全性 ( TLS ) 协议正在被越来越多的网站使用。 SSL/TLS 对从原始服务器传输到用户的数据进行加密，以帮助提高网站安全性。 影响这一趋势的部分因素可能是，谷歌现在利用 SSL/TLS 的存在对搜索引擎排名产生积极影响。

尽管越来越受欢迎，但 SSL/TLS 的性能问题仍然是许多网站的症结所在。 SSL/TLS 会降低网站性能，原因有二：

1. 每当打开新连接时都需要进行初始握手来建立加密密钥。 使用 HTTP/ 1.x的浏览器为每个服务器建立多个连接的方式使命中率成倍增加。
2. 在服务器上加密数据并在客户端解密会产生持续的开销。

为了鼓励使用 SSL/TLS，HTTP/2 和 SPDY（在下一个技巧中描述）的作者设计了这些协议，以便浏览器每个浏览器会话只需要一个连接。 这大大减少了 SSL 开销的两个主要来源之一。 然而，今天还可以做更多的事情来提高通过 SSL/TLS 交付的应用的性能。

优化 SSL/TLS 的机制因 Web 服务器而异。 例如，NGINX 使用在标准商品硬件上运行的OpenSSL ，提供与专用硬件解决方案类似的性能。 NGINX SSL 性能有据可查，可最大限度地减少执行 SSL/TLS 加密和解密的时间和 CPU 损失。

此外，请参阅此博客文章以了解有关提高 SSL/TLS 性能的方法的详细信息。 简单总结一下，这些技术包括：

• 会话缓存- 使用ssl_session_cache指令缓存使用 SSL/TLS 保护每个新连接时使用的参数。
• 会话票证或 ID – 这些将有关特定 SSL/TLS 会话的信息存储在票证或 ID 中，以便可以顺利重用连接，而无需新的握手。
• OCSP 装订——通过缓存 SSL/TLS 证书信息来缩短握手时间。

NGINX 和 NGINX Plus 可用于 SSL/TLS 终止 - 处理客户端流量的加密和解密，同时以明文形式与其他服务器通信。 要设置 NGINX 或 NGINX Plus 来处理 SSL/TLS 终止，请参阅HTTPS 连接和加密 TCP 连接的说明。

提示 6——实现 HTTP/2 或 SPDY

对于已经使用 SSL/TLS 的站点，HTTP/2 和 SPDY 很有可能提高性能，因为单个连接只需要一次握手。 对于尚未使用 SSL/TLS 的站点，HTTP/2 和 SPDY 转向 SSL/TLS（通常会降低性能）从响应能力的角度来看是一种冲击。

谷歌于 2012 年推出了 SPDY，以便在 HTTP/ 1.x的基础上实现更快的性能。 HTTP/2 是最近批准的基于 SPDY 的 IETF 标准。 SPDY 得到广泛支持，但即将被弃用，并由 HTTP/2 取代。

SPDY 和 HTTP/2 的关键特性是使用单个连接而不是多个连接。 单个连接是多路复用的，因此它可以同时承载多个请求和响应的片段。

通过充分利用一个连接，这些协议避免了设置和管理多个连接的开销，这是浏览器实现 HTTP/ 1.x的方式所要求的。 使用单一连接对于 SSL 特别有用，因为它最大限度地减少了 SSL/TLS 建立安全连接所需的耗时握手。

SPDY 协议需要使用 SSL/TLS；HTTP/2 并未正式要求它，但到目前为止，所有支持 HTTP/2 的浏览器只有在启用 SSL/TLS 时才会使用它。 也就是说，仅当网站使用 SSL 且其服务器接受 HTTP/2 流量时，支持 HTTP/2 的浏览器才会使用它。 否则，浏览器通过 HTTP/ 1.x进行通信。

当您实现 SPDY 或 HTTP/2 时，您不再需要典型的 HTTP 性能优化，例如域分片、资源合并和图像精灵。 这些变化使您的代码和部署更简单、更易于管理。 要了解有关 HTTP/2 带来的变化的更多信息，请阅读我们的白皮书《面向 Webapplication开发人员的 HTTP/2》 。

作为对这些协议的支持示例，NGINX 很早就支持 SPDY，如今大多数使用 SPDY 的网站都在 NGINX 上运行。NGINX 也是 HTTP/2 的先驱支持者，自 2015 年 9 月起，NGINX 开源和 NGINX Plus 均支持HTTP/2。

随着时间的推移，NGINX 希望大多数网站能够完全启用 SSL 并迁移到 HTTP/2。 这将提高安全性，并且随着新优化的发现和实施，代码将更简单，性能更好。

提示 7——更新软件版本

提高应用性能的一个简单方法是根据稳定性和性能的声誉为软件堆栈选择组件。 此外，由于高质量组件的开发人员可能会随着时间的推移追求性能的增强和修复错误，因此使用最新的稳定版本的软件是值得的。 新版本受到了开发人员和用户社区的更多关注。 较新的版本还利用了新的编译器优化，包括针对新硬件的调整。

稳定的新版本通常比旧版本具有更高的兼容性和更高的性能。 当您掌握软件更新时，还可以更轻松地掌握调整优化、错误修复和安全警报。

继续使用旧软件也会阻止您利用新功能。 例如，上面描述的 HTTP/2 目前需要 OpenSSL 1.0.1。 从 2016 年中期开始，HTTP/2 将需要 2015 年 1 月发布的 OpenSSL 1.0.2。

NGINX 用户可以从迁移到最新版本的NGINX或NGINX Plus开始；它们包括套接字分片和线程池等新功能（参见技巧 9 ），并且两者都在不断调整性能。 然后深入研究堆栈中的软件并尽可能转到最新版本。

技巧 8 – 调整 Linux 的性能

Linux 是当今大多数 Web 服务器实现的底层操作系统，并且作为基础设施的基础，Linux 代表着提高性能的重要机会。 默认情况下，许多 Linux 系统都经过保守调整，以使用较少的资源并匹配典型的桌面工作负载。 这意味着 Web应用用例至少需要一定程度的调整才能获得最佳性能。

Linux 优化是针对 Web 服务器的。 以 NGINX 为例，以下是您可以考虑的一些可以加速 Linux 的变化亮点：

• 积压队列– 如果您有似乎停滞的连接，请考虑增加net.core.somaxconn ，即可以排队等待 NGINX 关注的最大连接数。如果现有连接限制太小，您将看到错误消息，您可以逐渐增加此参数，直到错误消息停止。
• 文件描述符– NGINX 对每个连接最多使用两个文件描述符。 如果您的系统正在处理大量连接，则可能需要增加sys.fs.file_max （系统范围的文件描述符限制）和nofile （用户文件描述符限制），以支持增加的负载。
• 临时端口- 当用作代理时，NGINX 会为每个上游服务器创建临时（“临时”）端口。 您可以增加由net.ipv4.ip_local_port_range设置的端口值范围，以增加可用端口的数量。 您还可以使用net.ipv4.tcp_fin_timeout设置减少非活动端口被重新使用之前的超时时间，从而实现更快的周转。

对于 NGINX，请查看NGINX 性能调优指南，了解如何优化您的 Linux 系统，以便它可以轻松应对大量网络流量！

技巧 9——调整 Web 服务器的性能

无论您使用哪种 Web 服务器，都需要对其进行调整以提高 Web应用的性能。 以下建议通常适用于任何 Web 服务器，但针对 NGINX 给出了特定设置。关键优化包括：

• 访问日志记录- 您无需立即将每个请求的日志条目写入磁盘，而是可以将条目缓冲在内存中，然后将它们作为一个组写入磁盘。 对于 NGINX，将buffer= size参数添加到access_log指令，以便在内存缓冲区填满时将日志条目写入磁盘。 如果添加flush= time参数，缓冲区内容也会在指定的时间后写入磁盘。
• 缓冲——缓冲将部分响应保存在内存中直到缓冲区填满，这可以使与客户端的通信更加高效。 内存中容纳不下的响应将被写入磁盘，这会降低性能。 当 NGINX 缓冲开启时，您可以使用proxy_buffer_size和proxy_buffers指令来管理它。
• 客户端保持连接– 保持连接可减少开销，尤其是在使用 SSL/TLS 时。 对于 NGINX，您可以将客户端通过给定连接可以发出的keepalive_requests的最大数量从默认值 100 增加，并且可以增加keepalive_timeout以允许 keepalive 连接保持更长时间，从而加快后续请求的速度。
• 上游保持活动– 上游连接（与应用服务器、数据库服务器等的连接）也受益于保持活动连接。 对于上游连接，您可以增加keepalive ，即每个工作进程保持打开的空闲保持连接的数量。 这可以提高连接重用率，减少打开全新连接的需要。 有关更多信息，请参阅我们的博客文章HTTP Keepalive 连接和 Web 性能。
• 限制——限制客户端使用的资源可以提高性能和安全性。 对于 NGINX， limit_conn和limit_conn_zone指令限制来自给定源的连接数，而limit_rate限制带宽。 这些设置可以阻止合法用户“占用”资源，也有助于防止攻击。 limit_req和limit_req_zone指令限制客户端请求。 对于与上游服务器的连接，请使用上游配置块中的服务器指令的max_conns参数。 这限制了与上游服务器的连接，防止过载。 相关的队列指令会创建一个队列，该队列在达到max_conns限制后，可在指定的时间内保存指定数量的请求。
• 工作进程——工作进程负责处理请求。 NGINX 采用基于事件的模型和依赖于操作系统的机制，在工作进程之间有效地分配请求。 建议将worker_processes的值设置为每个 CPU 一个。 如果需要，可以在大多数系统上安全地提高worker_connections的最大数量（默认为 512）；请进行实验以找到最适合您系统的值。
• 套接字分片- 通常，单个套接字监听器将新连接分发给所有工作进程。 套接字分片为每个工作进程创建一个套接字监听器，内核在套接字监听器可用时将其分配给该监听器的连接。 这可以减少锁争用并提高多核系统的性能。 要启用套接字分片，请在listen指令中包含repeatport参数。
• 线程池——任何计算机进程都可能被一个缓慢的操作所阻碍。 对于 Web 服务器软件，磁盘访问可以支持许多更快的操作，例如计算或复制内存中的信息。 当使用线程池时，较慢的操作将被分配给单独的一组任务，而主处理循环则继续运行较快的操作。 当磁盘操作完成时，结果将返回到主处理循环。 在 NGINX 中，两个操作 - read()系统调用和sendfile() - 被卸载到线程池。

提示。 更改任何操作系统或支持服务的设置时，请一次更改一个设置，然后测试性能。 如果更改导致问题，或者它不会使您的网站运行得更快，请将其改回。

有关调整 NGINX Web 服务器的更多信息，请参阅我们的博客文章“调整 NGINX 性能” 。

提示 10 – 监控实时活动以解决问题和瓶颈

高性能应用开发和交付方法的关键是密切、实时地关注应用程序的实际性能。 您必须能够监控特定设备内和整个网络基础架构内的活动。

监控网站活动大多是被动的——它告诉你发生了什么，然后让你发现问题并修复它们。

监控可以发现几种不同类型的问题。 它们包括：

• 服务器宕机了。
• 服务器运行不畅，正在断开连接。
• 服务器遭受大量缓存未命中。
• 服务器未发送正确的内容。

New Relic 或 Dynatrace 等全局应用性能监控工具可帮助您从远程位置监控页面加载时间，而 NGINX 可帮助您监控应用交付端。 应用性能数据可以告诉您何时您的优化对您的用户产生了真正的影响，以及何时您需要考虑增加基础设施的容量以维持流量。

为了帮助快速识别和解决问题，NGINX Plus 添加了应用感知健康检查- 定期重复并用于提醒您问题的综合事务。 NGINX Plus 还具有会话耗尽功能，可在现有任务完成时停止新连接，以及慢启动功能，允许恢复的服务器在负载平衡组内加速。 如果使用得当，健康检查可以让您在问题对用户体验产生重大影响之前发现问题，而会话耗尽和慢启动可以让您更换服务器并确保该过程不会对感知的性能或正常运行时间产生负面影响。 该图显示了具有服务器、TCP 连接和缓存的 Web 基础架构的内置 NGINX Plus实时活动监控仪表板。

结论——性能提升 10 倍

任何一个 Web应用可用的性能改进都有很大的差异，实际收益取决于您的预算、您可以投入的时间以及现有实施中的差距。 那么，如何才能使您自己的应用的性能提高 10 倍呢？

为了帮助您了解每项优化的潜在影响，以下列出了使用上述每条建议可能带来的改进，但您的结果几乎肯定会有所不同：

• 反向代理服务器和负载均衡——没有负载均衡或负载均衡不佳可能会导致性能非常差。 添加反向代理服务器（例如 NGINX）可以防止 Web应用在内存和磁盘之间发生抖动。 负载均衡可以将处理从负担过重的服务器转移到可用的服务器，并使扩展变得容易。 这些变化可以带来显著的性能提升，与当前实施中最糟糕的时刻相比，可以轻松实现 10 倍的提升，并且整体性能可以获得虽小但实质性的提升。
• 缓存动态和静态内容——如果您的 Web 服务器负担过重，并且兼作应用服务器，那么仅通过缓存动态内容就可以将高峰时间性能提高 10 倍。 静态文件的缓存也可以将性能提高个位数。
• 压缩数据- 使用媒体文件压缩（例如用于照片的 JPEG、用于图形的 PNG、用于电影的 MPEG-4 和用于音乐文件的 MP3）可以大大提高性能。 一旦这些都投入使用，那么压缩文本数据（代码和 HTML）可以将初始页面加载时间提高一倍。
• 优化 SSL/TLS – 安全握手会对性能产生很大影响，因此对其进行优化可以使初始响应能力提高 2 倍，特别是对于文本较多的网站。 优化 SSL/TLS 下的媒体文件传输可能只会带来很小的性能提升。
• 实施 HTTP/2 和 SPDY – 与 SSL/TLS 一起使用时，这些协议可能会导致整个站点性能的逐步改善。
• 调整 Linux 和 Web 服务器软件（如 NGINX） ——优化缓冲、使用保持连接以及将时间密集型任务转移到单独的线程池等修复可以显著提高性能；例如，线程池可以将磁盘密集型任务的速度提高近一个数量级。

我们希望您亲自尝试这些技术。 我们希望了解您能够实现哪些应用性能改进。 在下面的评论中分享您的结果，或使用标签 #NGINX 和 #webperf 发布您的故事！

互联网统计资源

Statista.com——2016 年互联网经济在 G-20 国家国内生产总值中的份额

Kissmetrics – 加载时间如何影响您的底线（信息图）

Econsultancy – 网站速度：提高转化率的案例研究、技巧和工具