网络性能评测：Google.com

谷歌怎么会这么快呢？它太快了，我们认为这是理所当然的。从你搜索到显示结果，感觉是瞬间的。关于他们用来让他们的网站这么快的技术，我们能学到些什么呢？

谷歌主页以速度著称，但这在一定程度上是因为它的稀疏程度。在此讨论中，让我们转而关注Google搜索结果页面。它有更多的功能和内容，而且加载速度仍然快得令人难以置信。在这里，我们搜索来自移动电话的“请求指标”。

哇。这几乎是立竿见影的。如果我们将谷歌搜索结果的速度与我们Nike.com的网络性能进行比较，毫无疑问，哪种体验更可取。但谷歌是如何如此迅速地加载这些结果的呢？

让我们来看一下这个页面加载的统计数据(在Chrome开发人员工具的Network选项卡中收集)。

与许多站点相比，这是一个“轻量级”的页面加载，但仍然有超过100个请求。有四分之三兆字节的资产通过电线运输。

有趣的是，Google正在使用gzip进行压缩，而不是使用他们自己的Brotli算法，尽管我的浏览器可以接受这两种算法。在基准测试中，与gzip相比，brotli可以配置为提高压缩和性能，所以不清楚他们为什么做出这个选择。

总体而言，这些统计数据还可以，但它们不能解释我们看到的速度。这里最值得注意的是没有外部CSS文件。

浏览器没有请求任何CSS文件，但是页面样式很好。让我们看看我们从Google得到的HTML，看看我们是否能找出样式是从哪里来的。

它们是内联的！Google正在内联CSS，并将其与页面响应一起发送出去。这允许浏览器呈现带样式的内容，而无需等待外部资源返回。但是谷歌不仅仅是内联CSS。

谷歌认真对待内联。它们不仅内联了样式，还内联了它们的JavaScript！

事实上，我们可以对页面运行一些选择器，以查看脚本和样式的内联有多普遍。

我们可以看到，在页面上的所有脚本和样式中，除了两个外部JavaScript文件之外，所有内容都是内联的。(注意：这两个外部脚本动态加载额外的JS文件，这就是我们总共加载9个页面的原因)。

为了说明Google在内联静态资源的概念上取得了多大进展，让我们只加载HTML。没有其他外部资产。没有外部JavaScript，没有外部图像，没有外部任何东西。我保存了来自Google的HTML响应，并在关闭网络的情况下打开它。看起来怎么样？

看上去棒极了！甚至所有的搜索结果都有图标。汉堡包菜单不起作用，向末尾旋转的图像丢失了它的图像。但其他一切看起来都很好。

前面我们看到，在实际页面加载过程中加载了104个图像文件。然而，我们看到大部分图像都在这里工作。什么给予？

谷歌对大部分图片进行了巧妙的优化。如果我们查看检查器中的request Metrics Favicon图像，我们可以看到该图像有一个特殊的src URI-一个数据URI！二进制图像内容是Base64编码的，并直接放入src属性中。

使用数据URI是谷歌展示其内联资产承诺的另一种方式。当有许多小图像要显示时，这是一种完美的技术。对于较大的图像，数据URI方法的回报会递减，因为它会增大页面大小。这就是为什么“图像”旋转木马是空白的-他们仍然使用外部来源的图像来填充该部分。

重要提示：值得注意的是，在Chrome开发人员工具的网络选项卡中，这些Base64编码图像中的每一个都被视为“请求”。这就解释了为什么有这么多“请求”的图片，而页面却这么快。浏览器从来不会通过网络获取它们！下面是它们在开发人员工具中的外观：

Google致力于内联JS、CSS和图片，这表明它对于最大化性能有多么重要。浏览器发出的每个外部请求都是一个等待发生的性能问题。

谷歌在这方面不会冒任何风险。一旦用户的浏览器收到来自Google的第一个响应，它就可以呈现90%的UI，而不需要再次走线。这加快了速度，还缓解了网络速度慢或不可靠的问题。

当然，快速获得对用户的第一个响应也很重要。90%并不是100%-要获得功能齐全的体验，还需要提出其他要求。内联并不是谷歌为提高速度而做的唯一一件事。

优化页面内容固然重要，但可能同样重要的是通过网络快速交付该页面及其相关资源。

Google运行一个具有多层基础设施的健壮网络，以确保处理请求时尽可能靠近最终用户。他们与世界各地的ISP有许多对等安排，以及全面的边缘缓存设置，可确保静态资源几乎始终在附近。

用ping这样的传统工具很难客观地衡量谷歌网络的性能，但我们可以在我们的浏览器中看看事情是如何表现的。

对Google的初始请求的第一个字节(TTFB)的时间为145ms(蓝框)。也就是说，浏览器在145毫秒后开始接收来自Google的响应。那是相当快的。完成阅读响应的总时间为880ms(橙色框)。这包括从谷歌下载全部回复的时间。

请记住，由于Google积极的静态内容内联，一旦响应完成，90%的UI可以显示给用户。

这些文件的平均TTFB均为~30ms。这表明服务器就在附近，浏览器之间的跳跃最小。考虑到我通过Comcast互联网连接加载此页面，这是一个可靠的响应时间。

谷歌服务器不仅在附近，它们还在使用新协议提供文件。您可能已经注意到上面屏幕截图中的值h3-q050。这是因为浏览器通过HTTP/3与谷歌对话。

它仍然是一个草案标准，但是HTTP/3和HTTP/2之间的主要区别在于TCP不再是底层连接协议。他们采用了Quic而不是TCP，因为它提高了性能：

[Quic]通过在两个端点之间通过用户数据报协议(UDP)建立多个多路复用连接来实现这一点。这与HTTP/2的多路复用连接协同工作，允许多个数据流独立到达所有端点，从而独立于涉及其他流的数据包丢失。

大多数公司无法访问谷歌的网络或庞大的开发人员池，但他们用来快速加载页面的相同想法可以应用于任何网站。

谷歌将其带到了一个新的水平，但避免网络请求是提高网络性能的主要因素。即使使用较新的HTTP协议，捆绑资产来合并静态内容仍然是一个好主意。如果您可以内联一些JavaScript或CSS，那就更好了。使用数据URI传输小图像也会有所帮助。网络不可靠，浏览器发出的每个请求都有可能失败或延迟。

Webpack是现代前端工具链中的主打，如果你想走内联路线，有几个插件可以帮助你：

你不太可能访问到像谷歌那样复杂的网络，但现代云提供商提供了许多类似的功能。任何人都可以使用专门构建的CDN和基于地理位置的动态DNS路由。

在CDN上托管静态内容是获得Google享有的一些网络优势的一种简单方式，包括对HTTP/2或HTTP/3的支持。如果数据局部性对您的用例或客户群很重要，那么使用地理感知DNS解决方案可以让您将数据局部性提升到一个新的级别。

即使你不使用云，像MaxCDN和这样的第三方也能迅速简化全球静态内容的传送。还有像easyDNS这样的DNS提供商提供完整的GeoDNS路由。

谷歌是互联网上最重要的网络资产之一，该公司正在推动许多新的网络标准。毫不奇怪，他们的网站是最快的网站之一。对于其他所有人，我们已经构建了请求度量。现在您可以看到您的用户是如何真正体验您的站点的。