网站页面打开速度数据研究

关键页面速度加载时间指标的基准

我们的首要任务是为重要的页面速度指标建立基准。

如您所知，“页面速度”实际上由几个不同的阶段组成。

 

其中一些阶段发生在服务器级别。其他的则发生在用户的浏览器中。

为了充分了解页面加载的速度，我们需要深入了解每个阶段。

具体来说，我们确定了以下方面的平均速度：

• TTFB： HTML 文档响应第一个字节的时间
• StartRender：渲染开始时
• 视觉完整：用户可以看到所有页面资产
• 速度指数：用户看到页面加载的速度
• onLoad：当所有页面资源（CSS、图片等）下载完成时
• 完全加载：当页面在用户浏览器中加载 100% 时

桌面上的平均 TTFB 速度为 1.286 秒，移动设备上为 2.594 秒。

 

桌面上的平均开始渲染速度为 2.834 秒，移动设备上为 6.709 秒。

 

桌面上的平均 Visual Complete 速度为 8.225 秒，移动设备上为 21.608 秒。

 

桌面上的平均速度指数速度为 4.782 秒，移动设备上的平均速度指数为 11.455 秒。

 

桌面上的平均 onLoad 速度为 8.875 秒，移动设备上为 23.608 秒。

 

桌面上的平均满载速度为 10.3 秒，移动设备上的平均满载速度为 27.3 秒。

 

要点：桌面上网页的平均页面加载速度为 10.3 秒，移动设备上为 27.3 秒。平均而言，移动设备上的页面加载时间比桌面设备上的加载时间长 87.84%。

Weebly 和 Squarespace 的整体速度表现最佳。 WordPress 是最糟糕的之一

就页面速度而言，哪种 CMS 最好？

为了回答这个问题，我们确定了数据集中所有网站所使用的 CMS。然后，我们比较了我们发现的每个 CMS 的 TTFB 性能。

根据我们的数据，Weebly 和 Squarespace 在桌面领域名列前茅。

 

对于移动页面速度，Squarespace 排名第一……Adobe Experience Manager 和 Weebly 跻身前三。

 

值得注意的是，就移动速度而言，WordPress 仅在我们分析的最佳 CMS 中排名第 14。

 

另一种流行的 CMS Wix 在桌面和移动加载速度方面也评价不佳。

 

尽管 WordPress 为大约30% 的网站提供支持，但它显然没有针对页面加载速度进行优化。这并不是说 WordPress 是一个糟糕的 CMS。它还有其他优势（例如易用性、庞大的插件库和 SEO），使其成为许多网站所有者的首选 CMS。

然而，当严格考虑网站加载速度时，其他 CMS 似乎比 WordPress 有明显的优势。

要点：在主要 CMS 中，Squarespace 和 Weebly 具有最佳的移动页面速度性能。 WordPress 和 Wix 排名接近底部。

使用 CDN 可能有助于桌面 TTFB。最小化 HTML 请求是移动 TTFB 的关键

我们分析了各种页面特性对 TTFB（第一个字节的时间）的影响。

  这是我们发现的：

 

正如您所看到的，使用 CDN 似乎可以改善桌面和移动设备的 TTFB。然而，与移动设备相比，CDN 在桌面上似乎更有帮助。在通过移动设备加载的页面上，HTML 请求的数量对 TTFB 的影响最大。

虽然我们确实发现了各种页面特征和 TTFB 时间之间的关系，但页面级因素不会影响 TTFB。 TTFB 很大程度上取决于服务器的响应时间，我们稍后会介绍这一点。

要点：使用 CDN 并最大限度地减少 HTML 请求可能会加快桌面和移动设备上的 TTFB 速度。

与小页面相比，大页面需要 381% 的时间才能“视觉上完成”加载

“视觉完整”是指用户浏览器内网页的所有视觉内容均已加载。

 

可能有脚本和其他资源在屏幕外加载。但从用户的角度来看，页面已加载。

视觉完整度是一个重要的页面速度指标，因为它会影响用户对页面加载速度的主观体验。

