网络性能评测:Google.com

2020-09-16 22:38:27

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

谷歌主页以速度著称,但这在一定程度上是因为它的稀疏程度。在此讨论中,让我们转而关注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路由。

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