只要用户可以看到并使用该页面，它就已完全加载……即使仍然可能有资产在幕后加载和渲染。

我们发现页面大小 (bytesTotal) 对移动和桌面视觉完整加载时间有显着影响。

 

然而，与桌面相比，移动设备上的页面大小更为重要。

在桌面上，CDN 的使用与更快的 Visually Complete 加载速度密切相关。页面大小紧随其后。

在移动设备上，CDN 仅排名第五。

因此，如果提高移动加载速度是您的首要任务，我会考虑尽可能减少页面的大小。这可能意味着删除第三方脚本。或者压缩图像。确切的步骤取决于您的网站。然而，很明显，当谈到视觉完整速度时，一切都与 HTML 大小有关。

要点： CDN 可以显着提高桌面和移动设备上的视觉完整页面速度。然而，CDN 对桌面加载的影响要大得多。对于移动设备，总页面大小是视觉完整加载时间的最重要因素。

页面总重量与“满载”页面速度密切相关

最后，我们研究了影响“完全加载”页面速度的因素。

顾名思义，完全加载是指页面 100% 的资源已加载并呈现。

当谈到完全加载的页面速度时，页面的总大小是迄今为止桌面和移动设备上最重要的因素。

 

请求数量也会影响页面完全加载的速度。

该数据的有趣之处在于桌面和移动设备之间存在很强的重叠。与我们分析的许多其他指标不同，桌面和移动设备的“满载”似乎受到同一组变量（即页面大小和 HTML 请求总数）的影响。

然而，页面大小和 HTML 请求的重要性并不令人意外。

压缩图像、缓存和其他步骤通常会减少页面加载所需的时间。但他们只能走这么远。最终，要使页面“完全加载”，浏览器必须加载页面上的所有资源。需要加载的资源越多，页面加载所需的时间就越长。

这可能就是为什么 CDN 似乎对完全加载页面速度没有太大影响（在桌面上总体重要性排名第三，在移动设备上排名第十）。 CDN 可以缩短图像加载时间。但他们并没有对第三方脚本和其他可能减慢速度的资产提供太多帮助。

要点：总大小对完全加载页面速度的影响比桌面和移动设备上的任何其他变量都大。与较小页面 (<.83 MB) 相比，大页面 (>3.49 MB) 完全加载所需的时间要长 486%。

Wink 和 Gatsby 是平均大小网页最快的 JavaScript 框架

在确定页面上加载的内容（以及加载时间）的优先级时， JavaScript 框架承担了很多繁重的工作。

这就是为什么几乎 76% 的网站都使用这些框架来创建高效、安全和标准化的页面。

我们首先收集了每个框架在网络上的使用频率的基准。

 

React 是迄今为止最常用的 JS 框架（25.3% 的网站使用它）。 TweenMax (10.3%) 和 RequireJS (9.5%) 也相当受欢迎

接下来，我们想要找出哪些 JavaScript 框架在小型（<1,264,374 字节）、中型（1,264,374 和 4,019,332 字节）和大型（>4,019,332 字节）页面上表现最佳。

对于小页面，RightJS 表现最好。

 

对于中等页面，Wink 和 Gatsby 表现最好。

 

对于大页面，Gatsby 和 Riot 的 FCP 时间最快。

 

总的来说，JavaScript 框架的选择会对 FCP 时间产生重大影响。事实上，对于中等大小的页面，最好的 JS 框架 (Wink) 的加载速度比最慢的框架 (Meteor) 快 213%。

尽管最好和最差的表现有相当多的重叠（例如，Gatsby 和 RightJS 在所有三个页面大小类别中名列前 5），但似乎某些 JS 框架在某些大小的页面上效果最好。

例如，Riot 是一个很棒的大页面框架（总体排名第二）。

 

然而，对于小页面，Riot 的表现明显较差（总体排名第 15）。

 

要点：没有适合所有情况的“最佳”JavaScript 框架。对于拥有大量小尺寸页面的网站，RightJS 是您的最佳选择。对于大多数页面较大的网站来说，Gatsby 看起来是理想的选择。

具有低压缩级别或高压缩级别的页面具有最快的加载时间

在服务器上压缩页面文件是一把双刃剑。一方面，压缩文件可以显着减少页面重量。

但是，在从服务器发送文件之前对其进行压缩需要在浏览器上进行额外的工作，因为客户端需要在渲染文件之前解压缩文件。

作为分析的一部分，我们着手回答这个问题：压缩文件是否真的可以提高页面速度？

为了回答这个问题，我们将 FCP 分为三类（快速、平均、慢速）：

  快速：0-1000ms
  平均：1000ms-2500ms
  慢：< 2500ms

然后，我们比较了小、中、大页面之间的 FCP 速度和压缩级别。

对于小页面，较低级别的压缩与较快的 FCP 加载时间相关。然而，在非常高的压缩级别 (90-100%) 下，加载时间会再次加快。

 

中等大小的页面也有类似的分布：

 

大页面具有更极端的反向钟形曲线分布：

 

尽管页面大小之间的确切分布不同，但结论很明显：压缩级别非常低或非常高的页面加载速度最快。

事实上，您可以看到压缩适量文件的页面的 FCP 性能有所下降。

 

具体来说，压缩 60%-80% 文件的页面性能最差。

因此，当谈到提高页面速度时，超低或超高级别的压缩往往效果最好。低级别的压缩减少了浏览器所需的工作。高水平的压缩比负载较小的客户端的繁重工作更重要。

要点：与具有中等压缩级别的页面相比，具有非常低或非常高压缩的页面具有更好的性能。

第三方脚本对加载时间产生负面影响

毫不奇怪，我们发现第三方脚本（例如 Google Analytics、社交分享按钮和视频主机）会导致 FCP 时间变慢。

 

事实上，我们发现每个第 3 方脚本都会使页面加载时间增加 34.1 毫秒。

我们的发现与其他发现第三方脚本对页面速度有巨大影响的研究结果（例如此）一致。

显然，影响取决于所使用的脚本。某些第三方脚本（如 Hotjar）加载速度相对较快。其他公司，包括 Salesforce，是出了名的缓慢。

简而言之，第三方脚本会导致加载时间更长。页面的脚本越多，加载速度就越慢。

要点：页面上使用的每个第 3 方脚本都会使页面加载时间增加 34.1 毫秒。

响应式图像似乎比延迟加载和使用 WebP 更能缩短页面加载时间

图像在网站性能中发挥着极其重要的作用，主要原因有两个：

首先，图像占据了页面整体大小的相当大的部分。

其次，用户的注意力往往集中在页面上出现的图像上。如果这些图像加载缓慢，可能会对用户体验产生负面影响。

由于图像可以决定网站的加载速度，因此我们决定比较 4 种不同的图像优化方法的性能：

• WebP：由 Google 开发，WebP 是一种图像格式，与其他文件格式相比，其尺寸较小，但仍能获得相似水平的图像质量。
• 优化图像： “优化图像”是指根据用户的设备、位置等提供不同版本的图像。我们在此类别下包括了内容交付网络 (CDN)、图像压缩和其他图像优化 Web 服务的使用。
• 延迟屏幕外图像当用户滚动到页面上的该点时加载折叠下方的图像。也称为“延迟加载”。
• 响应式图像：图像动态适应浏览器窗口大小。

当我们比较Lighthouse 速度得分的各种方法时，响应式图像名列前茅。

 

我们还分析了哪种方法获得的100/100 Lighthouse 分数最高。结果非常相似。

 

要点：尽管与 PNG 和 JPEG 相比，WebP 可能会改进图像压缩，但目前很少有网站实现这种新的图像格式。

GitHub 和 Weebly Hosting 具有最佳 TTFB 性能。 Siteground 和 Wix 的情况最差

我们比较了主要网络托管提供商的页面速度性能。

考虑到服务器响应时间对 TTFB 的影响最大，我们分析了不同主机在该关键指标上的表现。

具体来说，我们将 TTFB 分为三类（快、平均、慢）。我们还查看了每位主持人在每个类别中出现的百分比。

以下是每个网络托管提供商在桌面上的 TTFB 性能：

 

Github、Weebly 和 Acquia 是桌面 TTFB 表现前三名。 Automattic、Wix 和 Siteground 表现最差。

我们对移动 TTFB 进行了相同的分析。结果如下：

 

正如您所看到的，Github 在移动设备和桌面设备上的表现都非常出色。考虑到Github Pages仅提供静态资源，这应该不足为奇。这意味着，在很多方面，Github 与“普通”网络主机并不是 1:1 的比较。

Seravo、Netlify 和 Weebly 跻身前 4 名。Wix 和 Automattic 排名垫底。

从这个分析中可以得出什么结论？

TTFB 只是选择主机时要考虑的众多因素之一。还有成本、正常运行时间、客户支持、功能等等。

也就是说，当谈到桌面和移动设备上的快速页面加载时间时，Github Pages 是迄今为止主要主机中的最佳选择。 Wix 和 Automattic 主机的 TTFB 时间往往较慢。

要点：在主要托管提供商中，Github 和 Weebly 在桌面上表现最好。根据我们的分析，GitHub 和 Seravo 是最快的移动主机。但是，应该注意的是，Github Pages 仅提供静态页面，这使其比我们分析的其他主机具有固有的优势。

中国、日本和德国的 TTFB 加载时间最快

我们根据数据集比较了 11 个国家/地区的 TTFB 加载时间。

以下是按国家/地区划分的桌面速度细分：

 

  和移动设备：

 

要点：中国拥有最好的移动和桌面 TTFB 性能。其次是日本和德国，其页面速度高于全球平均水平。法国、英国、加拿大、美国和俄罗斯的页面速度平均。澳大利亚、巴西和印度的速度低于全球平均水平。

具有 CDN 的页面比没有 CDN 的页面性能更差

我们最令人惊讶的发现之一是，使用 CDN 的页面实际上比不使用 CDN 的页面表现更差。

对于两个桌面来说都是如此：

 

  和移动设备：

 

  怎么会这样？

理论上，由于 CDN 提供的内容靠近用户所在位置，因此应该全面提高页面速度。

 

然而，我们的分析并非如此。

我们假设并非所有 CDN 都是一样的。在许多情况下，使用优化不佳的 CDN 实际上会减慢速度。

当我们分析前 18 名顶级 CDN 提供商的性能时，我们确实发现了性能上的巨大差异。

 

具体来说，我们注意到（在桌面上）最好的 CDN 的性能比最差的 CDN 好 3.6 倍。这有助于解释为什么 CDN 不会自动提高性能。

为了更容易发现表现不佳的网站，我们将 CDN 性能与全球平均水平进行了比较。

 

然后，我们将每个 CDN 放入三个存储桶之一：

• 好（快百分比和慢百分比优于所有提供商的平均水平）
• 平均（快 % 或慢 % 优于所有提供商的平均水平）
• 差（快百分比和慢百分比比所有提供商的平均水平更差）

以下是每个提供商的绩效摘要：

  桌面

好的： Airee、Amazon Cloudfront、Azure CDN、CacheFly、EdgeCast、Fastly、GitHub Pages、Google Cloud、KeyCDN、MaxCDN、Netlify
平均： CDN77
不好： Akamai、ArvanCloud、Cloudflare、Fireblade、Incapsula、Sucuri

  移动的

好的： Airee、Amazon Cloudfront、Azure CDN、CDN77、EdgeCast、Fastly、GitHub Pages、Google Cloud、KeyCDN、MaxCDN、Netlify
平均： Fireblade、Incapsula、Sucuri
不好： Akamai、ArvanCloud、Cloudflare

要点：使用 CDN 不会自动提高页面速度性能。某些 CDN 的性能明显优于其他 CDN。因此，选择在桌面和​​移动设备上都表现良好的 CDN 非常重要。

  结论

如果您想了解有关如何进行此分析的更多信息，请随时查看我们的研究方法 PDF 。

现在我想听听你的意见：

这项研究的哪一项发现让您印象深刻？

  或者：

您计划针对哪项发现采取行动？

无论哪种方式，请在下面发表评论让我知道。